GNU bug report logs - #44550
tabulated-list-mode should offer incremental filtering

Previous Next

To reply to this bug, email your comments to 44550 AT debbugs.gnu.org.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Jean Louis <bugs <at> gnu.support>
To: bug-gnu-emacs <at> gnu.org
Subject: 28.0.50;
 proposal for tabulated-list-mode to provide narrowing incremental
 search
Date: Tue, 10 Nov 2020 13:36:03 +0300

I have asked author if narrowing incremental search feature could be
included in tabulated-list-mode. He asked me to file bug report for
that proposal and I include last part of conversation here:

* Chong Yidong <cyd AT stupidchicken.com> [2020-11-10 10:25]:
> Hi Jean Louis,
> 
> > But now when you gave me references on how to filter the view then I
> > can make function for my particular case myself to enter one or more
> > words to filter by words. That is workaround, not real solution.
> > ...
> > In my opinion the above is enough for me. You said how / k filtering
> > is implemented, even I used it but I forgot it. You reminded me, so
> > now I can filter in similar way myself.
> >
> > If it happens that you decide to improve it, I have idea how you could
> > do it: simply concatenating all tabulated items with space between and
> > then using matching words on that list.
> 
> Glad the interim solution can be done.
> 
> I think the incremental typing functionality is best implemented as its
> own minor mode.  It should not be tied to tabulated-list-mode.
> 
> This could be modelled after Emacs' completion functions.  In
> completion, you start typing and Emacs draws in information from the
> buffer to try and complete what you have in the minibuffer.  In the new
> incremental processing mode, you start typing and Emacs alters the
> buffer to reflect what's in the minibuffer.  Similar to completion, it
> would not be mode-specific, but different modes would be able to
> customize the effects in a way that makes sense for that mode.
> 
> Could you file a feature request in the Emacs bug tracker, or send an
> email to emacs-devel to open a discussion?  It's possible there's
> already related functionality that I'm not current aware of, e.g. in an
> external package.

I will also Cc: this email to emacs-devel.

In general I am advising that every application with choices offers
among others the narrowing incremental search.

Be it by invoking a key binding first or directly by simply
typing. Because there are various key bindings in almost every mode it
is better to start narrowing incremental seach when user press special
key like / or something.

To come out of narrowed list one could press other key binding and see
the original list.

In my program I am using (setq tabulated-list-entries entries) and it
is common in tabulated-list-mode.

So I guess it could be implemented as you said in a derived mode
invoked by programmer or program where:

- user press some key to start a real-time narrowing incremental
  search

- program remembers the original `tabulated-list-entries' as
  ORIGINAL-DATA

- program can concatenate parts of each entry into strings (or maybe
  use other method) during the incremental narrowing search

- user starts typing and lines shown in tabulated-list-mode get
  narrowed to selected lines

- program obtains the ID numbers and displays only those ID numbers by
  using (setq tabulated-list-entries NARROWED-DATA) and redisplays

- use could press ENTER and narrowing incremental search stops at that
  point, user is facing new tabulated list and can handle it in usual
  manner.

- user may press a key to go back to go to original
  `tabulated-list-entries' and program does (setq
  tabulated-list-entries ORIGINAL-DATA) and re-displays



-- 
Thanks,
Jean Louis
⎔ λ 🄯 𝍄 𝌡 𝌚

Message #8 received at 44550 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Jean Louis <bugs <at> gnu.support>
Cc: 44550 <at> debbugs.gnu.org
Subject: Re: bug#44550: 28.0.50;
 proposal for tabulated-list-mode to provide narrowing incremental
 search
Date: Tue, 10 Nov 2020 17:57:18 +0200

> Date: Tue, 10 Nov 2020 13:36:03 +0300
> From: Jean Louis <bugs <at> gnu.support>
> 
> I have asked author if narrowing incremental search feature could be
> included in tabulated-list-mode. He asked me to file bug report for
> that proposal and I include last part of conversation here:

