[ed0]

I personally use Vim but I like Emacs as well. They are both great. But they are getting old and it shows. Compare them to the super nice text rendering of ST3. I understand one cannot use ST3 from the terminal but that's fine. I can continue to use vim in that case. But 99% of my time is spent in graphical environment and I want a modern editor with nice font rendering and all. But still, IMHO Vim and Emacs are better text editors than ST3. Why can't we have best of both worlds? Implement core vim functionality as a backend service and provide a modern frontend with nice rendering (by using Skia for example). Same goes for Emacs. It's time to move on but keep the best of Vim and Emacs.

[pmoriarty]

I don't use Sublime Text, so I don't really understand what's so great about its text rendering.

But.. how great can it be?

Both vim and emacs (and the terminals they run in) can use the fonts that your operating system has available on them. So what's the problem? And how is that inferior to what you get in Sublime Text 3?

Genuinely curious.

Second, while a nice look is great and all, I'm more interested in sheer power, not eye candy. I guess I'm more of a function over form guy, and both vim and emacs could look a lot worse than they do now and I'd still prefer them over virtually any other text editor out there.

If there's something that other text editors can do that makes them more powerful than vim or emacs, I'd love to hear about it. That's happened in the past. Sometimes there's been some feature that they don't have. And usually, not much later, vim and emacs both clone that feature.. absorb and expand, and move on.

[melling]

I find it much quicker to navigate buffers in Sublime. Code completion is usually built-in, both html and variable names in whatever language I'm developing (eg div<TAB>). Multiple cursors are great too.

I'm sure Emacs has modules for whatever or I could build it, but why waste the time. I'd rather pay someone to provide a solution that saves me time. I still keep emacs open for macros. Emacs is great for defining a keyboard macro and repeating it's 1000 times.

[barrkel]

Emacs's keyboard macros are one of its weaker areas, IMO. C-g cancels recording, but if you accidentally invoke the wrong command and end up in a minibuffer prompt, C-g is the reflexive way to get out of it - terminating the record. So you need to enter your command sequence with zero errors and no use of C-g for it to be of any use. I find multiple cursors more usable in practice, since you can see the results of various navigations simultaneously (at least for those instances that are visible on screen).

I use emacs because it functions the same on Windows, Linux, OS X and Solaris, all the platforms I use across work and home. I use it in the terminal rather than the GUI, because then it functions the same whether over ssh or locally - and no, TRAMP is not quite good enough. And finally, I use emacs because I've had it with learning a different IDE every couple of years. At this point, I want to invest my muscle memory and macro library in something with some longevity. I want something where getting my settings and modules all installed is no more effort than a git clone.

If I could pay someone for something that did all this for me, I would, but the solution would look a lot like emacs: highly scriptable, with a consistent terminal interface across all 4 platforms I use. Ideally it would use a much stronger, faster version of Lisp, although its dynamic scope lookup is actually convenient for layering new behaviour on top of existing code.

(On switching buffers, I use helm + projectile, which does incremental filtering search over file names. For navigating projects, I find helm-git-grep is often more useful than trying to remember a file name - this is an incremental regex search across the whole project, using git grep. No other IDE I use is quite as quick to switch buffers as my emacs config.)

[melling]

Multiple cursors only seem to work for simple things, which is good enough a lot of the time. However, incremental search in a macro is very useful, for example.

C-( do-searching-ESC-deleting-etc C-)

There's a new Emacs StackExchange: http://emacs.stackexchange.com

Maybe it'll become enough of a database that it'll be much easier to figure out how to add the "missing" features in Emacs. Currently 720 questions. Let's see how often it's used.

[barrkel]

What you would do with an incremental search inside a macro, I'm much more inclined to do with a regex search and replace. I generally only use search at the end of my macros, to find the next "instance" that need to be run over.

[pmoriarty]

I don't know about vanilla emacs (because I don't use it), but when using emacs in evil-mode, you can record a macro to a register and then edit the register. That way you can correct your mistakes. You can also append to registers and combine registers, so you can continue recording macros where you left-off.

Since evil-mode is a vim-emulation mode for emacs, the above is possible in vim as well.

[barrkel]

You can dump your macro to elisp without difficulty. That isn't the problem. Keyboard macros are at their best when you get to use all the regular keys that you normally would, so that you can reuse everything you already know, without having to learn a whole other set of commands. Both editing the resulting macros, and needing to treat C-g as fatal, break this.

[quotemstr]

I tend to jump straight to Emacs Lisp for anything more complex than trivial keyboard macros. It's well worth learning how to perform text manipulation in that environment.

I once programmed Emacs to convert an entire component of Windows Phone from Hungarian notation to something saner.

[barrkel]

I do too. Trivial macros come up very often when I'm using editors other than Emacs - I'd typically create and play back one every few minutes in other editors - but far more rarely in Emacs. Like I said, multiple cursors fills a very similar hole better, because it's not as sensitive to a C-g in the minibuffer.

