Re: Relevance search in Emacs

[Jean Louis <bugs@gnu.support>]

* TRS-80 <lists.trs-80@isnotmyreal.name> [2020-12-06 01:24]:
> Also, I seem to recall hearing that there was some discussion about
> moving some part (or all?) of Ivy directly into Emacs itself?  I do know
> that Ivy for a long time now have been assigning their copyrights to
> GNU, they are very upfront about this to contributors at their GitHub in
> fact.

As ivy is in GNU ELPA those issues are already solved. It is up to
author to polish the package if necessary to include it. But is not
necessary as it is already in GNU ELPA and new packages can request it
and it will be easier installed than from repositories not being
straight in GNU Emacs.

> Even those who would criticise Ivy/Helm[0] admit that there is a lot
> more functionality that they offer than the "built-in" solutions.

What Emacs needs is dynamic menu that user can filter quickly and work
on it, it would be similar to dmenu X program but one can only choose
one item there, or fzf console program which is more similar to what I
mean. Helm and ivy and others try to be that. But we do not have very
nice menu system in Emacs. And I do not refer to menu bar on top as
such is limited, then not dynamic.

Helm in full screen is pretty much what I think but again it limits
itself to execution of it.

Image list of items such as products. One need maybe to mark such and
move from one category to other. Job is tedious by doing it with
helm. List of people to which one need to send email by selecting them
by hand. Helm offers C-SPC to select each item and then run TAB
actions to do something with them. But programming with helm is
wasting time pretty much.

Doing it with tabulated-list-mode is so much easier:

- filter items (provided function exist for this interface)
- mark items (those are ID numbers)
- do something with items

For now I am transitioning from helm to tabulated-list-mode as for its
simplicity and interface that remains on screen, it is does not
disappear like completion interfaces (helm, ivy).

It just lacks dynamic filtering.

> realized this in developing some of my own (as yet unreleased) packages
> where I depend on some of that functionality, and thus, in fact require
> Ivy as a dependency.

First I have started going helm dependency direction as that was first
that I have discovered, then I have tried to make it that users can
decide on completion. This is best approach and also does not bind
myself to specific completion. Run it with built-in completion or turn
any other completion package.

It is best to have packages liberated from specific completion
packages such as ivy, helm, etc.

For me ivy does well with relevance search for few words apart from
each other may be used to locate the item. But it is still
"completion", it does not allow me actually work on the filtered set
of items. It wants me to complete. I think helm too. 

> If this was more about search itself than choice of completion
> framework, I guess I totally missed the point, or maybe that's another
> discussion to have.
> 
> Anyway, maybe give Ivy a try instead of Helm.  Or if you are swayed by
> arguments at my footnote link, one of those other "minimal" completion
> frameworks.

I am testing them all. Selectrum is just core stuff, it is not
integrated well for end users and it is completion, not dynamic filter
after filter. I hope you get what I mean.