Completions and history

Completions and history

[Ergus]

Hi:

I am wondering if we have some feature to list the minibuffer history
vanilla for example in completions. In ivy there was C-r which switched
completions to the minibuffer-history; icycles had a similar feature;
and helm also had something; but in the default completion system there
is not such feature as far as I know.

Some commands like previous-line-or-history-element or the
un-docummented previous-complete-history-element do part of the work,
but there is no way to list the history and select which may be useful
for find-file or M-: to repeat previous actions. The information is
there...

I suppose that this has been discussed before... so is there a reason
why this has not been implemented? Should I open a feature request or is
someone already opened?

Best,
Ergus

Re: Completions and history

[Juri Linkov]

> I am wondering if we have some feature to list the minibuffer history
> vanilla for example in completions. In ivy there was C-r which switched
> completions to the minibuffer-history; icycles had a similar feature;
> and helm also had something; but in the default completion system there
> is not such feature as far as I know.
>
> Some commands like previous-line-or-history-element or the
> un-docummented previous-complete-history-element do part of the work,
> but there is no way to list the history and select which may be useful
> for find-file or M-: to repeat previous actions. The information is
> there...
>
> I suppose that this has been discussed before... so is there a reason
> why this has not been implemented? Should I open a feature request or is
> someone already opened?

Indeed, this has been discussed recently in
https://lists.gnu.org/archive/html/emacs-devel/2021-12/msg00802.html
but no feature request was opened, since C-TAB is already taken by
file-cache-minibuffer-complete.

Re: Completions and history

[Ergus]

On Mon, Apr 11, 2022 at 07:56:58PM +0300, Juri Linkov wrote:
>> I am wondering if we have some feature to list the minibuffer history
>> vanilla for example in completions. In ivy there was C-r which switched
>> completions to the minibuffer-history; icycles had a similar feature;
>> and helm also had something; but in the default completion system there
>> is not such feature as far as I know.
>>
>> Some commands like previous-line-or-history-element or the
>> un-docummented previous-complete-history-element do part of the work,
>> but there is no way to list the history and select which may be useful
>> for find-file or M-: to repeat previous actions. The information is
>> there...
>>
>> I suppose that this has been discussed before... so is there a reason
>> why this has not been implemented? Should I open a feature request or is
>> someone already opened?
>
>Indeed, this has been discussed recently in
>https://lists.gnu.org/archive/html/emacs-devel/2021-12/msg00802.html
>but no feature request was opened, since C-TAB is already taken by
>file-cache-minibuffer-complete.
>
At least could we have documented how to enable this and then let the
user set it? Ivy users will find it comfortable in C-r to substitute the
Current isearch-backward, other may prefer something else. The default
binding may be agreed latter.

Re: Completions and history

[Juri Linkov]

>>> I suppose that this has been discussed before... so is there a reason
>>> why this has not been implemented? Should I open a feature request or is
>>> someone already opened?
>>
>> Indeed, this has been discussed recently in
>> https://lists.gnu.org/archive/html/emacs-devel/2021-12/msg00802.html
>> but no feature request was opened, since C-TAB is already taken by
>> file-cache-minibuffer-complete.
>
> At least could we have documented how to enable this and then let the
> user set it? Ivy users will find it comfortable in C-r to substitute the
> Current isearch-backward, other may prefer something else. The default
> binding may be agreed latter.

One problem is that completions are sorted alphabetically that
makes no sense for history items which are sorted chronologically.
So the first thing to do would be to add sorting keys in Completions
that will allow switching the order between alphabetical and unsorted
(history items are in chronological order, so unsorted should keep it)
that will change the value of 'completions-sort'.

Another question: should duplicate history items be retained
in the Completions window when history-delete-duplicates is nil?

Re: Completions and history

[Ergus]

