- 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.
(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.
(setq recentf-max-saved-items 200)
(setq ido-use-virtual-buffers t) ; include recentf files
(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.
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.