[viksit]

As someone who uses emacs purely for clojure/lisp and vim for everything else, the biggest feature for me is the fact that this will be the first version of emacs to support menus in terminal mode. So for all the commands you don't remember, a menu is now a click or F10 away. To quote,

"Emacs now supports menus on text-mode terminals. If the terminal supports a mouse, clicking on the menu bar, or on sensitive portions of the mode line or header line, will drop down the menu defined at that position."

More at: http://www.masteringemacs.org/article/whats-new-in-emacs-24-...

[cies]

Have you tried Helm in Emacs? For me it binds to M-x, and I can find a "lost" command by typing just bits.

For example "M-x tree undo" show me "undo-tree-visualize (C-x u)".

Now I use Helm all over the place: (recent) file opening (within the current project), buffer switching, grepping, etc. It really changed how I interface Emacs.

[csdrane]

What's the advantage of Helm to Ido?

[ludwigvan]

Helm by default ands the query terms. Notice how he typed the second word first. Ido searches linearly. Helm is also much more ambitious in general

[rando289]

I prefer smex for M-x command matching (which is self described as Ido-style).

[tuhdo]

I wrote it in my guide: http://tuhdo.github.io/helm-intro.html#sec-2

[linuxfan]

Just curious. How did you manage to use both emacs and vim? I've seen that people accustomed to one editor are usually averse to using the other.

[inclemnet]

> I've seen that people accustomed to one editor are usually averse to using the other.

I think this is more a meme than necessarily a reality - you'll tend to see a lot more comments online from people who think the old joke is funny or who want to validate their own choice than from people who don't care or have tried both without such strong feelings.

In reality, there's really no barrier to 'manage' to use both emacs and vim. If anything, since they're both powerful and configurable programs whose best configuration is personal and some way from the default, it probably is harder to construct your own perfect config in both than for simpler alternatives like web browsers - I guess this may lead to a practical aversion.

Personally, I think vim's modal editing is superb but generally prefer the behaviour of emacs' modes and client model, so I use emacs with evil-mode but have no problem using vim if necessary.

[Argorak]

I'd sign that. I never use emacs, because I never trained it, but I sometimes use it at a friends machine.

It's nothing I find bad or not understandable. All errors stem directly from my lack of skill. (and the different key layout of most of my colleagues)

[viksit]

Hehe because I don't subscribe to monotheism? ;) I prefer vim's modal editing mode and have been using it as my primary for as long as I can remember. For clojure/lisp, I found that the vim tooling was just not as elegant/efficient as emacs (fireside et al arent as nice as cider/swank), and decided to learn how to use it. It's not that much of an "antipattern" because the keymaps are very different. I don't like using vim mode within emacs either - for some reason I find myself thinking in emacs mode when editing lisps. I do think that I could be more productive in emacs if I invested more time in the tutorials, but so far it hasn't been an issue. To me, it's more like needing to know how to use Eclipse or IntelliJ to program in Java since their tooling is so great.

[methehack]

You might consider checking out evil mode. It's for real. Does not feel like emulation at all.

[viksit]

Ah, will check. I'm not sure how it will coexist with all the cider key bindings though?

[catern]

It coexists pretty near perfectly, since vim and emacs keybindings are usually non-overlapping.

[MBlume]

Can you tell me more about why cider > fireplace? I'm a clojure developer working in vim, I've considered moving over to emacs a few times, and I'd love to hear what you see as the advantages.

[viksit]

@MBlume - first and foremost, the installation process for me for fireplace was fraught with issues. I installed lein.vim, fireplace, and a bunch of other stuff from all the allied projects : as much as I love vim, it was too much overheard for me to just go through all that! Once I did get it working (and after having worked with emacs/swank/lisp before) - it was just very unintuitive to me. It also feels much slower than cider, and doesn't offer things like the inspector for stack traces and things that cider can. Most importantly, I think the inferior mode in emacs is just a pleasure to use in terms of functionality - I've used it with R, lisp, clojure, and ipython. It's a very neat/clean interface.

There's also the fact that all of these modes are a simple M-x-package-install <package-name> away and they just work. It's kind of like choosing OS X for me after using Linux as my main OS for years and years - I didn't have to worry about the wifi card not being detected or my dual screen display needing a lot of kernel modules : things just work :)

[mwfunk]

Not really. There are lots of people who get off on imaginary rivalries and enjoy exaggerating the virtues of what they like and the flaws of what they don't like. Some of the more self-aware people know what they're doing and consider it all in good fun, but the dumb ones just go along with it because they actively enjoy engaging in tribalism.

See also casual sports fans who don't understand the game they watch, but understand and enjoy pretending to love one team unconditionally for no particular reason, and hating another team for no reason other than it's fun for them to hate somebody. Ditto for operating system fanboys of all stripes.

