Better reason why not use helm · Issue #203 · radian-software/selectrum (original) (raw)

I feel like the section is essentially the same as before.

I also personally prefer using software that I have some hope of
understanding, which ideally means that they don't provide a hugely complex
array of features of which I only use one or two.

I don't see the problem with the existence of many features in a program. If the
program is designed well, you should be able the just use the one or two
features without being obstructed by the others (or even knowing of their
existence). For me, Emacs itself is such an example. What you're getting at (if
I may) is that the implementation of these features is "complex" and interfere
with the fundamental function of the program because they are not properly
segregated. If this is what you mean, then you should say this.

Ideally, I thought a Why not helm? section should include
why specific design decisions in helm are not good.

For example, I like how you mentioned the problems of functions having knowledge
about specific functions, and having to create a wrapper around every function,
in the why not ivy? section (although I would also like it even more if this
were supplemented by links to some of ivy's code which does this). I also really
like the specific issue you referenced concerning ivy's API. These are specific
critisms concerning ivy's design. And at least to me, someone who wants a
predictable, customizable, completion framework, it seemed appealing.

I think one thing that you should include is Helm's performance problems. While
I have not done a benchmark, I can say that in my experience Helm's candidate
filtering is noticably slower than Ivy's or Selecturm's. I don't know about
everyone else, but over time that extra second or so delay when filtering would
really start to annoy me. Perhaps I can provide a gif for the README showing the
noticable speed difference.

It also seems like helm does create a wrapper around functions instead of
working with the existing completing-read framework. For example I did not like
that I could not use helm's multiple actions/selections if a function was not
defined with helm. Considering this seems to be a theme for why people should
use selectrum, this should definitely be included.

In a nutshell, the way I see it there are differences in design that we may not
agree with but that are relatively benign because they can be disabled (as per
variables) or advised (with functions). These differences don't warrant a
redesign. However there are some differences in design that are so fundamental and
so difficult to overcome that they do warrant the creation of a new package. I'd
like the Why not helm? section to answer why helm's design is an example of
the latter.