

Vim and Emacs modelines - CUViper
http://briancarper.net/blog/vim-and-emacs-modelines

======
jrockway
All the messy code there is to make a right-click (etc.) menu available to
show commonly-used minor modes. This makes the interface more discoverable for
new users, and doesn't get in the way of experienced users.

S-expressions are better than strings because they cleanly compose. You can
write your big-long-sexp for the default menu, and I can use it as a part of
my modeline without worrying about quoting.

You can see here that you can control a lot of Emacs' user-visible
functionality simply by adding an association to this list. The programmer
adds the cool routine to this code, the user gets a simple alias in
`customize`.

I am really, really confused as to why this is a bad thing.

The deep issue here is that Emacs' behavior is built from composing fragments
of programs. This means that you can change it as much or as little a you
want. Vim just does stuff -- "Don't like it? Fuck you."

(I will also point out that it is a Simple Matter Of Programming to make Emacs
support vim modeline definitions verbatim. Not as easy to do it the other way,
is it?)

------
bonsaitree
A classic apples vs. oranges fallacy--which is main reason why these horrid
comparison articles will never stop being published.

~~~
CUViper
The primary goals of these apps are not so different, which is why I think
comparisons can be meaningful. Consider how they describe themselves:

 _Vim is a highly configurable text editor built to enable efficient text
editing._

 _GNU Emacs is an extensible, customizable text editor--and more._

The "and more" speaks volumes about the complexity of Emacs...

~~~
jjames
That's interesting. It actually illustrates the sometimes massive difference
between "configurable" and "extensible".

~~~
jrockway
Yes. Emacs is a library for writing text editors, and this library also comes
with a text editor that runs when you type "emacs".

Programs are much easier to write than config files.

(Incidentally, emacs can be set up to act like vi with all of Emacs' editing
commands available. To preempt the inevitable "it's not vim" comments, I'll
point out that this tends to confuse vim users, who think that all "vi"s have
the same commands that vim does...)

------
Periodic
I know this isn't quite what the article was about, but when he said
"modelines" I thought of the lines you can place in a comment in a file to set
editor options. For example, <http://vim.wikia.com/wiki/Modeline_magic>

It's great for making things consistent within a file when the editors people
are using might not be consistent in their configuration. For example, I might
be collaborating with one person who uses tabs with a shift width of 8, while
in my own writing I may prefer to use 4 spaces.

So I can add:

    
    
        /* vim: set noexpandtab:sw=8:ts=8 */
    

and suddenly vim will realize that it should treat an input of <tab> as a tab
character and render them as 8 characters.

Alternately, if I were writing a document where I wanted all lines to be
automatically wrapped to be within 80 characters but I usually let them
continue indefinitely, I could add

    
    
        /* vim: set wrap:tw=80 */
    

and I quickly have a per-file way of setting my editor's configuration.

~~~
sid0
Yeah, emacs has them too. Interestingly, I've noticed that Komodo supports
emacs modelines, but vim doesn't.

~~~
aerique
Emacs ought to understand Vim modelines. That would be very Emacs.

~~~
jrockway
How do you map vim to emacs? Emacs has much richer (for example) indentation
properties; so there is not enough information for it to do the right thing.

For simple things, like tab width, it could be made compatible, however.
Personally, I prefer a human-readable set of guidelines, then I just configure
emacs (via eproject) to set things up correctly for each project. Not as easy,
I guess, but then new files I create for the project have the right settings
by default.

