[Haskell-cafe] Editor

[Claus Reinke]

>Vim is eliminated before it reaches the gate because it's a modal
>editor.  Even with GVim in place, it still has that modal stench to it
>that leaps up and bites at awkward moments. 

that's a bit more specific, at least. but as far as i recall, modes were
considered bad for specific reasons, such as 'users can't see where
they are, modewise',  'functionality becomes unavailable in a mode',
'users have no way to get out of a mode', etc. and most of these 
specific issues have actually been addressed in vim.

so, what remains is convenience: do i always want to start navigating
from some home mode (meaning long, absolute, command navigation 
strings), or do i want the interface to remember where i navigated last 
(meaning short, relative, command navigation strings)? what used
to be called modes (bad, or rather: badly implemented) is now called 
context-sensitivity (good, or rather: good, if done well). 

you do not want your fortran- or xml-editing commands around 
when editing haskell, so unless you're prefixing every command
with 'haskell-', or refuse to use haskell-specific commands, you're 
editing haskell in a haskell-mode, right?

you could use insert mode as your home mode, and wrap each
command sequence to leave insert mode and to return to it, so 
'dd' would become '<esc>ddi'. or you could use normal mode
as your home mode, and make sure to end every excursion into
insert mode with '<esc>'. or you could use vim as it was intended:
using insert mode, or normal mode, for what they are good at, 
and switch between them whenever you like.

have you tried 'easy vim', btw? i don't like it myself, but it is useful
for getting students started quickly (':help easy', ':help evim-keys'):

    -y  Easy mode.  Implied for |evim| and |eview|.  Starts with
      'insertmode' set and behaves like a click-and-type editor.
      This sources the script $VIMRUNTIME/evim.vim.  Mappings 
      are set up to work like most click-and-type editors, see
      |evim-keys|.  The GUI is started when available.
      {not in Vi}

>files of either stripe) and adjust your editing preferences.  It's not a
>particularly good programmer's editor, but look at the lovely tabbed
>dialog box with all those lovely HID bits like checkboxes, radio
>buttons, spin buttons, dropdown lists, lists, etc.  Now do the same in
>GVim and get ... a text file with some editing tricks to make things
>slightly easier.  (It's not immediately obvious how to get rid of it
>either.)  

you're referring to ':options', i assume? and you're aware that the
sheer number of options would make a single dialog box hard to
design in any useful way? gvim actually permits setting a whole
lot of options via its menus, and i tend to set options either in
my vimrc file or in a filetype plugin, or directly, using ':set'+tab
for command-completion/navigation. 

yes, the ':options' window doesn't look pretty, merely functional. 
on the positive side, it is just another text window, so you navigate
in it they same way as in any other text window (no separate
dialogue-box-mode!-). and since vim is about programmers 
editing (program) text, handling everything as text is consistent.

claus