[pmoriarty]

I don't know how much faster navigating a buffer can be than doing it in emacs or vim, both of which can switch buffers with the press of a single key and do fuzzy-matching of buffer/file names with a keystroke or two. They can also navigate by moving or clicking around tree-structured directory trees, through menus, and many other ways.

Again, it would be nice if people offered specifics when they described something another editor could do that emacs or vim allegedly couldn't. How exactly do you navigate a buffer in Sublime that's allegedly "much quicker"? Can you give an example (including exactly which keys you press and exactly what it does in response)? Or can you at least show a video demonstrating this navigation?

As for multiple cursors, both vim and emacs have had them for years.[1][2][3][4][5]

[1] - https://github.com/terryma/vim-multiple-cursors

[2] - https://www.youtube.com/watch?v=Umb59mMvCxA

[3] - https://www.youtube.com/watch?v=NYzGBnsJ-eg

[4] - https://github.com/magnars/multiple-cursors.el

[5] - https://www.youtube.com/watch?v=jNa3axo40qM

[melling]

Cmd-t to be prompted with a list of buffers in the most recently visited order. It has a filter too. Sometimes I just look at the nav buffer on the left. Kind of depends.

What's the fuzzy match in Emacs? C-x b?

Why don't multiple cursors ship with Emacs? I'll give it a try.

[pmoriarty]

In emacs, I use helm[1][2] and BufferSelection (aka "bs")[3] to do the same thing, only helm is much more powerful and does a ton more than just that. In vim, I use MRU.[4]

But neither emacs or vim are limited to buffer selection using this relatively primitive method (which I do like and use myself). You can select buffers using an almost overwhelming number of methods and plugins.

You can filter, use regular expressions, use timing, use fuzzy matching, by buffer contents, color buffers in buffer lists using various criteria, etc. Here are some options for emacs: [5][6]

Both vim and emacs can bind pretty much anything to any key, so you can use Cmd-t for any of those (or a function key, if you preferred something that requires only a single keypress) or virtually any other keystroke.

[1] - http://www.emacswiki.org/emacs/Helm

[2] - https://github.com/emacs-helm/helm

[3] - http://www.emacswiki.org/emacs/BufferSelection

[4] - http://www.vim.org/scripts/script.php?script_id=521

[5] - http://www.emacswiki.org/emacs/SwitchingBuffers

[6] - http://www.emacswiki.org/emacs/CategoryBufferSwitching

[ed0]

I am not too familiar with the technical details regarding the text rendering in ST3, but I can clearly see the difference between ST3 and Vim/GVim. At least on the machines I use (Desktop Archlinux & MBP OSX). Apparently ST3 uses Skia2d[1] for rendering which is what Google Chrome uses as well. Even for the text. But again, it's not just about the text rendering. ST3 is designed for the modern GUI and Vim/Emacs are not. What I want to see is the raw power of Vim + nice modern UI rendering/feel. It can't be that hard.

[1] - http://www.sublimetext.com/3dev (search for Skia)

[pmoriarty]

It would be helpful if you could precisely describe exactly what it is that makes ST3 look better for you than emacs or vim.

Saying that "I can clearly see the difference" and calling it a "nice modern UI rendering/feel" is too vague to be useful for improving emacs or vim in any concrete direction.

[bronson]

I can see the difference too. For whatever reason, text in Sublime with the same theme looks sharper than Vim (Yosemite). Maybe it's because it's not surrounded by ugly text rulers and inverse mode split bars, or maybe the text itself is actually sharper. Who knows? The programs are free, try it yourself.

Also, both Vim and Emacs feel really chunky and numb when showing completions and switching buffers. They take many hundreds of milliseconds to respond to keypresses, while Sublime responds close enough to instantly for me to not notice. It makes a big difference for something that's done hundreds of times per day.

