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.
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.
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.
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.)
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.
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.
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.
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.
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.
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.
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.
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]
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.
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.
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.
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.
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...)
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 :)
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
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
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?
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)
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...
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++.
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.
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?
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.
/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:
I love emacs, but it seems like most of my programming for pay is trending towards languages where there is a huge advantage to using a "modern" ide. I'm talking mainly of java/jvm languages and objc here.
I don't expect emacs (the community really) to all of a sudden provide awesome packages for that type of development, but it saddens me that I get more locked in to these other ides that I don't view as generally superior.
At least for Java (and probably most other languages) (emacs-)eclim can leverage Eclipse functionality (for Emacs, Vim, ...). So you'll get the same completion, refactoring methods and so on.
It would actually be cool to have a ninite.com for Emacs configurations, where one could choose from the best pre-configured crowd-sourced Emacs versions for several use cases and platforms (e.g. web-design, Java-programming or reproducible research). Sure, extending Emacs from scratch is fun, but many people are probably reluctant having to spend many hours to achieve a good configuration because they are not guaranteed to benefit from the result.
But you then need eclipse installed also right? I use intellij for my java needs and it makes me content the bulk of the time. Having used emacs + jdee back in the day I'm afraid of the lost hours to trying emacs+<insert hack here> again.
Yes, that's also one of the reasons I didn't pursue this, the other one that I wanted to be able to use other peoples machines (including shortcuts etc.) as well.
It's a tradeoff; Eclipse has a lot of understanding of the different languages, which seems to me is not really worthwhile to rebuild in Elisp if you can just reuse it this way.
I work on Android at Facebook. I write a ton of C++ and Java for that environment. I use Emacs to do it and have no problems aside from the occasional cc-mode bug.
Then again, I don't care much for autocompletion. I started on a IntelliJ Emacs integration a few months ago: the idea was to run Rhino in an IntelliJ plugin and have IntelliJ and Emacs talk to each other using JavaScript. I got as far as getting completion working, but decided I didn't need it. If there's a real need, maybe I can dust off this "bad-idea mode".
rms wouldn't let them in because he (via Moglen?) thought they would undermine the copyleft. That was worrying as a design criterion was to make them (almost?) equivalent at compile time and after loading to things built into the Emacs core normally, so that derived work status should be clear in a court.
Perhaps eventually someone will re-do other things, like replacing the GC.
Concurrency in elisp would bring the benefits that Chrome brought with it's thread-per-tab design. I feel like I'm in the 80's when I can't touch my other windows while the repl gets loaded; and crossing my fingers that it doesn't crash emacs.
I honestly don't understand why many such services aren't designed as APIs that any editor can interact with via an API. TernJS is an example of a tool that takes this approach[0]. Just make the solutions for each of the problems needing to be solved LISPy. Wouldn't it be great if one day other editors are using LISP based language tools via API in their text editor of choice.
I switched to nognus for better speed, and recently made the jump to mu4e with offlineimap. And I'm already in love, so fast and non-blocking when refreshing emails! Of course, I could have had offlineimap with gnus, but it was a tedious setup (when I checked) and mu4e was quite a breeze. Local indexed search is so good I'm don't care that much now about filing emails anymore.
One question for long time Emacs users - do you notice any significant changes compared to e.g. 10 or 20 years ago versions of Emacs? Same question applies to vim users I believe...
Like, for instance, there are huge advancements from MSVC 97 to MSVC 2013...
* --daemon with emacsclient was a big improvement in usability (ie. "instant startup" by keeping it running all the time)
* As others have said, there's been a surge in elisp packages lately, thanks to package.el and friends
* Changing color themes and fonts used to be a real hassle, but no more.
* Unicode (and bidi) Just Works now, no magic incantations in ~/.emacs needed any more
* org-mode! Ten years ago, org-mode was just started and not yet a part of Emacs. I think I first installed it as an addon around 2005, but at the time it was quite barebones compared to what it is now … (and of course installing it and keeping it up-to-date was a lot more work than doing the same for any third-party package now).
Have been using Emacs since 1991. Most of the things I like about Emacs, e.g., it's "self-documenting" nature, have been there since I started using it.
My personal opinion (as someone who uses the mouse a lot with Emacs) is that the most important change was the addition of the ability for Emacs to interface with the user through "window systems" (namely, X, Windows, Mac) which reached non-beta status in 1994.
(I'm ignoring the XEmacs fork since I never used it full-time.)
This allowed using the mouse much like it is used in e.g. TextEdit.app and added many possible key combinations (like Control-space and a "real" Meta key) that were not possible to express using the old terminal-based user interface.
Other important changes: high-quality ports to Mac OS X's window system in the early 2000s; the addition -- finally on 30 Jul 2009 -- of non-beta support for anti-aliased text when Emacs interfaces through the X windowing system. (Anti-aliased text was supported on OS X and on Windows much earlier than that -- probably as soon as the ports to their graphical interfaces became available.)
With the release of Emacs 24 a few years ago, a definite clunkiness around non-ascii character sets finally got sorted out with the result that most users of Emacs no longer have to think about coding systems and such.
About 10 years ago, it became possible to click on a "link" in the buffer that shows the docstring to an Emacs Lisp function to go right to the definition of that function, which was a nice new feature.
package.el excites me not at all.
And I'm very skeptical that the addition of threads to Emacs will improve it. I think it will prove an unnecessary complication.
As a user of Emacs for about 18 years, the answer is absolutely.
In recent years, since 23.0, it feels as if Emacs has improved a great deal. This is largely due to the introduction of package.el (extension / package management.) To put it in slightly more dramatic terms, it's revolutionized it.
Off the top of my head I can't think of any major changes that have really impacted my use of Emacs, but there have been a lot of smaller changes that made my existing workflow smoother, or look better, or faster, etc
To be fair, I've customized my .emacs to be just how I like it, and it usually "just works" for me, so I don't change it much any more. It's entirely possible there are a ton of great new features that I just haven't bothered to look for yet.
Also, when I make changes I don't check to see when the feature was added, so it's possible I'm using new features, and I've just assumed they've been there forever and I just hadn't discovered them until recently :-)
The only thing that has changed in my setup has been the discovery of ido-mode - http://www.masteringemacs.org/article/introduction-to-ido-mo... - but I've no idea when that was actually added to emacs, it could have been around for a decade and I just never knew of its existence!
I think that with either emacs or vim, once you have got a useful setup you tend to stick to it, so discovering new features is uncommon (and both apps don't make feature discovery easy in the first place.)
While others have mentioned UI changes, I want to highlight recent core improvements. Emacs Lisp is now a much better language. In particular, we have:
* lexical scoping and fully correct lexical closures
I'm not sure the bare executable is what most people consider to be Emacs (well not its users anyway!), since the large percentage of the code is emacslisp.
With bare executable I mean just a bare, recently downloaded emacs with no additional libraries. Emacs is understood to be together with its accompanying libraries.. I think even find-file is implemented in emacs-lisp
Some great features listed for Emacs 25, sounds promising.
Personally I hope that Ergo Emacs can be merged into the main Emacs branch, as an alternative keybinding option (not a mode). Some might say, why not just use Ergo Emacs? The way I see it, it's too much work for a small group of developers to create new key bindings for all Emacs packages. By moving it into mainline (as an option), package developers know the option is available by default and can choose whether they want to support it.
I somewhat doubt it was anything to do with me mentioning a version number, and all to do with having the audacity to suggest I'd like a comprehensive keybinding alternative (it's the weakest element in Emacs, in my personal opinion).
What I want from Emacs 25 is to not have to use vi when I want to edit a large file without line-breaks. Okay, maybe I need a more powerful machine — but I shouldn't.
It's no big deal, but if it is not the speed of scrolling, then I do not understand what it is about Emacs that discourages you from using it on large files without line-breaks.