Could you please explain what you mean by "narrowing incremental
search feature"?  You only explained it in the terms of
tabulated-list-mode, and even then I don't think I understand what
it's supposed to do.

Message #11 received at 44550 <at> debbugs.gnu.org (full text, mbox):

From: Jean Louis <bugs <at> gnu.support>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 44550 <at> debbugs.gnu.org
Subject: Re: bug#44550: 28.0.50; proposal for tabulated-list-mode to provide
 narrowing incremental search
Date: Tue, 10 Nov 2020 22:57:35 +0300

* Eli Zaretskii <eliz <at> gnu.org> [2020-11-10 18:57]:
> > Date: Tue, 10 Nov 2020 13:36:03 +0300
> > From: Jean Louis <bugs <at> gnu.support>
> > 
> > I have asked author if narrowing incremental search feature could be
> > included in tabulated-list-mode. He asked me to file bug report for
> > that proposal and I include last part of conversation here:
> 
> Could you please explain what you mean by "narrowing incremental
> search feature"?  You only explained it in the terms of
> tabulated-list-mode, and even then I don't think I understand what
> it's supposed to do.

Drew also suggested to express that more precise. Context is similar
to ivy-mode or helm or icomplete or ido, etc.

- imagine list of items in tabulated-list-mode

- user press / to open up the feature (real time incremental narrowing)

- when user starts typing the list of items in tabulated-list-mode are
  narrowing themselves visually and in real time. It is very similar
  to completion networks.

Then I can use it for browsing trees of knowledge and narrowing huge
index lists. Video below shows using tabulated-list-mode to brows the
three of knowledge (17M): 

https://gnu.support/images/2020/11/2020-11-10/2020-11-10-20:10:49.ogv

In general I would like to have direct real time incremental narrowing
of collection instead of blowing up minibuffer, making modeline jump
up and down with ivy-mode and splitting windows.

Interface would be clean just as tabulated-list-mode is and minibuffer
could be used for narrowing.

Message #14 received at 44550 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Jean Louis <bugs <at> gnu.support>
Cc: 44550 <at> debbugs.gnu.org
Subject: Re: bug#44550: 28.0.50; proposal for tabulated-list-mode to provide
 narrowing incremental search
Date: Wed, 11 Nov 2020 17:35:35 +0200

> Date: Tue, 10 Nov 2020 22:57:35 +0300
> From: Jean Louis <bugs <at> gnu.support>
> Cc: 44550 <at> debbugs.gnu.org
> 
> - imagine list of items in tabulated-list-mode
> 
> - user press / to open up the feature (real time incremental narrowing)
> 
> - when user starts typing the list of items in tabulated-list-mode are
>   narrowing themselves visually and in real time. It is very similar
>   to completion networks.

What does "narrowing" mean in this context?  What should happen in
real time?  Do you mean "filtering", i.e. that some items should
disappear from view?  If so, what criteria should be used to filter
out items, and how is that derived from what the user types?  I'm
still confused regarding the feature you are looking for, and how it
relates to completion.

> Then I can use it for browsing trees of knowledge and narrowing huge
> index lists. Video below shows using tabulated-list-mode to brows the
> three of knowledge (17M): 
> 
> https://gnu.support/images/2020/11/2020-11-10/2020-11-10-20:10:49.ogv

Sorry, cannot watch such videos.

> In general I would like to have direct real time incremental narrowing
> of collection instead of blowing up minibuffer, making modeline jump
> up and down with ivy-mode and splitting windows.
> 
> Interface would be clean just as tabulated-list-mode is and minibuffer
> could be used for narrowing.

And now I'm completely confused: I thought you were talking about
tabulated-list-mode, but now you've made some gigantic leap to much
more general issues.

Message #17 received at 44550 <at> debbugs.gnu.org (full text, mbox):

From: Jean Louis <bugs <at> gnu.support>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 44550 <at> debbugs.gnu.org
Subject: Re: bug#44550: 28.0.50; proposal for tabulated-list-mode to provide
 narrowing incremental search
Date: Wed, 11 Nov 2020 20:22:04 +0300

