Vim and Emacs modelines

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

by CUViper • 17 years ago

10 12 17 years ago

bonsaitree• 17 years ago

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

CUViper• 17 years ago

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• 17 years ago

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

crux• 17 years ago

I disagree. The two apps have wildly different configuration schemes, yes, to wildly different ends, but in this case we're addressing the exact same function in both editors. It's not a question of whether vim's syntax highlighting is better or worse than emacs's ability to run tetris. It's a direct look at which of the two apps makes it easier and more effective to configure the modeline. Now, you might argue that that's not going to be a determining factor for anyone who's choosing between the two—because perhaps they are apples and oranges, but in this case he's simply saying that vim has more vitamin b. So to speak.

In general though I find the apples-and-oranges complaint about vim-emacs comparisons to be disingenuous. You may say, 'Oh, but emacs is much more than a text editor, so it's foolish to compare them directly!' but not everybody who's interested in choosing one or the other would necessarily have any interest in the OS-like capabilities of emacs. That is to say: there is still a very good reason to review emacs purely in its function as a text editor, even if that is not the full extent of its capabilities. Many, if not most, people in the market for a text editor aren't really interested in whether, after several years' learning the ropes, they might run a full Turing Machine in it.

Periodic• 17 years ago

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• 17 years ago

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

aerique• 17 years ago

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

aeroevan• 17 years ago

Same here. I was really hoping that this was a translation between vim and emacs modelines. That would actually be useful.

shabble• 17 years ago

The equivalent for Emacs (sometimes known as the "Hey, Emacs!" line, is documented at http://www.gnu.org/software/emacs/manual/html_node/emacs/Spe...

There's also ways to set directory tree specific variables as well, so you can override the defaults for all files in a particular project. Very handy.

jrockway3• 17 years ago

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?)

Vim and Emacs modelines

Related Stories