If Emacs looked as good as Sublime, I'd be marginally happier. But if Emacs lost Helm or Magit, I'd be devastated.

- Significant performance issues

- Constant bugs - updates often break the package completely, especially if you're using the melpa version (melpa is another rant for another time - standard melpa is totally brain-dead)

- An atrocious version of "fuzzy matching" (you have to separate terms with spaces, which are then turned into ".asterisk" (can't type a single asterisk in HN comments) and everything's concatenated into a regex to match)

- The default helm-mode (what they recommend using for completing-read, which controls execute-extended-command, i.e. M-x, and such) is unsorted. Not badly sorted - unsorted.

- Doesn't use a lot of the standard layout functions, instead replacing them with its own stuff that can't be customized in a standard way.

- Dictatorial maintainers that only allows options and features that they deem the "right way" to do it. This is fine for some projects, but total control of my editing experience is the primary reason I use Emacs in the first place.

ido with a few simple plugins is vastly better, less buggy, more compatible, faster, has better matching, and is easier to customize. I recommend against using helm for completing-read unequivocally.

- There certainly are performance issues with helm, but setting gc-cons-threshold to a higher value helps my setup a lot.

- I update all my installed packages pretty frequently, and I just use regular melpa. I haven't really noticed bugs with Helm.

- As for the fuzzy matching, look into the "helm-flx" package. It gives you real fuzzy matching, much better than the default helm matching.

- I have M-x bound to helm-M-x, which is a better option than the default. Also, helm-mini is a better option for a buffer switcher.

I agree that Helm is lacking in many areas, but this guide made Helm work better for me: https://tuhdo.github.io/helm-intro.html

I haven't used helm-M-x. That may be better - but it doesn't solve the problem that everything else using completing-read is still on normal helm.

I typically use a small emacs window next to a terminal (or few - I don't run terminals in emacs) and browser in my tiling wm. Helm makes this nearly impossible, since it's very difficult to control where helm windows will go without using popwin (horrifically buggy) or shackle (I never tried this, as I'd already moved to ido by the time it showed up), because of helm's nonstandard way of doing things.

With regards to the bugginess, I can anecdotally say that I've seen more asking about problems with helm on the #emacs IRC channel than any other package - and there are several of equivalent popularity (magit, for instance). I also experienced numerous bugs while I was using helm, including some that broke my emacs config. The only package I've had break my config more than helm is org, but org generally works quite well if you can get it loaded without problems.

Popwin is very annoying for me, too. I'll look into trying out shackle.

There is also a less-popular completion system for emacs called ivy. I don't know how it stacks up to ido or helm, but perhaps that one is also worth checking out.

That's not true. Helm doesn't just insert .asterisk, which is why it supports out of order matching. If one searches for "file rename" Helm will find rename-file, while typing "filerename" in ido it will not find it. In ido one would have to do "file<C-SPC>rename"

> Dictatorial maintainers that only allows options and features that they deem the "right way" to do it.

Helm is already criticized by many ido fans for having too many features, now it's also criticized by ido fans for not having more (despite it having way more than ido).

> Constant bugs

This is because helm is constantly changing and improving. ido is not changing, and most extensions to it are very hacky.

I prefer ido, but helm is a good tool that's perfectly usable that tons of people like and does a lot more than ido.

I did forget it supports out-of-order matching, my apologies. Still, it does use a strange, difficult-to-use form of matching, and does not sort the results by default.

I use flx-ido, which supports out-of-order matching to some degree. This is not a knock on helm, as helm (now) has helm-flx, but nevertheless I consider ido's default much better than helm's, as ido at least sorts the results.

> Helm is already criticized by many ido fans for having too many features, now it's also criticized by ido fans for not having more (despite it having way more than ido).

I may have made this point badly, but it's not about features, it's about letting me use those features the way I want. I don't recall the exact discussion, as this was over a year ago, but I asked for the ability to change a specific default and was told "that's the wrong way to do it" - and I'm not the only one who's recounted something like that happening in the project. That's unacceptable for something I use in Emacs - I want to be able to change anything.

> ido is not changing, and most extensions to it are very hacky.

ido does everything I need it to, and works seamlessly with every package I've tried it with. If its extensions are hacky, I haven't noticed - my ido config has literally never broken, whereas when I used helm I dealt with things breaking constantly, and not because of the introduction of grand new features. I don't mind bugs due to newness; I greatly dislike bugs that are due to doing things in a non-standard, difficult-to-customize manner, combined with a lack of care towards not breaking things, which has been my experience with helm.

Helm has a lot more features. That's certainly true. A lot of those features are ones I wished I could have in ido. But in nearly every other aspect helm is significantly deficient, often pointlessly so. Helm had to have extra work put in in order to use custom non-standard windowing functions - extra work that makes the package significantly worse, IMO.

FWIW, I don't mean to say your response is wrong, and I don't mind that people use helm (I use helm a little, though only when I have to). If you can get helm working, and you like it, that's great. I just don't want new users to get disillusioned with emacs because of how finicky and frustrating helm can be - as I mentioned in another comment, I see more people in the #emacs IRC channel having problems with helm than with any other package. Helm is often proselytized without much warning about the issues I listed - I almost quit Emacs when helm, one of its "star packages" according to most Emacs bloggers, caused me so many problems.

  (require 'smex)
  (smex-initialize)                       ; is this needed?
  (global-set-key [(meta x)] 'smex)
  (global-set-key [(shift meta x)] 'smex-major-mode-commands)

I find ido unusable for find-file, because of how it splits up directory from filename. So I use the builtin completion.

But I rarely open files using find-file anymore. ido-use-virtual-buffers is magical. For commonly opened files it let you use switch-to-buffer whether the file is opened or not.

  (require 'recentf)
  (recentf-mode t)
  (setq recentf-max-saved-items 200)

  (setq ido-use-virtual-buffers t)        ; include recentf files

  (require 'yari)
  (define-key ruby-mode-map [(meta h)] 'yari-helm)

To be fair, most of my file opening is done with projectile, which, when you exclude the right files and use ido, works fantastically well. I can get to nearly anything I've been working on in two commands - projectile-switch-to-project (C-c p p) and projectile-find-file (C-c p f).

I'm not sure what you mean by "how it splits up directory from filename" - could you clarify?

ido-use-virtual-buffers is indeed awesome - I really love it.

Do ido-find-file. Now I see current directory as part of the prompt. Cannot C-a, C-b, Backspace, etc. within it.

After ido-find-file you can do C-f and edit the line like find-file does.

since switching from unstable to stable melpa, I've not had anything break.

it will do the correct thing, and it will give visual feedback. Also I can type

  M-x rev-bu RET

  ;; Ignore case when completing file names in minibuffer.
  read-file-name-completion-ignore-case t
  read-buffer-completion-ignore-case t
  completion-ignore-case t

  enable-recursive-minibuffers t

In addition, ido and flx-ido provide more efficient and faster (you don't have to manually invoke it) autocompletion than what you can get with prefix-based tab completion.

Also, I haven't had any issue with ido+TRAMP - everything works seamlessly on my end.

But beyond that, I find that a lot more stuff Just Works in Emacs. I spend my days working in Python, and both major Python modes for Emacs are miles ahead of ST's equivalents. Things like linters work as expected and there are lot more packages available for niche things. Emacs is subjectively better, even if the UI doesn't feel as platform-native as other editors.

I don't use Emacs because I'm a graybeard afraid to learn something new. I use it because I've tried every new hotness to come along and I've yet to find something as powerful, well-supported, and ubiquitous.

Meanwhile, if you're used to Vi's modal editing or Emacs's elisp, you're basically going to hate the other tools forever if for whatever reason. For example if you need IDE features for your project or the Vim/Emacs extensions for language X are no stable/flexible enough.

Ctrl+F for Find is a common standard, for example, but it's hit or miss whether this is Ctrl+F for Find (and that's your lot! Find & Replace is something entirely different), Ctrl+F for Find (and you have a checkbox for Replace), Ctrl+F for Find (and you have a checkbox for Replace... and this is how you search across multiple files as well). And there are multiple standards for all of these additional options. Your muscle memory will be useless no matter what you're used to. You're welcome to describe emacs as unusual... but don't assume everything else is a nirvana of UI consistency. The process of "just" switching can be a bit more inconvenient than you might think ;)

When I'm working on Python code, I'm in PyCharm. My C++ work on Windows is in Visual Studio. When I ssh into the Linux machine that serves our in-house documentation to make changes, I'm using vim. On OSX, I use BBEDit most of the time. When I'm writing a letter, I'm usually in Word or Google Docs.

I think if I spent all day every day in one environment, I would get bored.

Yes, at least whenever possible.

> I think if I spent all day every day in one environment, I would get bored.

The opposite perspective: It's extremely frustrating constantly switching between significantly different environments with different UIs, different hotkeys, subtly different jargon, etc.

Maybe that's the difference. I'm not a productive multitasker. When I have some Python to work on, that's all I'm doing for the next day or two. I'm not jumping from Word to PyCharm to Vim all day.

Personally, mapping Caps Lock to Ctrl (which I do anyway) and using Ctrl-C works best. I use vim and IntelliJ's vim emulation on an international keyboard where Ctrl-[ won't work.

Got it. Thanks.

If you think that places me on the other side of the argument (it doesn't), that's on you. It simply puts me in the middle.

This is misleading. In the era of JetBrains and its perpetual licensing and Steam and whatnot, it's worth pointing out that ST3 is a binary that you download and have complete access to, so of course it will be there next year.

You're probably getting at the fact that development may stop on it next year, and that's true, but the product is still pretty polished and useful now.

I also don't have your confidence that Emacs will always be there. I don't have statistics - but have contributions been increasing or decreasing in the last decade? In any case, I hope that Emacs fades away: text editing is great, but I think there's still plenty of room to advance our craft. Things like Lamdu and Eve (nee Light Table) are interesting explorations.

Here are some screenshots: https://github.com/ch11ng/exwm/wiki/Screenshots

All you need to do is to set up a couple of hotkeys for things that Emacs cannot do (yet), like (start-process "" nil "xdg-open" "http://some.flashy.javascript.website")

This is not "being there." Popular architectures change, as do operating systems. Unless you intend to freeze your current computing environment for posterity, a working executable means nothing.

I'd say that both vi and Emacs have solid fundamentals and have stuck with a model that works, to their credit. I must admit that I shop around for editors occasionally (I'm a long-time emacs person, who swapped back to vi a few years ago to re-develop his vi-fu), but I haven't seen anything so compelling that I've switched to anything else.

It may well be that I'm looking in the wrong place, or that I don't realize the true awesomeness of something that does cross my desk.

In the spirit of advancing text editing, what would you say is missing from vi or Emacs that you've found in other editors (even if the advancements aren't present in one singular other processor)?

Edit: stray words

But I'll grant you it's a hard sell to say "this is great, but you're going to be unproductive for a month". Nonetheless, I think the payout is very much worth it, and if you are interested, make sure you are prepared, and stick with it for a good long time before giving up.

In general, vi/emacs are missing support for editing above the level of text (eg. refactoring) and support for UI above the level of a text terminal. I know add-ons exist for both editors that do some of these things, and of course, you can run both in a graphical terminal with custom fonts, etc -- but if one is being honest, it's not very well integrated in either of the old standbys.

I'm a vim user, but not really an advocate. I'm just used to it, I like the way it works (mostly) out of the box[1], and I think it's text editing facilities match the way I edit better. It's a great generic text editor -- as is emacs (for some others, not me). But all they do is understand text...

I had to do some Java development recently. So I tried eclipse (with a vim keymap plugin). Now, eclipse kind of sucks in many ways, but one thing it definitely has is the ability to refactor code. Something like variable rename over multiple files that would have me concocting a sed-ish script for vi, or doing query-search-replace, next,next,next,skip,next in emacs was literally two keystrokes and bang, done. Forget about actually moving language constructs from one file to another or to another package, etc. And the UI for it was very clear: inplace modification, and popping up a warning about where the refactoring would break, if it would.

And then we have modern UI. Eclipse isn't even very pretty (or modern) by modern standards, but it still highlights properties of code (warnings, unused variables, etc) by actually drawing symbols or boxes on the screen rather than attempting to wrangle indications into the world of VT220 terminals. Among other things...

One could put this all making up for deficiencies in Java, I suppose. Except, again, if one is honest, one realizes that this kind of thing is highly useful no matter what language you're developing in...

Neither Vim or Emacs has very good support for any of this at all. There are examples of add-ons that do it kinda-sorta, but they aren't very good. Emacs is better than vim at this, of course[2], but it's still not very common for language support to get to this level. It's not a standard thing, and it should be. Such is history, and the pragmatics are writing a substantial piece of software inside another piece of software in a crappy language :-). Emacs still crappier (and slower) than eclipse at just highlighting syntax (and barely does the highlighting of semantics).

Emacs & vim have real issues as code editors because they are stuck in the past -- and not the recent past either. Vi was never meant to be anything but a text editor, for good or ill. And Emacs... well emacs lives in it's own little world reminiscent of a half-baked lisp machine crossed with a VT220 terminal. And while the capability is there somewhat to do the above, there is a lot of historical baggage and historical code to overcome.

So, is eclipse my editor of choice now? :-) :-P Well, no (except for java code). :-) It's a shitty editor, it's slow to start, it crashes or gets into a funky state too often, and it's really a Java-editor, not a generic text/code/anything editor (although it tries to be, and fails). But I think eclipse and tools like it show clearly "what is missing" in an old-school editor like vim/emacs, or indeed any new editor which uses either of these as a model.

[1] I also think key-chording, which emacs uses (and others influenced by emacs use) is actively physically harmful.

[2] A better scripting language helps. I'm sure emacs is somewhat passable at refactoring lisp code. :-)

If you look the way magit dialogs are handled, they're quite innovative and could be useful in many other contexts (like shell commands). Magit itself has many other innovative UI approaches. EMMS/gnus/notmuch/twittering-mode have innovative UIs of their own. Also look at spacemacs and the things its doing with guide-key for more UI innovation.

Being able to search (C-s) or filter (occur) almost any text on the screen (including UI like button names) is very nice, and something I miss when in Atom (like the Settings tab where one can only search things the creator decided to add a search field for).

There is a ton of innovation in vim and emacs these days, mostly in new packages. I'm glad we have them (and Atom and others) exploring different approaches.

There are plenty of gedit-like editors with standard user interfaces.

Luckily there are VIM bindings for nearly every single IDE of importance out there.

For things like renaming, an IDE would have a function for that, which isn't text based but symbolic. At the very least, bringing up a replace diaglog with regex functionality doesn't require any more keys to be pressed in an IDE than in emacs. Most IDEs's also support key bindings that are pretty close to Emacs or vim.

unless you use a dynamic language in which case you are shit out of luck.

[1] http://ensime.github.io/

Also, you can create quite a lot of code indirectly by few well-placed keystrokes that utilize multiple cursors / keyboard macros, regexp-replaces and things like this. Think of it as chiseling out an entire block of code at once. Spend little time mastering those features, and you can do things like this on the fly, without much conscious focus.

With regards to simpler editors, the problem is that they come and go. Learning an editor is a big investment, so I'd rather stick to something that will still be around next decade.

Mind you, Atom takes longer to start than Visual Studio.

Note UNIX, not UNIX like.

I can also use tramp to ssh onto another machine from within emacs, and so don't have to bother installing my favourite editor on headless servers and Raspberry Pis.

[1]: https://atom.io/faq

https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=atom-...

https://code.visualstudio.com/Docs/supporting/FAQ#_how-to-di...

PDP-11 command line experience is not even there.

Are you saying the modern unix command line is not as good/better than the "PDP-11 command line experience"?

Also, which PDP-11 command line? RSTS? RT11? Unix? or maybe that awesome front panel where you had to manually input your boot loader in binary every time you started the machine?

No, I am saying that it isn't even close to the Xerox PARC REPL experience from Interlisp-D, Mesa/Cedar and Smalltalk environments.

> Also, which PDP-11 command line? RSTS? RT11? Unix? or maybe that awesome front panel where you had to manually input your boot loader in binary every time you started the machine?

The VT-100 interface some people seem to keep living on.