Better reason why not use helm

[Luis-Henriquez-Perez]

I was not satisfied with the reasoning used to describe why not to choose helm.

I found two parts to the argument one is that it has "too many features".

Alone this is a very weak argument. An answer would be either disable or don't use the features you don't want/like.
In and of itself, many features is an advantage not a weakness. Now, if this argument were to mention code complexity and bugs that are a consequence of the way many features were implemented then we'd have something here. But there is no mention of this.

The next part of the argument deals with the appearance of helm.

"Upon opening a Helm menu, I am immediately confronted by numerous colors, diagnostics, options, and pieces of help text."

This is also not a strong argument considering that the display of helm can be customized. The appearance alone is certainly not a good reason to justify using selectrum when an established completing framework exists.

[clemera]

My main arguments against helm would be the complexity and its interaction model. Users used to the meaning of TAB in the minibuffer will feel more comfortable with Selectrum. Selectrum also follows a more modular approach favouring composable extensions instead of a monolith which handles everything. That said I think Helm is a great completion framework and I'm happy it exists. Personally I don't see Selectrum in direct competition with helm: Selectrum gives you enhanced minibuffer completion and helm gives you the ability to write some advanced completion commands which need some of the special features it supports.

[raxod502]

Let me know what you think of the update.

[Luis-Henriquez-Perez]

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.

[raxod502]

Thank you for your well-reasoned response. I think your criticisms are fair. Do you want to rewrite the Helm section according to your suggestions? It might be nice to have a somewhat less biased author behind these, anyway...

[Luis-Henriquez-Perez]

I'll give it a shot. Although I can't say I've used helm extensively, I can provide my experiences with it. I'll submit a draft as a PR after doing some reading into Helm's source code so I can be sure what I say is factual.

[mplscorwin]

FYI, the Helm is once again under active development.
Would it make sense to remove the language stating otherwise?

Thanks!

[okamsn]

FYI, the Helm is once again under active development.
Would it make sense to remove the language stating otherwise?

Thanks!

For the most recent release, the maintainer states (here):

This Helm version is stable enough to be considered as mature, it is probably the last Helm version under my maintenance.

So the future is still uncertain.

[mplscorwin]

Makes sense. Thanks.

[brainhead105]

Senseable.

[minad]

@clemera @raxod502 can be closed? If someone wants to improve the helm section, an improvement can be submitted as PR.

[clemera]

We can wait for @Luis-Henriquez-Perez to respond/close it otherwise issues labeled waiting for response will auto close after three month.