[qubitcoder]

I typically use Vim for quick edits on my Mac, and especially on remote boxes.

But for Haskell and Clojure development, it's hard to beat the tight integration features that Emacs provides (e.g. quickly piping your code or a single function to the REPL for testing). Vim is not designed for this; there are plugins available to approximate it, but it’s a bit hacky and nowhere close to Emacs).

Honestly, it's not hard to learn the basics of both. If you're accustomed to Vim commands, Emacs has `evil-mode`. There's also the slick `god-mode`, which is like Vim's Normal mode for Emacs.

Both tools are great in their own ways. Personally, I regularly use and love them both.

[reirob]

How about yi (https://github.com/yi-editor/yi)?

I hope some day an editor, written in Haskell, allowing to emulate Vi and and Emacs behaviour will become more appropriate for Haskell programming than any other editor and offer you to either the Vi or Emacs style.

[JoshTriplett]

Personally, I started out using Emacs because I wasn't a big fan of the "modal" style of vi (insert/command mode). Later on, I started pair programming in shared GNU Screen sessions, in which we ran vim; a pile of "how did you make that change so quickly" questions later, and I ended up switching to vim for the speed of basic text editing tasks, which save more time than I lose by not having as many high-level mode-specific commands.

However, I still use Emacs for LaTeX documents via AUCTeX, because I find it far more powerful for basic editing, with commands to insert directives, environments, \item, etc.

[chetanahuja]

' "how did you make that change so quickly" questions later, and I ended up switching to vim"'

Heh... what a perfectly beautiful little invitation to a flame-war. If it was about 5 years ago, I would have fallen for it in a minute ;-)

[nocman]

It didn't sound like an invitation to a flame war to me at all. It sounded like his honest personal experience.

[KC8ZKF]

If you are a Unix user, you almost need to know enough vi to edit a simple file. crontab -e is considered a minor sin in the Church of Emacs, but only a minor one.

ESC:q!

[MereInterest]

export EDITOR=emacs

Then crontab -e will start emacs instead of vi.

[TeMPOraL]

Try:

    export ALTERNATE_EDITOR=emacs EDITOR=emacsclient VISUAL=emacsclient

and set up Emacs to run (server-start) on startup.

