Hacker News Reader

Comment by tptacek | Hacker News Reader

There's a lot of antiquated stuff in Emacs, but despite the almost total lack of a modern UI toolkit for extensions, there are also interfaces in Emacs that are better than anything available elsewhere --- reasons to launch Emacs even if you don't need its expressive power for editing. Magit is a good example, Helm is another, org-mode another, FlyCheck another.

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

View on HN

Helm may be the most flagrant example of a terrible package that remains inexplicably popular. I haven't uninstalled it yet, because there are a few packages that use helm that don't have ido equivalents yet, but I try to minimize my usage of it as much as possible. Issues include:

- 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.

I can't say that I have experienced all of these issues myself after using helm for about a year.

- 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

Ah, helm-flx didn't exist when I quit helm, and flx-ido did. Question: does helm-flx sort results, or does it just throw back an unsorted list of matching entries, like normal helm? I consider the sorting an even bigger and more ridiculous drawback than the matching.

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.

helm-flx sorts results by the "closest" match to your typed in characters. For me, typing "tetri" has "tetris" listed first, with the next result matching all of those characters in a different command, and each of the following results being less and less accurate matches. There is no alphabetical sorting, though.

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.

You may be interested in checking out Ivy; it has a similar workflow to Helm but is much more lightweight. As a fan of Ido, Ivy has replaced Ido everywhere for me except for opening files.

I've heard good things about ivy, but haven't got around to revamping my config in some time. I'll check it out next time I do.

I'm on 24.5, and I don't know how it was in the past, but Emacs' default minibuffer reading functionality is good enough that Ido, Ivy, Helm or whatnot seem superfluous to me. I can type C-x C-f ~/Git/projectx/src/ding/~/.xombrero/runtime//etc/fstab RET

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

  M-x rev-bu RET

and it will run revert-buffer, and if I type TAB instead of RET, it will complete to actual command name. It will ignore case in completions if these variables are set:

  ;; 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

Also an indispensable config:

  enable-recursive-minibuffers t

What does them tools provide that can't be easily done by these? And ido fails when entering a TRAMP file name, so one has to hit C-f in minibuf to drop to the original prompt.

This works great if you have all the commands memorized. If you don't, fuzzy matching in ido is a fantastic way to find commands and variables that do what you want (Emacs has a great tendency to name user-facing commands very sensibly a lot of the time). Most of the time I can use C-h f and C-h v to figure out how to configure something without having to read the documentation.

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.

I do not have all the commands memorised. But how emacs completes changes upon where you hit tab. if you type M-x re-bu TAB, it will show revert-buffer, re-builder, etc. If you hit TAB when cursor is at the beginning, like M-x buffer M-b TAB, it will show any command with buffer in it. Then you can C-x o to the Completions buffer and use any search tool on it, e.g. isearch-forward-regexp.

More power to you, but I couldn't go back to manually-invoked completion at this point. An environment which gives me as much information as possible as quickly as possible in as few keystrokes as possible is a big priority for me, and I'm willing to have a few extra dependencies in order to get that.

It's not about dependencies, after all ido is part of emacs. I find the default with some tweaks to simply be better. Though it's a bit personal preference here I think.

"dependencies" was a reference to the numerous plugins I use to get ido in a state that I enjoy. I don't particularly like stock ido, though I prefer it to the standard completing-read.

make sure you're using the stable melpa repository. The unstable (default) melpa repo is just builds direct from the master branches of the projects. melpa stable is builds from release tags.

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

Agreed. Regular melpa is practically a parody of a package repo - sometimes it seems it took the worst option at every possible decision. Building directly from HEAD, using insane version numbering that causes package.el to prioritize it over every other repo (someone more cynical than I might think this was intentional), and yet somehow managing to be by far the most popular way to distribute packages, even more so than melpa-stable (which is actually quite tolerable).

For M-x I like smex. Like fuzzy ido but without the bugs and purpose built for M-x - it just works. smex persistently remembers how often you use different commands, and uses this to sort the initial list of completions - very handy.

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

> 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)

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.

ido would really benefit from being spun-out as a package. People would actually fix bugs and add functionality in a reasonable way rather than hacky extensions (like ido-hacks)

> 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"

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.

I think both built-in completing read and helm/ivy have their uses. ido is best for when you know what you want and want to get it to it with minimal number of keystrokes. helm seems better for when you want to review many (but not too many) options before deciding on what you want.

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

While, something like this works better with helm:

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

I love ido's find-file, but I think that's because I've made it behave much differently than the defaults. The ability to use backspace to go up one full directory, jump to home with ~/ at any point, jump to / with // at any point, and navigate folders quickly with fuzzy matching and RET is really, really nice.

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 find-file. Now I see current directory as the default suggestion. Can C-a, C-b, Backspace, etc. within it.

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

Ah, I see. This is actually one of my favorite features of ido-find-file. I love the fact that I can treat the current path section I'm writing as independent of the path I've already navigated to. To each their own.

I can't reply to gleb's comment below, so I will respond here.

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

FWIW, you can do that stuff with helm as well. Except it's C-l to go up a directory by default, IIRC.

Which plugins would you recommend to replace helm?

Reply on news.ycombinator.com