Re: on helm substantial differences

[Jean Louis]

* Drew Adams <drew.adams@oracle.com> [2020-11-12 20:43]:
> > Features wanted in ivy or icomplete or anything inside
> > of Emacs or in GNU ELPA:
> > 
> > - full frame completion with mode line staying where it is
> > - split window completion as helm does it, with mode line
> >   staying where it should be
> 
> And you mentioned vertical presentation of candidates.
> 
> FWIW, Icicles offers that.  You can show candidates
> vertically, in a single column *Completions*, if you set
> option `icicle-Completions-max-columns' to 1.

Our conversation helped me to make some conclusions.

What I need is how you and others pointed out is real time dynamic
filtering or searching. It is filtering when a present display of
hyperlinks has to be filtered.

It is searching when completion encompasses all nodes that are not
only in the current selection. In that case it positions the cursor in
possibly different set of the tree.

Completion as such, as it works in built-in Emacs or any other, like
ivy, icicles, helm, is working well for that functionality to locate
the node or to find other set with searched node.

Additional feature that would spare much time for user is real time
dynamic filtering for tabulated-set-mode. I will see how that can be
implemented.

By functionality it would be similar to completing-read, though not
same.

> There are many kinds of completion, and many kinds of
> completion candidates.  For short candidates, a single
> column wastes an incredible amount of screen real estate.

That may be true for various other use cases. For this particular
usage candidates are mixture of very long lines and sometimes short
lines. Also good for thinking about that.

tabulated-list-mode does allow wide or widening of candidates I think
indefinitely. That helps the user to read what is really there as
completion candidate or to obtain more information. For example I can
go with C-e to the far left side of the text, there could be even
right screen or several screens from left to right which give various
information pertaining to the hyperlink while priority information is
shown on first screen only.

completing-read functions would mostly be limited in that regard, I
would need to shorten information to accommodate completing-read. New
feature shall rather accommodate the program.

> That may be fine, if your only purpose is to narrow to
> a particular candidate.

That is one usage case. completing-read finds the candidate, but then
displays all surrounding candidates in the set of the selected
candidate. In the next step is possible to either examine or activate
the hyperlink or do other actions.

> But if you're operating on or otherwise examining the _set_ of
> current matches in some way, then you likely want to see more than
> just a few of them, and being able to show more than one on a single
> line helps a lot.
> 
> On-the-fly filtering is about many things.  What's
> really involved is manipulating a candidate _set_.
> For that, it helps to see most or all of the set.

Yes.

> The design of Icicles recognizes this high degree of
> variability in candidates (including display size) and
> in uses of filtering and manipulations of a set of
> candidates.

For now icicles are functional and I can use it. In general I will
leave to user which completing-read or package to use. 

Overall discussion helped me to find various other similar
projects.

As the words I used were not confirming to understanding of other
people and I have got various other references that relate to
HyperScope.

GNOWSYS: A Kernel for Semantic Computing!
https://www.gnu.org/software/gnowsys

gstudio
https://gitlab.com/gnowledge/gstudio