Vim and Emacs modelines(briancarper.net)
briancarper.net
Vim and Emacs modelines
http://briancarper.net/blog/vim-and-emacs-modelines
12 comments
A classic apples vs. oranges fallacy--which is main reason why these horrid comparison articles will never stop being published.
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.
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.
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...
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...
That's interesting. It actually illustrates the sometimes massive difference between "configurable" and "extensible".
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...)
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...)
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:
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
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 */
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 */
Same here. I was really hoping that this was a translation between vim and emacs modelines. That would actually be useful.
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.
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.
Yeah, emacs has them too. Interestingly, I've noticed that Komodo supports emacs modelines, but vim doesn't.
Emacs ought to understand Vim modelines. That would be very Emacs.
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.
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.
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?)