(That said, I'm still using MacVim as my primary editor. The botched ST2->ST3 transition demonstrated above all else the danger of proprietary lock-in...)

[quotemstr]

> I can see the difference too. For whatever reason, text in Sublime with the same theme looks sharper than Vim (Yosemite).

It would help if you would send a comparison of screenshots to [e-mail].

[arthurcolle]

Is it really lock-in if the upgrade is a completely separate install?

[JonnieCache]

I imagine when neovim is ready we'll see frontends for it with all the optimised subpixel rendering you could ask for.

[warp]

One thing which annoys me about emacs is that it doesn't do threading or non-blocking i/o when saving a file.

If I save a file on a remote machine (sshfs mounted), it stalls the entire interface. I only use emacs, so I don't know if "modern" text editors are better at this, but I certainly expect them to be :)

[bearbin]

ST3 is no better at this, IME. When I edit files over SSHFS it at least freezes the file that's being saved, and maybe other files too.

[tazjin]

I'm not a ST3 user, so I'm curious in which way it renders fonts differently than other applications (and on which platforms)?

Emacs and Chromium are the applications that I spend most of my time at the computer in, and both of those go through the same font-rendering system (Infinality patched freetype) and look very nice. I also use standalone Emacs frames and almost never run it from a terminal.

Edit: I installed Sublime and took a comparison screenshot with the same font, however slightly different font weight and theme: http://i.imgur.com/UqwM0j2.png

[craigching]

What font is that in the emacs screenshot?

[tazjin]

As abrowne correctly identified, the font (in both applications actually) is Source Code Pro. I've been using that font since it was released and am very happy with it, same goes for the colour scheme: Gruber Dark

[abrowne]

Looks like Source Code Pro http://adobe-fonts.github.io/source-code-pro/

[gmcabrita]

I don't notice any font rendering differences from ST3 to Emacs with my setups [1].

[1] - http://a.pomf.se/ytaujl.png

[morekozhambu]

I see that you use ubuntu. What version, theme are you using?

[gmcabrita]

I'm running 14.04 LTS.

The theme is a modified version of Zukiwi-mac that has the new Yosemite buttons [1].

[1] - https://github.com/gmcabrita/dotfiles/tree/master/.themes/Zu...

[quotemstr]

I sometimes contribute to Emacs. On X11, we use XFT to render text. On Windows, we use Uniscribe. I suppose we could be using DirectWrite instead, but Uniscribe produces pretty good results.

What specific improvements would you like to see in Emacs text rendering? What is Skia doing that these very common system text rendering interfaces are not?

[chrisguilbeau]

I no longer use ST due to being in the terminal most of the time, but one thing I miss is how easy it was to write new packages with Python. Just enough of the API was documented and exposed to get what you needed done and usually resulted in a plugin with pretty good performance. It took very little time to write things I missed from emacs like "sort paragraphs", opening files by typing a path, an auto complete that uses a similar algorithm. Even a ctags module that I wound up prefering over emacs. I think ST's extensibility is easier than just about any other editor I've used (I do develop primarily in Python though)

[ufo]

I heard that the Vim architecture makes it hard to implement Vim as a backend service and that changing that was one of the big goals of the Neovim fork. Well have to wait and see how that works out in the long run...

[edwintorok]

How does ST3's rendering compare to GVim? You can select a different font for GVim, I personally prefer Source Code Pro for example.

[hrvbr]

It depends on the quality of your screen. On my previous laptop I had a high-quality WLED screen and ST3 looked clearly better than everything else on Windows. On my current cheap laptop however, everything looks quite pixelated anyways and I actually prefer the rendering of gVim or Notepad++.

[ed0]

GVim is not that bad to be honest, but in my experience ST3 is still better. It's not just the font rendering. The whole UI experience in GVim is lacking compared to ST3. ST3 has been designed for the modern UI environment and Vim and Emacs haven't. That's the point.

[edwintorok]

Can you point me to an article with more details on this? I use my text editor mainly from the keyboard, I very rarely use the mouse (it would be a lot slower), so the only reason to use GVim (vs a terminal Vim) would be font rendering / color themes. Does the UI experience you refer to primarily to mouse use, or something else?

[Shorel]

The mouse would be a lot slower for some users, not all of them.

I always hear that argument and my own experience makes me strongly disagree.

So, let's make an hypothetical example: In your own comment I need to select the text "would be font rendering". Using the mouse it took me all of one second to select it, and send it to the clipboard. May be a bit less, because I used to play Starcraft and I know my way around with a mouse.

I can look at some point in the screen, and have the mouse there in less time it would take me to count the number of words from my current cursor to the desired position.

Now it's your turn. Tell me how I can use the keyboard for exactly the same task and be faster.

Disclaimer: this is a real mouse and not the thing that laptops use. I can imagine a touchpad being slower.

[edwintorok]

In Vim I would do something like this:

  /fo<RET>vweobby

  /fo <RET> I use search to get me close to where I want to be
  v         I enter visual mode, I want to see what I'm selecting
  we        I select the words 'font rendering'
  o         I realize I want to extend my selection to the left
  bb        select 'would be to the left'
  y         yank the selected text

I didn't need to count anything and the in-progress selection was visible the whole time allowing me to make adjustments to it.

If you don't know all the Vim motion keys yet and don't like counting then you could also do it like this that requires very minimal Vim knowledge:

  /fo<RET><C-left><C-left>v<C-right><C-right><C-right><C-right><left>y

How would you extend the selection to the left with the mouse without loosing the already existing selection?

[JoeAltmaier]

There's the time switching from keyboard to mouse. The mouse is the enemy of fast typing.

[rasur]

I get your point but fwiw Emacs in a modern mac terminal is not completely horrible to look at.