* Eli Zaretskii <eliz <at> gnu.org> [2020-11-11 18:35]:
> > Date: Tue, 10 Nov 2020 22:57:35 +0300
> > From: Jean Louis <bugs <at> gnu.support>
> > Cc: 44550 <at> debbugs.gnu.org
> > 
> > - imagine list of items in tabulated-list-mode
> > 
> > - user press / to open up the feature (real time incremental narrowing)
> > 
> > - when user starts typing the list of items in tabulated-list-mode are
> >   narrowing themselves visually and in real time. It is very similar
> >   to completion networks.
> 
> What does "narrowing" mean in this context?  What should happen in
> real time?  Do you mean "filtering", i.e. that some items should
> disappear from view?

Yes, thank you. I mean filtering. By pressing specific key for
filtering let us say "/" or other key, user starts typing and anything
above X length of characters (normally 3, should be customizable)
starts removing other lines that do not contain the written
query. User could enter few words and words could go match filter also
in reverse order (could be customizable). When user finishes filtering
process one could press enter to get the display in order to browse
down or up in the list. Even filtered list as result can be very long.

> If so, what criteria should be used to filter out items, and how is
> that derived from what the user types?

Criteria is that query should match the line. I prefer that several
words or parts of words can be inserted and that they can be matched
in reverse order.

When choosing a chocolate, designation in the database can be:

"Chocolate (white)" or "White Chocolate" and program does not know how
user will want to search for white chocolate. That is why reverse
order helps. Multiple words should be possible

As I am using tabulated list mode I see that lines can be concatenated
so that it is a list of strings. Query that user types would make
temporary tabulated-list-entries-filtered that replaces the original
tabulated-list-entries. User could go back to unfiltered view.

> I'm still confused regarding the feature you are looking for, and
> how it relates to completion.

I am using already tabulated mode to choose an entry. I guess it was
made for that as there is function (tabulated-list-get-id) and by that
id the choice is completed.

tabulated-list-mode can be used as additional completing-read function
and is very suitable for that. I know it is no adapted to that. I just
see it is very simple as it works with the list tabulated-list-entries
and when redisplayed it shows candidates, one can obtain ID and
candidate entry.

This below should serve to concept understanding that such function
"tabulated-completing-read" is possible.

(define-derived-mode choice-mode tabulated-list-mode "Choice" "Choice Mode"
  (setq tabulated-list-format [("Prompt here" 80 t)])
  (setq tabulated-list-padding 1)
  (tabulated-list-init-header))

