Hacker News Reader

Comment by gexla | Hacker News Reader

Vim has the keyboard entry conquered. Emacs may come close enough, but if we are talking photo finishes to races, then I think Vim always edges out emacs by a hair or more (but still misses a lot which Emacs provides.) We will have to get a totally different interface for entering text before Vim is knocked off its perch.

Emacs has a much better Vim mode for me than SublimeText 2, but neither can really give you Vim. The deeper you are in the Vim rabbit hole, the less likely you will be to return to try anything else.

Emacs wins out against everyone for scripting.

There is one other reason that I knew would always keep me in the Vim and Emacs world. At first I couldn't figure out what it was that bothered me about SublimeText 2. Vim and Emacs is open source! I don't see this point mentioned in arguments for or against but this is important to me.

View on HN

The thing about Emacs is really its extensibility. There is simply no other text editor out there that can open a single C/C++ source file and automatically infer all tags (even of included headers) without any kind of project set up. That is simply awesome and to my knowledge only available with semantic-mode in Emacs.

Vim can use ctags or cscope or clang, but that is not the same thing. These are great tools, but they need to be set up with the correct include paths and they need to be run regularly to be useful.

To my mind, that is what makes Emacs so unique and powerful and that is something that really, no other program can hope to accomplish in a short time frame (sorry, Sublime Text).

That said, Vim hands down beats Emacs when it comes to pure text editing speed. It's keybindings are just a lot more powerful and flexible than Emacs's. And of course, that is what evil-mode is for. It emulates a subset of Vim in Emacs. It is by far the best simulation of Vim I have ever seen (judging from ViEmu, Viper, Vintage, Vico and Vimpulse), but it is not the real thing. Plus, there are lots of great Vim plugins that do not work in evil-mode.

I, for one, use Emacs and Evil and I am happy with it.

And I hope that Sublime Text will provide a potent entry-level drug for the next generation. But really, without open sourcing it at some point, I can't see it catching up to The Big Two.

> There is simply no other text editor out there that can open a single C/C++ source file and automatically infer all tags (even of included headers) without any kind of project set up.

The SublimeClang plugin for Sublime will do this, pretty much. You may have to add a few paths to its global or per-project config file, but that's pretty obvious considering that it needs them to parse referenced files. It works extremely well, giving you autocompletion of any C/C++ symbol as well as automatic compilation error indicators.

That is precisely what I am saying: Other editors interface with some tools, you configure them, they call some external process, they have to be run regularly...

Well, Emacs has that stuff built-in, and better. That is precisely the way in which Emacs is more powerful than Sublime or Vim.

I would rather have just the plugin.

The modularity means that the core application itself is small and simple, with fewer moving parts than something huge like Emacs. It also means that I have the freedom not to install something that would otherwise come bundled with/tangled with the app. Everybody wins.

SublimeClang requires a minimal amount of config, is dead easy to install, and it relies on external toolset by design, because building everything in would be insane. I very much prefer that Sublime does not come with this functionality.

(I don't know what you mean by "have to be run regularly", btw. SublimeClang can run continuously and transparently.)

You misunderstood the parent post.

Emacs doesn't come with everything built-in. But when you extend Emacs, you usually do it entirely in Emacs with Elisp. Emacs libraries rarely call external tools - they usually implement the tools inside Emacs.

I don't think I misunderstood the parent. The parent heavily implies that Emacs' semantic mode simply works out of the box.

I have no idea if that's the case, but if it's not, there is no functional difference between that and any other editor, where you need to install a separate plugin.

Sublime itself can be extended with Python. To me, that's a better solution than a proprietary (albeit Lisp-based) language.

Whether those plugins "call external tools" or not is of little importance, although relying, in a modular fashion, on pre-existing software is more Unixy.

I'm sure Emacs' tag system is powerful, but personally, I would rather have something like SublimeClang, which is built on a high-quality, highly maintained C/C++ compiler toolchain that retain type information and so on, than some kind of tag system based on a superficial parser designed purely for code inference.

You did indeed misunderstand my post. I was not arguing about the relative merits of clang vs some-other-tool.

I was simply saying that Emacs can open a C++ file and have all tags and completions right there, no setup required. No external application required either. That is the power of Emacs and that is a power not available to Sublime Text (unless you write your own C++ parser in Python).

You see, clang is an awesome tool and I'm sure its integration in Sublime Text is very good. But by its design it can not look for headers in appropriate locations without someone explicitly telling it to do so. Also it can not parse partially erroneous code. Both these actions are just not sensible actions for a compiler.

And that is why no external tool can ever provide the integration and practicability of a tool purposely built just for parsing code for Emacs in the same way cscope can not match the integration of Visual Studio's C# parser in Visual Studio.

I am not arguing the merits of Clang versus some other tool, either.

I am arguing against the claim that a monolithic app like Emacs that bundles a specific tool is somehow qualitatively superior to any other tool which does not bundle a specific tool.

> But by its design it can not look for headers in appropriate locations

I think that's a perfectly valid design. I would rather want to spend 10 seconds adding a path to my project's config file than spend an eternity with just ctags. :-)

> Also it can not parse partially erroneous code.

Of course it can. Clang recovers from partially invalid code just fine.

For example, if I do something like "typedef enum { a, b, 3 } foo bar;" (constituting two syntax errors), it will still correctly autocomplete "foo" as well as its values, even though the type is strictly incomplete.

Emacs is anything but monolothic. I think that is what our argument boils down to.

Emacs is a Lisp virtual machine and someone happens to have implemented da rather splendid text editor in it. Claiming that Emacs is monolithic is about as meaningful as calling the assorted programs that make up a Unix environment monolithic.

I agree, especially after witnessing TextMate go stale and TextMate2 start to follow the Duke Nukem Forever release schedule. When I see a project like IntelliJ, I'm confident they will be around awhile. Looking at TextMate and SublimeText... I'm a little hesitant. The development muscle doesn't appear very robust. If a lead developer (or the only developer) gets hit by a bus is the project going to disappear?

Being open source doesn't change that. Lots of open source project have gone stale or abandoned after one or more key developers lost interest.

Unless people are going to step up and take the lead, being open source means nothing. If you want some assurance in this area it should be:

1) project is open source AND 2) project has a HUGE community AND 3) there are > 2-3 key developers

(I added (2) because even hugely successful open source projects where abandoned and left in the cold when most members of the core team decided to try something different. Like, how, D (the language) was abandoned for D2 (the second, different implementation).

I recently switched from Emacs to Vim, because Emacs is pretty much unusable on an iPhone or iPad. Vim seems pretty good on a touchscreen. There are things I miss but as a former Emacs snob I'm pleasantly surprised at how powerful and extensible Vim is.

I switched from emacs to vim because I was tired of typing `git commit` and waiting 3-5 seconds for emacs to finish launching and setting up. Since switching to vim I've installed more vim plugins than I ever had in emacs, and yet I can still launch gvim (not just vim, but the GUI version!) in a fraction of a second.

I just always have an emacs running, and use emacsclient to open files in it. Anyway, if you're typing "git commit" you may not be using the capabilities of your editor to the fullest.

I've never found an in-editor git interface that I like better than the command-line (although I am aware that Fugitive is considered to be extremely good). Besides, I do a lot of work outside of Vim. In fact, most of my work is outside of Vim, because most of my work is done inside of Xcode.

Reply on news.ycombinator.com