This way, crontab -e should open a new Emacs frame (or start Emacs, if it isn't already running). It will speed things up and make the experience better, while giving you access to all the things you're working on in an already running Emacs.

See also: http://www.emacswiki.org/EmacsClient.

[ams6110]

If emacs is installed. It often isn't. vi almost always is.

I know enough vi to open a file, move up, down, left, and right, search, delete and insert text. And I often run afoul of my emacs muscle memory just doing that. But you really need to know the vi basics if you admin unix machines.

[teddyh]

I’ve learnt enough ed to use that instead of vi. If that isn’t installed, I’ve had to resort to nano, and, in rare cases, sed --in-place. But I never need to know vi.

Of course I realize that this is mostly me being silly, but it’s also rather educational.

[KC8ZKF]

You are absolutely right. Especially if we are talking about BSD or Unix proper. But, there is a cognitive load to remembering what machine you are on, or if certain variables have been set and so on.

I have been on machines that fire up nano with crontab -e, in the name of user friendliness. These same machines will not respect EDITOR or VISUAL anyway, so I have no idea what to do about them. I usually just get up and creep away making sure not to turn my back on them.

[dunham]

I used both back in college. I usually used XEmacs for coding and reading mail/usenet and vi for sysadmin stuff. These days I've moved on to IDEs for coding and only break out emacs for editing binaries or large files.

It worked out pretty well as long as I used Emacs in an X window and vi on the command line. But if I ran emacs in a terminal, I automatically started typing vi commands into it.

[cies]

I use Evil for that: Vim-style editing in Emacs, best of both worlds.

[kstrauser]

Emacs has had console menus for years. The difference is that they're now clickable, not keyboard-only.

[viksit]

Right - but the fact that they behave more like a window manager menu than ever before - as in, they drop down et al.

[rezistik]

As a dev who's always used Sublime/Atom and sometimes Vim, what's the benefit of Emacs for Lisp?

[malisper]

Slime is really amazing. It provides tons of features of which here are a few (these work with Common Lisp, I have no clue if they work with Clojure).

Inspector[0]: You can click on objects to "inspect" their values. This includes hash-tables, arrays, and closures. In addition you can execute arbitrary code on these objects at any time, even while a program is running.

Trace Dialog[1]: Most Lisp implementations already provide a way to trace procedures. Tracing normally consists of printing the input and the output as each traced procedure is called. Slime provides something much more powerful. Slime's Trace Dialog is similar to trace in that it creates a buffer of the input and output, but instead it is provided in a tree menu format. In addition it is possible to inspect all of the values in the Trace Dialog with the inspector.

Debugger[2]: When an error is thrown in a program, a window pops up which provides several things. You can click on a stack frame to see all of the variables in that frame and then inspect those variables with the inspector. You are also provided with a list of restarts[3]. In addition, you can return a value from a given stack frame, or retry a procedure call on the stack frame (you may have modified the definitions of some procedures before you did this), and have the program continue as if nothing had ever happened.

There are also many other features, such as the ability to macroexpand code by clicking on it, to look up every procedure which calls a given procedure, to look up every place in which a given variable is set, and many other awesome features.

[0] http://common-lisp.net/project/slime/doc/html/Inspector.html

[1] http://common-lisp.net/project/slime/doc/html/SLIME-Trace-Di...

[2] http://common-lisp.net/project/slime/doc/html/Debugger.html#...

[3] http://en.wikibooks.org/wiki/Common_Lisp/Advanced_topics/Con...

[TeMPOraL]

Restarts are feature of Common Lisp, for which SLIME only draws a powerful interface. Your ability to return a value/retry a call from a given stack frame is just a bunch of default restarts of your CL implementation. What is really awesome is that you can add your own restarts to the interactive debugger. Or have them execute automatically.

I recommend those who are not familiar with conditions/restarts to read up a bit on them. This is something like exception handling, but an order of magnitude more powerful.

[lispm]

> Your ability to return a value/retry a call from a given stack frame is just a bunch of default restarts of your CL implementation.

Almost. Restarts and value/retry on a stack frame are mostly unrelated - Restarts are only the UI for implementation specific features. Common Lisp provides no feature to retry an arbitrary stack frame. This is all implementation specific functionality provided by SOME implementations.

[logicchains]

That actually sounds a lot like Smalltalk.

[malkia]

Also the editor does not crash if the (lisp) environment becomes unstable (hangs, crashes, etc.) - Such things rarely happen, but they might - for example in Lispworks (which has emacs-like IDE (very nice) but runs the lisp threads in the same process as the editor).

[craigching]

I can speak about Clojure support for Emacs a bit, but I don't know how much of this Sublime or Atom can do.

I like the cider+nrepl workflow myself. You can edit your code, reevaluate it, and test it without having to restart your JVM. As you can imagine, this really speeds up development.

Also, though I haven't quite grokked all the barfing and slurping yet, paredit has really become a huge part of my code writing and editing in Emacs for Clojure code. I am on the cusp of getting barfing and slurping working for me now ;)

[viksit]

There's quite a lot of technology that allows you to write lisp/clojure very well in emacs. Some that come to mind,

- Swank/Slime (Lisp inferior modes) that allow you to write lisp, evaluate within the editor, see your results in a buffer. Offer auto complete, refactoring, debugging et al.

The more recent nrepl and cider modes for Clojure build on top of slime/swank and offer extremely great tools to write code as well. If you ever wanted to have the REPL running on the side and have great interop between code in a file and the REPL - these modes are great. Imagine their power when you can connect into a running webserver and debug on the fly from within your editor.

- A lot of original emacs plugins like paredit have now been ported to other platforms like Sublime. Also, emacs itself is written in lisp, which makes it a first class language it supports at its very core.

[Havvy]

Each lisp varies dramatically in its semantics. Just because emacs is written in e-lisp does not mean it has first class language support for every other lisp. Would you say that vim has first class support for every language with block & statement based languages?

[viksit]

Agree with your high level point. Mine isn't that because it's written in e-lisp, emacs supports every other lisp. The fact that it's written in e-lisp makes it very extensible, and some standard things like C-x C-e to evaluate forms et al, which were originally developed for and are the standard for e-lisp, have been adopted for all other lisp modes as well. The very fact that the editor is written in a lisp makes it expose useful functionality this is useful in other lisp contexts.

[TeMPOraL]

Aside from all the other reasons other people already listed, there is a one fundamental benefit. Emacs is not just an editor, it's a Lisp runtime with text-editing functionality bolted on top. Lisp is natural for Emacs at all levels of complexity - from the fact that it's easy to work with Lisp code using Lisp to the Emacs community, composed in a big part of Lispers. Lisp just fits Emacs.

[BostonEnginerd]

Emacs is pretty much a built in REPL primarily written in Lisp.

[wglb]

Slime

[knome]

I hope this terminal mouse business is easy to disable. If I wanted mouse clicks to be registered by emacs, I wouldn't insist on installing emacs-nox versions in the first place.

[ams6110]

M-x apropos is usually good.