bug#44550: 28.0.50; proposal for tabulated-list-mode to provide narrowing incremental search

bug#44550: 28.0.50; proposal for tabulated-list-mode to provide narrowing incremental search

[Jean Louis]

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
⎔ λ 🄯 𝍄 𝌡 𝌚

bug#44550: 28.0.50; proposal for tabulated-list-mode to provide narrowing incremental search

[Eli Zaretskii]

> Date: Tue, 10 Nov 2020 13:36:03 +0300
> From: Jean Louis <bugs@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.

bug#44550: 28.0.50; proposal for tabulated-list-mode to provide narrowing incremental search

[Jean Louis]

* Eli Zaretskii <eliz@gnu.org> [2020-11-10 18:57]:
> > Date: Tue, 10 Nov 2020 13:36:03 +0300
> > From: Jean Louis <bugs@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.

bug#44550: 28.0.50; proposal for tabulated-list-mode to provide narrowing incremental search

[Eli Zaretskii]

> Date: Tue, 10 Nov 2020 22:57:35 +0300
> From: Jean Louis <bugs@gnu.support>
> Cc: 44550@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.

bug#44550: 28.0.50; proposal for tabulated-list-mode to provide narrowing incremental search

[Jean Louis]

* Eli Zaretskii <eliz@gnu.org> [2020-11-11 18:35]:
> > Date: Tue, 10 Nov 2020 22:57:35 +0300
> > From: Jean Louis <bugs@gnu.support>
> > Cc: 44550@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.

bug#44550: 28.0.50; proposal for tabulated-list-mode to provide narrowing incremental search

[Juri Linkov]

> - 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

bug#44550: 28.0.50; proposal for tabulated-list-mode to provide narrowing incremental search

[Jean Louis]

* Juri Linkov <juri@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.

bug#44550: 28.0.50; proposal for tabulated-list-mode to provide narrowing incremental search

[Drew Adams]

> > 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).

bug#44550: 28.0.50; proposal for tabulated-list-mode to provide narrowing incremental search

[Stefan Kangas]

Juri Linkov <juri@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.

bug#44550: 28.0.50; proposal for tabulated-list-mode to provide narrowing incremental search

[Juri Linkov]

>> 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".

bug#44550: 28.0.50; proposal for tabulated-list-mode to provide narrowing incremental search

[Stefan Kangas]

Juri Linkov <juri@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?

bug#44699: Add package filter by description

[Juri Linkov]

Severity: wishlist

>> 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?

Opened a new bug report here.

bug#44699: Add package filter by description

[Stefan Kangas]

