Re: tabulated-list-mode needs incremental search option

[Jean Louis]

* Stefan Monnier <monnier@iro.umontreal.ca> [2020-11-10 16:18]:
> > In general I am advising that every application with choices offers
> > among others the narrowing incremental search.
> 
> Very well, but to me this is much too vague to know what it means.

Drew also reminded me to express me better. The above statement refers
to general applications and not only to Emacs.

I am referring to real-time collection narrowing just as
icomplete-mode or ido-mode or ivy, helm.

> AFAICT, if every application uses `completing-read` when it has
> a choice, then it does offer "narrowing incremental search" because
> `icomplete-mode` (among other minibuffer completion schemes) does offer
> something that narrow the search incrementally.

I am using tabulated-list-mode to classify hyperdocuments and browse
trees of information. That will arrive to GNU ELPA when polished. But
first must come the `emacs-libpq' PostgreSQL database dynamic module
which developers are working on it.

One way to search is filtering results like in M-x list-packages with
/ a for example to filter by archive. That uses tabulated-list-mode

Filtering the final result of matches is useful in any application
offering larger selections.

Completion frameworks are excellent improvement for Emacs to narrow
the collection of items. Yet not all of them are developing with good
principles of work.

We think of minibuffer being minibuffer. Of course it can expand and
become as large as main buffer. Yet historical and practical use is
that we look and focus into minibuffer, it is down there, and it is
mini.

Above minibuffer there is modeline. People do look into modeline
including me.

What hapens when using ivy-mode is that modeline jumps up-down when
completing. And I need to use external function (without knowing the
license) to accommodate ivy to behave more useful.

Some things are apparently pretty static in Emacs. For example Help
menu and modeline. Does anybody expects Help menu to jump down to
middle of screen?

In the same way I do not expect modeline to jump in the middle of
screen. Minibuffer completion that raises modeline does not enhance
legibility, it enhances confusion.

Good example how is that solved ind `M-x helm' may be seen here:
https://emacs-helm.github.io/helm/images/helm-buffers-list.gif

- minibuffer stays where it is, it does not enlarge
- modline does not jump up and down
- separate window is used for completion

More about Helm:  https://emacs-helm.github.io/helm/

icomplete-mode is far from being complete in the above context of
making the legible visual non-disturbing selection.

Here is short demonstration and comparison, video (17M):
https://gnu.support/images/2020/11/2020-11-10/2020-11-10-20:10:49.ogv

The demonstration is showing:

- how Hyperscope for Emacs is using tabulated-list-mode to browse the
  tree and sets of hyperdocuments

- entering sub-tree is done with arrow left, going up the tree is
  arrow right

- if selection or collection is very long, browsing is tedious, it
  could be 15000 items, I have 19000 items now.

- basic filtering is implemented, yet this does not replace the real
  time incremental matching (aka ivy, helm)

- querying with ivy or helm or any completing-read function is
  possible. What is missing here is ivy-occur so when narrowing have
  been performed that user gets narrowed list.

- there is comparison between ivy where modeline is jumping up and
  down because minibuffer is enlarging. Those elements of user
  interface considered static (even if they are not) are not supposed
  to jump up and down, it confuses user. I do use external function to
  remedy it and hope that ivy will get it internally. Manual does not
  warn users that modeline is to jump up and down when using
  minibuffer. 

- helm mode shows that modeline remains where it is expected to be
  just as it is explained to users in the Emacs Manual. 

As tabulated-mode-list can be used for selection of items, for listing
of items, it is good to have real-time incremental narrowing
function.

Difference between the tabulated-mode-list feature (narrowing
incremental real time matchin) and minibuffer completing framework
functions is that the first uses full screen and does not mess the
modeline and general user interface.

In this application it would be better to remain in full screen and to
narrow by using minibuffer.

When using completing frameworks there are visual disturbances to
screen:

- screen is divided in half either by modeline jumping up or by split
  window
  
- minibuffer is not mini any more

- modeline jumps up and down

With the new feature I am proposing we would enable Emacs Users to
create full screen menus and selections from menu.

Jean