(define-key choice-mode-map (kbd "<RET>") 'choice-get-id)

(defun tabulated-completing-read (prompt collection)
  (erase-buffer)
  (choice-mode)
  (setq tabulated-list-entries collection)
  (read-only-mode 1)
  (tabulated-list-print t))

(setq collection '((1 ["~/tmp"]) (2 ["~/Maildir"])))

(defun choice-get-id ()
  "Returns the choice"
  (interactive)
  (let ((id (tabulated-list-get-id)))
    (when id
      (set-register 100 (aref (car (alist-get id collection)) 0)) ;; character d
      (kill-this-buffer)
      (get-register 100))))

;; I do not know how to return, so in my program I am using register,
;; but I do not know how to return register from similar function as
;; above

;; When you evaluate this below buffer will change.

;; (tabulated-completing-read "Files" collection)

> > In general I would like to have direct real time incremental narrowing
> > of collection instead of blowing up minibuffer, making modeline jump
> > up and down with ivy-mode and splitting windows.
> > 
> > Interface would be clean just as tabulated-list-mode is and minibuffer
> > could be used for narrowing.
> 
> And now I'm completely confused: I thought you were talking about
> tabulated-list-mode, but now you've made some gigantic leap to much
> more general issues.

For my personal use case I almost finished such function but I do not
know how to return the ID. When that is solved then it becomes
possible for tabulated list mode to be used as replacement for usual
completing-read.

Message #20 received at 44550 <at> debbugs.gnu.org (full text, mbox):

From: Juri Linkov <juri <at> linkov.net>
To: Jean Louis <bugs <at> gnu.support>
Cc: 44550 <at> debbugs.gnu.org, Eli Zaretskii <eliz <at> gnu.org>
Subject: Re: bug#44550: 28.0.50; proposal for tabulated-list-mode to provide
 narrowing incremental search
Date: Sun, 15 Nov 2020 22:03:33 +0200

> - imagine list of items in tabulated-list-mode
>
> - user press / to open up the feature (real time incremental narrowing)
>
> - when user starts typing the list of items in tabulated-list-mode are
>   narrowing themselves visually and in real time. It is very similar
>   to completion networks.

Isn't this like how incremental filtering works in 'list-packages'?

Here is a list of filters supported by 'package.el':

  Major Mode Bindings Starting With /:
  key             binding
  ---             -------
  / /             package-menu-clear-filter
  / a             package-menu-filter-by-archive
  / k             package-menu-filter-by-keyword
  / m             package-menu-filter-marked
  / n             package-menu-filter-by-name
  / s             package-menu-filter-by-status
  / u             package-menu-filter-upgradable
  / v             package-menu-filter-by-version

Message #23 received at 44550 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Kangas <stefankangas <at> gmail.com>
To: Juri Linkov <juri <at> linkov.net>, Jean Louis <bugs <at> gnu.support>
Cc: 44550 <at> debbugs.gnu.org
Subject: Re: bug#44550: 28.0.50; proposal for tabulated-list-mode to provide
 narrowing incremental search
Date: Sun, 15 Nov 2020 14:51:59 -0800

Juri Linkov <juri <at> linkov.net> writes:

> Isn't this like how incremental filtering works in 'list-packages'?
>
> Here is a list of filters supported by 'package.el':
>
>   Major Mode Bindings Starting With /:
>   key             binding
>   ---             -------
>   / /             package-menu-clear-filter
>   / a             package-menu-filter-by-archive
>   / k             package-menu-filter-by-keyword
>   / m             package-menu-filter-marked
>   / n             package-menu-filter-by-name
>   / s             package-menu-filter-by-status
>   / u             package-menu-filter-upgradable
>   / v             package-menu-filter-by-version

I think so.  But of course the above commands unfortunately don't show
matches interactively.  It would be useful if they did.

Message #26 received at 44550 <at> debbugs.gnu.org (full text, mbox):

From: Jean Louis <bugs <at> gnu.support>
To: Juri Linkov <juri <at> linkov.net>
Cc: 44550 <at> debbugs.gnu.org, Eli Zaretskii <eliz <at> gnu.org>
Subject: Re: bug#44550: 28.0.50; proposal for tabulated-list-mode to provide
 narrowing incremental search
Date: Mon, 16 Nov 2020 01:04:04 +0300

* Juri Linkov <juri <at> linkov.net> [2020-11-15 23:29]:
> > - imagine list of items in tabulated-list-mode
> >
> > - user press / to open up the feature (real time incremental narrowing)
> >
> > - when user starts typing the list of items in tabulated-list-mode are
> >   narrowing themselves visually and in real time. It is very similar
> >   to completion networks.
> 
> Isn't this like how incremental filtering works in 'list-packages'?

It is not filtering real time while user is typing.

Message #29 received at 44550 <at> debbugs.gnu.org (full text, mbox):

From: Drew Adams <drew.adams <at> oracle.com>
To: Jean Louis <bugs <at> gnu.support>, Juri Linkov <juri <at> linkov.net>
Cc: 44550 <at> debbugs.gnu.org
Subject: RE: bug#44550: 28.0.50; proposal for tabulated-list-mode to provide
 narrowing incremental search
Date: Sun, 15 Nov 2020 15:26:37 -0800 (PST)

> > Isn't this like how incremental filtering works in 'list-packages'?
> 
> It is not filtering real time while user is typing.

I think what Jean means to describe is what I'd call
_incremental_ filtering:

As you type chars into the minibuffer the resulting
minibuffer input filters the current set of candidates
further.  Likewise, as you delete or otherwise edit
chars in the minibuffer.  The content of the minibuffer
is continually matched against the domain of completion
candidates, and the display of matches is updated.

I call it "incremental" as in "incremental search" -
same idea: the search space (set of candidates in the
case of filtering) is filtered on the fly as you edit
the search pattern (minibuffer input in the case of
completion-matching filtering).

Message #32 received at 44550 <at> debbugs.gnu.org (full text, mbox):

From: Juri Linkov <juri <at> linkov.net>
To: Stefan Kangas <stefankangas <at> gmail.com>
Cc: 44550 <at> debbugs.gnu.org, Jean Louis <bugs <at> gnu.support>
Subject: Re: bug#44550: 28.0.50; proposal for tabulated-list-mode to provide
 narrowing incremental search
Date: Mon, 16 Nov 2020 11:05:10 +0200

>> Isn't this like how incremental filtering works in 'list-packages'?
>>
>>   / /             package-menu-clear-filter
>>   / a             package-menu-filter-by-archive
>>   / k             package-menu-filter-by-keyword
>>   / m             package-menu-filter-marked
>>   / n             package-menu-filter-by-name
>>   / s             package-menu-filter-by-status
>>   / u             package-menu-filter-upgradable
>>   / v             package-menu-filter-by-version
>
> I think so.  But of course the above commands unfortunately don't show
> matches interactively.  It would be useful if they did.

Incremental filtering while user is typing might cause too sluggish
response, so I'm fine with the current non-incremental filtering.

BTW, what I still miss in package filtering is a key to match
package descriptions (in addition to package names).  For example,
Ubuntu package manager allows filtering by these fields:
"Name", "Description and Name".

Message #35 received at 44550 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Kangas <stefankangas <at> gmail.com>
To: Juri Linkov <juri <at> linkov.net>
Cc: 44550 <at> debbugs.gnu.org, Jean Louis <bugs <at> gnu.support>
Subject: Re: bug#44550: 28.0.50; proposal for tabulated-list-mode to provide
 narrowing incremental search
Date: Mon, 16 Nov 2020 05:04:30 -0800

Juri Linkov <juri <at> linkov.net> writes:

>>> Isn't this like how incremental filtering works in 'list-packages'?
>>>
>>>   / /             package-menu-clear-filter
>>>   / a             package-menu-filter-by-archive
>>>   / k             package-menu-filter-by-keyword
>>>   / m             package-menu-filter-marked
>>>   / n             package-menu-filter-by-name
>>>   / s             package-menu-filter-by-status
>>>   / u             package-menu-filter-upgradable
>>>   / v             package-menu-filter-by-version
>>
>> I think so.  But of course the above commands unfortunately don't show
>> matches interactively.  It would be useful if they did.
>
> Incremental filtering while user is typing might cause too sluggish
> response, so I'm fine with the current non-incremental filtering.

That would entirely depend on how it's implemented, right?  AFAIR, Helm
has incremental filtering that is not sluggish.

> BTW, what I still miss in package filtering is a key to match
> package descriptions (in addition to package names).  For example,
> Ubuntu package manager allows filtering by these fields:
> "Name", "Description and Name".

Good idea, that would be useful (and straightforward to add).  Could you
please open a new bug report for that?

Message #38 received at 44550 <at> debbugs.gnu.org (full text, mbox):

From: Drew Adams <drew.adams <at> oracle.com>
To: Juri Linkov <juri <at> linkov.net>, Stefan Kangas <stefankangas <at> gmail.com>
Cc: 44550 <at> debbugs.gnu.org, Jean Louis <bugs <at> gnu.support>
Subject: RE: bug#44550: 28.0.50; proposal for tabulated-list-mode to provide
 narrowing incremental search
Date: Mon, 16 Nov 2020 08:22:30 -0800 (PST)

> Incremental filtering while user is typing might cause too sluggish
> response, so I'm fine with the current non-incremental filtering.

It should be optional, and it should be controllable
by users.  Wrt the latter, the things that might
affect such performance could be controllable on the
fly (e.g. increment/decrement this or that, toggle
this or that on/off)

> BTW, what I still miss in package filtering is a key to match
> package descriptions (in addition to package names).  For example,
> Ubuntu package manager allows filtering by these fields:
> "Name", "Description and Name".

Icicles allows for optionally matching such things,
which are, in effect separate parts of the same
candidate (different colums of the same row of the
table, in this case).

For example, when you use `C-x C-f' you can optionally
match only the file name, only the file content, or
both.  You separate the two patterns (or more, for
other kinds of candidates) with the char(s) of
`icicle-list-join-string', which by default is just
"^G^J".

Users can customize this, and code can bind it.
Those odd control chars are used because such a
string is unlikely to be part of candidates to be
matched.  But you can change it to just " ", for
example.  And you can always enter this join-string
by hitting `C-M-j'.  The string just appears as a
newline in the minibuffer.  That is, the different
pattern parts start on new lines.

This "multi-completion" can be used with progressive
completion.  E.g., you can provide different patterns
to match as different steps of matching.  You need not
provide patterns to match the different parts in the
same, multi-part pattern.  As always with progressive
completion, `S-SPC' starts a new completion, with a
new pattern, against the candidates that result from 
matching previous patterns.

Message #41 received at 44550 <at> debbugs.gnu.org (full text, mbox):

From: Jean Louis <bugs <at> gnu.support>
To: Drew Adams <drew.adams <at> oracle.com>
Cc: 44550 <at> debbugs.gnu.org, Stefan Kangas <stefankangas <at> gmail.com>,
 Juri Linkov <juri <at> linkov.net>
Subject: Re: bug#44550: 28.0.50; proposal for tabulated-list-mode to provide
 narrowing incremental search
Date: Mon, 16 Nov 2020 20:49:33 +0300

* Drew Adams <drew.adams <at> oracle.com> [2020-11-16 19:24]:
> > Incremental filtering while user is typing might cause too sluggish
> > response, so I'm fine with the current non-incremental filtering.
> 
> It should be optional, and it should be controllable
> by users.

Same thinking. It need not be automatically turned on but only when
user makes derived mode and binds the key to the function.

I would be happy if all elements of tabulated-list-entries are
concatenated with spaces to be searchable by such feature. Of course
it would be even better if programmer can decide to search only one column.

Feature description from Icicles could be used there as well.

Message #44 received at 44550 <at> debbugs.gnu.org (full text, mbox):

From: Jean Louis <bugs <at> gnu.support>
To: Juri Linkov <juri <at> linkov.net>
Cc: 44550 <at> debbugs.gnu.org, Stefan Kangas <stefankangas <at> gmail.com>
Subject: Re: bug#44550: 28.0.50; proposal for tabulated-list-mode to provide
 narrowing incremental search
Date: Tue, 17 Nov 2020 10:05:41 +0300

* Juri Linkov <juri <at> linkov.net> [2020-11-16 12:40]:
> >> Isn't this like how incremental filtering works in 'list-packages'?
> >>
> >>   / /             package-menu-clear-filter
> >>   / a             package-menu-filter-by-archive
> >>   / k             package-menu-filter-by-keyword
> >>   / m             package-menu-filter-marked
> >>   / n             package-menu-filter-by-name
> >>   / s             package-menu-filter-by-status
> >>   / u             package-menu-filter-upgradable
> >>   / v             package-menu-filter-by-version
> >
> > I think so.  But of course the above commands unfortunately don't show
> > matches interactively.  It would be useful if they did.
> 
> Incremental filtering while user is typing might cause too sluggish
> response, so I'm fine with the current non-incremental filtering.
> 
> BTW, what I still miss in package filtering is a key to match
> package descriptions (in addition to package names).  For example,
> Ubuntu package manager allows filtering by these fields:
> "Name", "Description and Name".

You are referring to package.el while proposal is directed for general
enhancement within tabulated-list.el

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.