[-- Attachment #1: Type: text/plain, Size: 522 bytes --]

tags 44699 + patch
thanks

Juri Linkov <juri@linkov.net> writes:

> Severity: wishlist
>
>>> 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?
>
> Opened a new bug report here.

Thanks.  How does the attached patch look?

[-- Attachment #2: 0001-Add-command-to-filter-package-menu-by-name-or-descri.patch --]
[-- Type: text/x-diff, Size: 6791 bytes --]

From b149068c0c046c40d0814213088caf7a42f872f2 Mon Sep 17 00:00:00 2001
From: Stefan Kangas <stefan@marxist.se>
Date: Tue, 17 Nov 2020 03:41:04 +0100
Subject: [PATCH] Add command to filter package menu by name or description

* lisp/emacs-lisp/package.el (package-menu-filter-by-description):
(package-menu-filter-by-name-or-description): New commands to filter
the package menu.
(package-menu-mode-map): Bind the above new commands.
(package-menu-mode-menu): Add new commands to the menu.
* doc/emacs/package.texi (Package Menu): Document new commands.
---
 doc/emacs/package.texi     | 16 ++++++++++++++
 etc/NEWS                   |  4 +++-
 lisp/emacs-lisp/package.el | 43 ++++++++++++++++++++++++++++++++++++++
 3 files changed, 62 insertions(+), 1 deletion(-)

diff --git a/doc/emacs/package.texi b/doc/emacs/package.texi
index 56e8ee1363..4981dd50c7 100644
--- a/doc/emacs/package.texi
+++ b/doc/emacs/package.texi
@@ -187,6 +187,14 @@ Package Menu
 This prompts for a package archive (e.g., @samp{gnu}), then shows only
 packages from that archive.
 
+@item / d
+@kindex / d @r{(Package Menu)}
+@findex package-menu-filter-by-description
+Filter package list by description
+(@code{package-menu-filter-by-description}).  This prompts for a
+regular expression, then shows only packages with descriptions
+matching that regexp.
+
 @item / k
 @kindex / k @r{(Package Menu)}
 @findex package-menu-filter-by-keyword
@@ -194,6 +202,14 @@ Package Menu
 This prompts for a keyword (e.g., @samp{games}), then shows only
 packages with that keyword.
 
+@item / N
+@kindex / N @r{(Package Menu)}
+@findex package-menu-filter-by-name-or-description
+Filter package list by name or description
+(@code{package-menu-filter-by-name-or-description}).  This prompts for
+a regular expression, then shows only packages with a name or
+description matching that regexp.
+
 @item / n
 @kindex / n @r{(Package Menu)}
 @findex package-menu-filter-by-name
diff --git a/etc/NEWS b/etc/NEWS
index 79c937b9ae..9f39851b4a 100644
--- a/etc/NEWS
+++ b/etc/NEWS
@@ -831,12 +831,14 @@ equivalent to '(map (:sym sym))'.
 
 +++
 *** New commands to filter the package list.
-The filter command key bindings are as follows:
+The filter commands are bound to the following keys:
 
 key             binding
 ---             -------
 / a             package-menu-filter-by-archive
+/ d             package-menu-filter-by-description
 / k             package-menu-filter-by-keyword
+/ N             package-menu-filter-by-name-or-description
 / n             package-menu-filter-by-name
 / s             package-menu-filter-by-status
 / v             package-menu-filter-by-version
diff --git a/lisp/emacs-lisp/package.el b/lisp/emacs-lisp/package.el
index fbab6debd5..d78a1a2856 100644
--- a/lisp/emacs-lisp/package.el
+++ b/lisp/emacs-lisp/package.el
@@ -2704,7 +2704,9 @@ package-menu-mode-map
     (define-key map "(" #'package-menu-toggle-hiding)
     (define-key map (kbd "/ /") 'package-menu-clear-filter)
     (define-key map (kbd "/ a") 'package-menu-filter-by-archive)
+    (define-key map (kbd "/ d") 'package-menu-filter-by-description)
     (define-key map (kbd "/ k") 'package-menu-filter-by-keyword)
+    (define-key map (kbd "/ N") 'package-menu-filter-by-name-or-description)
     (define-key map (kbd "/ n") 'package-menu-filter-by-name)
     (define-key map (kbd "/ s") 'package-menu-filter-by-status)
     (define-key map (kbd "/ v") 'package-menu-filter-by-version)
@@ -2736,8 +2738,11 @@ package-menu-mode-menu
     "--"
     ("Filter Packages"
      ["Filter by Archive" package-menu-filter-by-archive :help "Filter packages by archive"]
+     ["Filter by Description" package-menu-filter-by-description :help "Filter packages by description"]
      ["Filter by Keyword" package-menu-filter-by-keyword :help "Filter packages by keyword"]
      ["Filter by Name" package-menu-filter-by-name :help "Filter packages by name"]
+     ["Filter by Name or Description" package-menu-filter-by-name-or-description
+      :help "Filter packages by name or description"]
      ["Filter by Status" package-menu-filter-by-status :help "Filter packages by status"]
      ["Filter by Version" package-menu-filter-by-version :help "Filter packages by version"]
      ["Filter Marked" package-menu-filter-marked :help "Filter packages marked for upgrade"]
@@ -3765,6 +3770,23 @@ package-menu-filter-by-archive
                                              (string-join archive ",")
                                            archive)))))
 
+(defun package-menu-filter-by-description (description)
+  "Filter the \"*Packages*\" buffer by DESCRIPTION regexp.
+Display only packages with a description that matches regexp
+DESCRIPTION.
+
+When called interactively, prompt for DESCRIPTION.
+
+If DESCRIPTION is nil or the empty string, show all packages."
+  (interactive (list (read-regexp "Filter by description (regexp)")))
+  (package--ensure-package-menu-mode)
+  (if (or (not description) (string-empty-p description))
+      (package-menu--generate t t)
+    (package-menu--filter-by (lambda (pkg-desc)
+                        (string-match description
+                                      (package-desc-summary pkg-desc)))
+                      (format "desc:%s" description))))
+
 (defun package-menu-filter-by-keyword (keyword)
   "Filter the \"*Packages*\" buffer by KEYWORD.
 Display only packages with specified KEYWORD.
@@ -3790,6 +3812,27 @@ package-menu-filter-by-keyword
 (define-obsolete-function-alias
   'package-menu-filter #'package-menu-filter-by-keyword "27.1")
 
+(defun package-menu-filter-by-name-or-description (name-or-description)
+  "Filter the \"*Packages*\" buffer by NAME-OR-DESCRIPTION regexp.
+Display only packages with a name-or-description that matches regexp
+NAME-OR-DESCRIPTION.
+
+When called interactively, prompt for NAME-OR-DESCRIPTION.
+
+If NAME-OR-DESCRIPTION is nil or the empty string, show all
+packages."
+  (interactive (list (read-regexp "Filter by name or description (regexp)")))
+  (package--ensure-package-menu-mode)
+  (if (or (not name-or-description) (string-empty-p name-or-description))
+      (package-menu--generate t t)
+    (package-menu--filter-by (lambda (pkg-desc)
+                        (or (string-match name-or-description
+                                          (package-desc-summary pkg-desc))
+                            (string-match name-or-description
+                                          (symbol-name
+                                           (package-desc-name pkg-desc)))))
+                      (format "name-or-desc:%s" name-or-description))))
+
 (defun package-menu-filter-by-name (name)
   "Filter the \"*Packages*\" buffer by NAME regexp.
 Display only packages with name that matches regexp NAME.
-- 
2.29.2

bug#44699: Add package filter by description

[Juri Linkov]

>>>> 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?
>>
>> Opened a new bug report here.
>
> Thanks.  How does the attached patch look?

I was not sure what is better: to create a command that matches only
descriptions *OR* a command that matches names and descriptions.
But you created two commands that is much better - problem solved! :-)

I tested your patch and both commands work fine, thanks.

bug#44699: Add package filter by description

[Stefan Kangas]

tags 44699 fixed
close 44699 28.1
thanks

Juri Linkov <juri@linkov.net> writes:

> I was not sure what is better: to create a command that matches only
> descriptions *OR* a command that matches names and descriptions.
> But you created two commands that is much better - problem solved! :-)

Yup.  :-)

I was a bit unsure about the keybinding at first, but I think this
should work.  We have time to tweak it before Emacs 28.1 is released if
we want to.

> I tested your patch and both commands work fine, thanks.

Thanks for testing, and for the feature idea.  Pushed to master as
commit 1ac5fd2624.

bug#44550: 28.0.50; proposal for tabulated-list-mode to provide narrowing incremental search

[Drew Adams]

> 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.

bug#44550: 28.0.50; proposal for tabulated-list-mode to provide narrowing incremental search

[Jean Louis]

* Drew Adams <drew.adams@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.

bug#44550: 28.0.50; proposal for tabulated-list-mode to provide narrowing incremental search

[Jean Louis]

* Juri Linkov <juri@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