Hacker News Reader

Comment by ComputerGuru | Hacker News Reader

(neo)vim user here; is this like the myriad of ctrl-p vim plugins like fzf, cpsm, etc? In the vim world the core functionality is often shelled out to a task-specific process via a plugin, and the vim code is only used to communicate with it. Is that not the case with emacs?

View on HN

It's more like fuzzy search for everything you could possibly do, with docs and completion. I'm a vimmer, emacs people should correct me.

It's magic because everything is a single lisp environment. So the client/server thing vim does isn't as unified.

No that is right, emacs has two main contenders for "fuzzy search" - ido-mode and helm. They act as completion engines for all kinds of search; file, word, buffer, commands etc.

Helm acts similar to Ctrl+P, ido is like an incremental search so finding a file named BasketViewController.swift in path ~/Code/MyApp/;

In helm would be 'bvc', whereas in ido it would be c -> code (hit enter), m -> MyApp (tab across if its not first result, enter) Bas -> BasketViewController.swift

> emacs has two main contenders for "fuzzy search" - ido-mode and helm.

Also Ivy.

The closest vim has (to my knowledge) is Unite/Denite, although fzf is functionally similar minus a couple limitations on starting new fzf searches from the callback of another.

Like helm, fzf and Unite can be fed arbitrary completion candidates, custom callbacks, mostly customized fuzzy matching. fzf is very fast, which is the main claim over what seems to be the more featureful Unite/Denite.

Does FZF work with a list of vim's ex commands as source (preferably including plugin defined commands)?

That functionality (helm-M-x) has been the best part of using emacs. It's always something I miss when I'm back in vim land. Really nice to just be able to discover these things without a mess of gui everywhere distracting me when I don't need it.

Yes, `:Commands` does that. Not sure if it’s documented in more detail somewhere else, but it’s listed here (https://github.com/junegunn/fzf.vim/blob/master/README.md#co...).

Helm allows one to specify their interface in the form of a class (helm-source) between (arbitrary searching code) and (helm-core = a standardized way to represent/navigate that in a buffer) which one can plug in his candidates for searching (anything).

So if one eg. used shell or remote tools, it would still plug into helm, one would write a "helm-source" which communicated to helm how the source was updated and provide actions to communicate back and update/filter the source.

not very familiar with vim internals (other than knowing vim is not vi codebase), but emacs most everything is natively written in emacs lisp and has lots of hook points, emacs extensions tie into these or in some cases may carefully provide extensions/extra API's around builtin functions, etc.

Helm is itself a library loaded into a given emacs image which provides useful functionality, but also that many other packages build on top of. Not sure if the point about plugins as a process was just wondering about how it works or hinting at some kind of 'workaround' for not being maintained by isolating it; issue here seems aside from potential bitrot in helm itself to be the overall ecosystem of all 'emacs helm plugins' deteriorating if helm is not maintained, which separate process plugin architecture wouldn't solve.

Reply on news.ycombinator.com