crazylazy.info

txt

Why Vim vs. emacs sucks

Most people out there prefer either vim or emacs. Most people see a kind of steep learning curve when it comes to the latter. LISP, short-cuts, and an extremely versatile set of configuration options aren't necessarily creating a beginner friendly editing experience. - I pretty much guess that's the reason why some people find vim, stick with it, and extend it minimally.
Nevertheless there're many people flaming and discussing the advancements... both editors are awesome. And that's the end of the story for me. So let's combine their features into an active editor that supports programming, taking notes, playing around, mind-mapping, brainstorming... with code-completion, keyboard-commands, mouse-menus, project management and convenient editing functions of course. Just to make an example what active editing means.

Fetch a GUI?

Surely you can stick with the command-line variant. But I don't do that as long as I'm not forced to edit stuff remotely.
On Linux you can stick with Xemacs, on Windows a cygwinized port exists. MacOS has Aquamacs, which follows the GUI guidelines Apple introduced and uses modified meta-keys. I most times stick with that one or Xemacs.

You can make emacs render pictures. auctex - an extension that renders LaTeX equations for example - does that. Or if you include a JPG.

The new born emacs rebel

Viper is a Vi emulation on top of Emacs. At the same time, Viper provides a virtually unrestricted access to Emacs facilities. That's pretty decent, because some shortcuts in emacs even after years still suck. You can stick with vim commands, but you don't need to.

There's an initial setup that may help you configuring your emacs-vim hybrid ;).

And the rebel steels

You can steel from any .emacs you find. It's not of major importance here what functions I chose and why I use specific mode hooks. The emacs-wiki has an interesting set of extensions for your .emacs.d. There're always fields in my config where I change stuff. There're always errors ;) or new requirements.

What's much more important is the How-Factor on how to adapt stuff. Here emacs is like Linux: everybody has an own set of extensions and needs. I for example need the company mode and tab-completion:

What's important here is: think of a B-tree and traverse it. At a position where your word can only end in a small variety of ways hit tab. That makes the editor actively support your code, because it reduces typos. Like omni-complete for vim.

Get the work done!

After you spent some days/years/decades defining your own Linux you'll be very fast doing your stuff. "I just have to add a small kernel extension... and voila...". emacs is very similar.
There're many nifty extensions - some aren't very IDE like. For example some Python IDEs have much better completion. Or VisualStudio has much better .Net support. And you won't have a lot of fun if you edit your files with emacs and reload them in VS. - Even if your versioning system is git or something. But you don't do LaTeX in VS, or ANSI C. You don't integrate your CAS into it. I scroll through RFCs with w3m-emacs while next to is there VisualStudio wainting for more code. There's no need to type down the concept directly into VS or Eclipse.

Active editing isn't a concept that just relies on emacs. Or vim. Or VisualStudio, or Eclipse. The concept can easily be demonstrated on any IDE, editor or within any working environment. Active editing means to rely on a set of Macros, shortcuts, configs and snippets in order to work faster and more effective. It means to separate editing from feeding directly into production environments. And these separated active editors are comfortable, fast and productive in a personalized way.
- You can extend vim with SuperTab to do the same... or with NERDtree. Or with csupport.

The choice of your active editor however has to fall on a very configurable software. Not ed ;).

Have fun,
wishi