On Tue, Apr 12, 2022 at 07:20:02PM +0300, Juri Linkov wrote:
>>>> I suppose that this has been discussed before... so is there a reason
>>>> why this has not been implemented? Should I open a feature request or is
>>>> someone already opened?
>>>
>>> Indeed, this has been discussed recently in
>>> https://lists.gnu.org/archive/html/emacs-devel/2021-12/msg00802.html
>>> but no feature request was opened, since C-TAB is already taken by
>>> file-cache-minibuffer-complete.
>>
>> At least could we have documented how to enable this and then let the
>> user set it? Ivy users will find it comfortable in C-r to substitute the
>> Current isearch-backward, other may prefer something else. The default
>> binding may be agreed latter.
>
>One problem is that completions are sorted alphabetically that
>makes no sense for history items which are sorted chronologically.
>So the first thing to do would be to add sorting keys in Completions
>that will allow switching the order between alphabetical and unsorted
>(history items are in chronological order, so unsorted should keep it)
>that will change the value of 'completions-sort'.
>
I have no idea about that, but it makes sense as you explain it.

>Another question: should duplicate history items be retained
>in the Completions window when history-delete-duplicates is nil?

In principle yes... unless you add another custom for that... But the
first is the important part.. to have the history list in order...

Re: Completions and history

[Ergus]

On Tue, Apr 12, 2022 at 07:20:02PM +0300, Juri Linkov wrote:
>>>> I suppose that this has been discussed before... so is there a reason
>>>> why this has not been implemented? Should I open a feature request or is
>>>> someone already opened?
>>>
>>> Indeed, this has been discussed recently in
>>> https://lists.gnu.org/archive/html/emacs-devel/2021-12/msg00802.html
>>> but no feature request was opened, since C-TAB is already taken by
>>> file-cache-minibuffer-complete.
>>
>> At least could we have documented how to enable this and then let the
>> user set it? Ivy users will find it comfortable in C-r to substitute the
>> Current isearch-backward, other may prefer something else. The default
>> binding may be agreed latter.
>
>One problem is that completions are sorted alphabetically that
>makes no sense for history items which are sorted chronologically.
>So the first thing to do would be to add sorting keys in Completions
>that will allow switching the order between alphabetical and unsorted
>(history items are in chronological order, so unsorted should keep it)
>that will change the value of 'completions-sort'.
>
A comment about this... completion-at-point-functions accept a list with
a format (START END COLLECTION . PROPS)

The PROPS can be any :completion-extra-properties plus predicate and
exclusive.. maybe the way to do this is to add a property :sort or
similar... Then on the other side we use that property to select the
sorting method... Does it makes sense?

>Another question: should duplicate history items be retained
>in the Completions window when history-delete-duplicates is nil?
>

Re: Completions and history

[Juri Linkov]

>> One problem is that completions are sorted alphabetically that
>> makes no sense for history items which are sorted chronologically.
>> So the first thing to do would be to add sorting keys in Completions
>> that will allow switching the order between alphabetical and unsorted
>> (history items are in chronological order, so unsorted should keep it)
>> that will change the value of 'completions-sort'.
>
> A comment about this... completion-at-point-functions accept a list with
> a format (START END COLLECTION . PROPS)
>
> The PROPS can be any :completion-extra-properties plus predicate and
> exclusive.. maybe the way to do this is to add a property :sort or
> similar... Then on the other side we use that property to select the
> sorting method... Does it makes sense?

It already works fine with:

```
(defun minibuffer-complete-history ()
  "Complete the minibuffer history as far as possible.
Like `minibuffer-complete' but completes on the history items
instead of the default completion table."
  (interactive)
  (let ((completions-sort nil))
    (completion-in-region (minibuffer--completion-prompt-end) (point-max)
                          (symbol-value minibuffer-history-variable)
                          nil)))

(define-key minibuffer-local-map [C-tab] 'minibuffer-complete-history)
```

So the only question is whether this should have a new defcustom?
Maybe 'minibuffer-complete-history-sort'?

>> Another question: should duplicate history items be retained
>> in the Completions window when history-delete-duplicates is nil?
>
> In principle yes... unless you add another custom for that... But the
> first is the important part.. to have the history list in order...

Another defcustom?  Maybe 'minibuffer-complete-history-delete-duplicates'?

Re: Completions and history

[Ergus]

On Tue, Apr 12, 2022 at 08:12:02PM +0300, Juri Linkov wrote:
>>> One problem is that completions are sorted alphabetically that
>>> makes no sense for history items which are sorted chronologically.
>>> So the first thing to do would be to add sorting keys in Completions
>>> that will allow switching the order between alphabetical and unsorted
>>> (history items are in chronological order, so unsorted should keep it)
>>> that will change the value of 'completions-sort'.
>>
>> A comment about this... completion-at-point-functions accept a list with
>> a format (START END COLLECTION . PROPS)
>>
>> The PROPS can be any :completion-extra-properties plus predicate and
>> exclusive.. maybe the way to do this is to add a property :sort or
>> similar... Then on the other side we use that property to select the
>> sorting method... Does it makes sense?
>
>It already works fine with:
>
>```
>(defun minibuffer-complete-history ()
>  "Complete the minibuffer history as far as possible.
>Like `minibuffer-complete' but completes on the history items
>instead of the default completion table."
>  (interactive)
>  (let ((completions-sort nil))
>    (completion-in-region (minibuffer--completion-prompt-end) (point-max)
>                          (symbol-value minibuffer-history-variable)
>                          nil)))
>
>(define-key minibuffer-local-map [C-tab] 'minibuffer-complete-history)
>```
>
>So the only question is whether this should have a new defcustom?
>Maybe 'minibuffer-complete-history-sort'?
>
>>> Another question: should duplicate history items be retained
>>> in the Completions window when history-delete-duplicates is nil?
>>
>> In principle yes... unless you add another custom for that... But the
>> first is the important part.. to have the history list in order...
>
>Another defcustom?  Maybe 'minibuffer-complete-history-delete-duplicates'?

Hi Juri, somehow this does not work for me completely fine (at least not
as I was expecting)...

  I mean, then we TAB the completion is updated but with normal, not
history completions... I would expect that C-tab (or any key) somehow
toggle the completions to a history list... so when using history to
complete they persist until I toggle them back to normal
completion....

Is that too much to request?? If so, then I will try to be used to this
one, but somehow I feel it a bit confusing.

Re: Completions and history

[Juri Linkov]

> I mean, then we TAB the completion is updated but with normal, not
> history completions... I would expect that C-tab (or any key) somehow
> toggle the completions to a history list... so when using history to
> complete they persist until I toggle them back to normal
> completion....
>
> Is that too much to request?? If so, then I will try to be used to this
> one, but somehow I feel it a bit confusing.

Toggling the completion mode like you proposed has such benefit
that a less convenient key could be bound to toggle since it will be used
less often - just to toggle, then you can use the easy to type TAB.

Re: Completions and history

[Augusto Stoffel]

On Mon, 11 Apr 2022 at 19:40, Ergus <spacibba@aol.com> wrote:

> On Mon, Apr 11, 2022 at 07:56:58PM +0300, Juri Linkov wrote:
>>> I am wondering if we have some feature to list the minibuffer history
>>> vanilla for example in completions. In ivy there was C-r which switched
>>> completions to the minibuffer-history; icycles had a similar feature;
>>> and helm also had something; but in the default completion system there
>>> is not such feature as far as I know.

For the record, Consult provides exactly that command (consult-history)
and it works beautifully.  The same command also works in a few special
modes like eshell and comint that have a notion of history.

Unlike Ivy, the Consult command is not tied to a specific completion
framework (I don't know how Icicles is in that regard).

RE: [External] : Re: Completions and history

[Drew Adams]

> >>> In ivy there was C-r which switched
> >>> completions to the minibuffer-history;
> >>> icycles had a similar feature;
> >>> and helm also had something;
> 
> For the record, Consult provides exactly that command (consult-history)
> and it works beautifully.  The same command also works in a few special
> modes like eshell and comint that have a notion of history.
> 
> Unlike Ivy, the Consult command is not tied to a specific completion
> framework (I don't know how Icicles is in that regard).

I already said what Icicles offers in this regard.
Whether you consider it a "completion framework"
is up to you.  It's just a minor mode - easy to
turn on and off.

With Icicles:

You don't need any separate command, to complete
against the history, any more than with vanilla
Emacs you need a separate command to search, or
to cycle through, the input history.

For any use of the minibuffer (not just for use
with completion), you can at any time get previous
inputs in the usual Emacs ways or by completing.

And for completing there are a couple different
ways.  See my previous explanation here:

https://lists.gnu.org/archive/html/emacs-devel/2021-12/msg00949.html

And the doc here:

https://www.emacswiki.org/emacs/Icicles_-_History_Enhancements

Re: [External] : Re: Completions and history

[Juri Linkov]

>> For the record, Consult provides exactly that command (consult-history)
>> and it works beautifully.  The same command also works in a few special
>> modes like eshell and comint that have a notion of history.
>>
>> Unlike Ivy, the Consult command is not tied to a specific completion
>> framework (I don't know how Icicles is in that regard).
>
> I already said what Icicles offers in this regard.
> Whether you consider it a "completion framework"
> is up to you.  It's just a minor mode - easy to
> turn on and off.

Does Icicles support history completion in eshell and comint?

RE: [External] : Re: Completions and history

[Drew Adams]

> Does Icicles support history completion in eshell and comint?

Yes, I believe so.

Command `icicle-comint-search':

 Use `icicle-search' to pick up a previous input for reuse.
 Use this in a `comint-mode' buffer, such as *shell* or
 *inferior-lisp*.

 This searches your interactive history in the buffer for a
 match to your current input, which you can change dynamically.
 When you choose a previous input, it is copied to the current
 prompt, for reuse.

 If the region is active, then only it is searched; otherwise,
 the entire buffer is searched.
 ...

https://www.emacswiki.org/emacs/Icicles_-_Other_Search_Commands#IciclesShell

Command `icicle-comint-command':

 Retrieve a previously used command.
 Use this in a `comint-mode' buffer such as `*shell*' or
 `*inferior-lisp*'.

Option `icicle-comint-dynamic-complete-replacements':

 A list of function replacements, for
 `icicle-comint-dynamic-complete' to replace the functions in
 `comint-dynamic-complete-functions'.  You can use this to
 provide Icicles completion for various modes that inherit from
 Comint mode.  By default, it treats Comint mode and Shell mode.

And there's some support for completion at point in these
contexts.  But in general, Icicles is about minibuffer
completion, not so much buffer-text completion.

https://www.emacswiki.org/emacs/Icicles_-_Defining_Completion_for_Comint_Modes

___

Anyway, my post was about _minibuffer_ history.

And about the history of text you've had in the
minibuffer at some point, but that you never entered
as input (chose with `RET', as opposed to acted on
in some other way or edited with).

The latter is important in the context of completion
and cycling, as I explained earlier.  AFAIK, only
Icicles gives you access to such a history.  (I'll
be pleased to learn that other libraries also offer
this now.)

Re: [External] : Re: Completions and history

[Juri Linkov]

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

>> Does Icicles support history completion in eshell and comint?
>
> Yes, I believe so.
>
> Command `icicle-comint-command':
>
>  Retrieve a previously used command.
>  Use this in a `comint-mode' buffer such as `*shell*' or
>  `*inferior-lisp*'.

It seems `icicle-comint-command' does the same as
`comint-dynamic-list-input-ring' bound to `C-c C-l'.

Maybe the same key `C-c C-l' could be bound by default
in the minibuffer to enable history completion?

BTW, currently this command highlights the header line only partly.
Here is a fix to keep text properties by replace-match:


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: comint-dynamic-list-input-ring.patch --]
[-- Type: text/x-diff, Size: 1085 bytes --]

diff --git a/lisp/comint.el b/lisp/comint.el
index 56082f622a..88eaf1120e 100644
--- a/lisp/comint.el
+++ b/lisp/comint.el
@@ -1110,7 +1110,8 @@ comint-dynamic-list-input-ring
 	  (use-local-map keymap))
 	(forward-line 3)
 	(while (search-backward "completion" nil 'move)
-	  (replace-match "history reference")))
+	  (replace-match (apply #'propertize "history reference"
+				(text-properties-at (point))))))
       (sit-for 0)
       (message "Hit space to flush")
       (setq comint-dynamic-list-input-ring-window-conf conf)
diff --git a/lisp/minibuffer.el b/lisp/minibuffer.el
index f60af482da..a4a04fc4ec 100644
--- a/lisp/minibuffer.el
+++ b/lisp/minibuffer.el
@@ -1895,9 +1980,7 @@ completions-detailed
   :version "28.1")
 
 (defcustom completions-header-format
-  (propertize "%s possible completions:\n"
-              'face 'shadow
-              :help "Please select a completion")
+  (propertize "%s possible completions:\n" 'face 'shadow)
   "Format of completions header.
 It may contain one %s to show the total count of completions.
 When nil, no header is shown."

Re: [External] : Re: Completions and history

[Augusto Stoffel]

On Wed, 13 Apr 2022 at 10:50, Juri Linkov <juri@linkov.net> wrote:

> Maybe the same key `C-c C-l' could be bound by default
> in the minibuffer to enable history completion?

Discussing default keybindings tends to be rather unfruitful, but still:
unless I'm missing something, `M-r' (previous-matching-history-element)
is strictly less powerful than `C-M-r' (isearch-backward-regexp).
History completion is quite handy and would be a better use for `M-r' in
my opinion.

Re: [External] : Re: Completions and history

[Po Lu]

Augusto Stoffel <arstoffel@gmail.com> writes:

> Discussing default keybindings tends to be rather unfruitful, but still:
> unless I'm missing something, `M-r' (previous-matching-history-element)
> is strictly less powerful than `C-M-r' (isearch-backward-regexp).
> History completion is quite handy and would be a better use for `M-r' in
> my opinion.

M-r is much easier to type than C-M-r, so if anything it should be the
other way around.

Or even better we could have M-S-r and M-S-s bound to history
completion.

Re: [External] : Re: Completions and history

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > > Discussing default keybindings tends to be rather unfruitful, but still:
  > > unless I'm missing something, `M-r' (previous-matching-history-element)
  > > is strictly less powerful than `C-M-r' (isearch-backward-regexp).
  > > History completion is quite handy and would be a better use for `M-r' in
  > > my opinion.

  > M-r is much easier to type than C-M-r, so if anything it should be the
  > other way around.

Consistency with general patterns of commands is also relevant here.
For example, C-M-s is regexp incremental forward search.

-- 
Dr Richard Stallman (https://stallman.org)
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

RE: [External] : Re: Completions and history

[Drew Adams]

> > Maybe the same key `C-c C-l' could be bound by default
> > in the minibuffer to enable history completion?
> 
> Discussing default keybindings tends to be rather
> unfruitful, but still: unless I'm missing something,
> `M-r' (previous-matching-history-element)
> is strictly less powerful than `C-M-r'
> (isearch-backward-regexp).

Dunno why you would choose to compare those two.

Anyway, Isearch key `C-M-r' is "more powerful" than
Isearch key `C-r' too.  So what?  There are good
reasons why Emacs has two different keys for those
different commands.

> History completion is quite handy and would be a
> better use for `M-r' in my opinion.

Of course it's quite handy.  So is simple history
search with `M-r` (previous-matching-history-element).

Let's please not try to cram the proposed feature
onto an existing key binding.  Users should _also_
be able to complete against history items.

As the guy who long ago tried to get Emacs more
interested in using completion for minibuffer
reading, I'm convinced of its utility.

That doesn't mean completion is always the best way
to let users choose something.  It's just one way.

It doesn't mean that completion should replace other
longstanding ways to choose things, especially when
it doesn't offer the same possibilities.
___

I'll give you an analogous how-to-choose from
Icicles, FWIW:

You can use key `C-,' in the minibuffer during
completion to change to a different sort order.

How to choose the sort order?  One way is completion:
You can pick one from those available in the current
context (you can see them in *Completions*).  Another
way is just cycling among them, without bothering to
see them all or bothering to type input to match one.

Icicles offers both possibilities, both (1) as a user
preference (Customize option) and (2) on the fly, for
any given use of `C-,'.

In fact, the option allows three possibilities:

 1. Always use completion.
 2. Always use cycling.
 3. Use completion if there are more than N sort
    orders to choose from; else use cycling.

`C-u' flips the behavior: if the option would
normally call for completion then cycle instead,
and vice versa.

Why go to the trouble of providing those different
ways to change the sort order?  Because completion,
though "quite handy", as you say, isn't always the
best or quickest way to choose something.  Cycling
isn't always the best way either.

A simple rule is fine, but a given user, with a
given command that involves choosing something,
can want this or that behavior.  Let users choose
what they want easily.

Re: [External] : Re: Completions and history

[Juri Linkov]

>> > Maybe the same key `C-c C-l' could be bound by default
>> > in the minibuffer to enable history completion?
>>
>> Discussing default keybindings tends to be rather
>> unfruitful, but still: unless I'm missing something,
>> `M-r' (previous-matching-history-element)
>> is strictly less powerful than `C-M-r'
>> (isearch-backward-regexp).
>
> Dunno why you would choose to compare those two.

Maybe history completion could be bound to 'C-c TAB' like in Icicles.

Re: [External] : Re: Completions and history

[Juri Linkov]

>> Maybe the same key `C-c C-l' could be bound by default
>> in the minibuffer to enable history completion?
>
> Discussing default keybindings tends to be rather unfruitful, but still:
> unless I'm missing something, `M-r' (previous-matching-history-element)
> is strictly less powerful than `C-M-r' (isearch-backward-regexp).
> History completion is quite handy and would be a better use for `M-r' in
> my opinion.

In comint/shell `M-r' runs history isearch, so it would add
more confusion when it will be bound to history completion.

RE: [External] : Re: Completions and history

[Drew Adams]

> > Command `icicle-comint-command':
> >  Retrieve a previously used command.
> >  Use this in a `comint-mode' buffer such as `*shell*' or
> >  `*inferior-lisp*'.
> 
> It seems `icicle-comint-command' does the same as
> `comint-dynamic-list-input-ring' bound to `C-c C-l'.

No, it doesn't.  The only similarity is that
they both let you choose a comint history item.

`icicle-comint-command' is a multi-command.  And
it shows completion candidates in *Completions*.

> Maybe the same key `C-c C-l' could be bound by default
> in the minibuffer to enable history completion?

Why would that be appropriate?

`C-c' followed by a control char is reserved for
major modes.  Even if Emacs has recently given the
minibuffer its own major mode (maybe a misfeature),
I think that such a key is inappropriate for the
minibuffer.

The major mode that's really involved (should be
anyway) when you use the minibuffer is the major
mode of the buffer where you activated use of the
minibuffer (at least at the outset of that
activation).

When in `comint-mode', it makes sense to have such
a key bound to such a command.  It doesn't make
sense to use that key for a minibuffer keymap, IMO.

> BTW, currently this command highlights the header line only partly.
> Here is a fix to keep text properties by replace-match:

That's orthogonal to the rest of your message, IIRC.
It's a change to `comint-dynamic-list-input-ring'.
I have no comment on that (other than it's unrelated
to the rest of your msg).