GNU bug report logs - #57163
completing-read not allow cycling of the options by default

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 57163 in the body.
You can then email your comments to 57163 AT debbugs.gnu.org in the normal way.

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

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

From: uzibalqa <uzibalqa <at> proton.me>
To: "bug-gnu-emacs <at> gnu.org" <bug-gnu-emacs <at> gnu.org>
Subject: completing-read not allow cycling of the options by default
Date: Fri, 12 Aug 2022 22:14:30 +0000

[Message part 1 (text/plain, inline)]

Why is it that things like completing-read not allow cycling of the options by default? Especially for new user, not having the ability to cycle by default is a terrible plan,

[Message part 2 (text/html, inline)]

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

From: Michael Heerdegen <michael_heerdegen <at> web.de>
To: uzibalqa via "Bug reports for GNU Emacs, the Swiss army knife of text
 editors" <bug-gnu-emacs <at> gnu.org>
Cc: 57163 <at> debbugs.gnu.org, uzibalqa <uzibalqa <at> proton.me>
Subject: Re: bug#57163: completing-read not allow cycling of the options by
 default
Date: Sat, 13 Aug 2022 06:52:54 +0200

uzibalqa via "Bug reports for GNU Emacs, the Swiss army knife of text
editors" <bug-gnu-emacs <at> gnu.org> writes:

> Why is it that things like completing-read not allow cycling of the
> options by default?

You mean the completion candidates?  M-<up> and M-<down> do that (by
default).

Michael.

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Michael Heerdegen <michael_heerdegen <at> web.de>
Cc: 57163 <at> debbugs.gnu.org, uzibalqa <at> proton.me
Subject: Re: bug#57163: completing-read not allow cycling of the options by
 default
Date: Sat, 13 Aug 2022 09:01:06 +0300

> Cc: uzibalqa <at> proton.me
> From: Michael Heerdegen <michael_heerdegen <at> web.de>
> Date: Sat, 13 Aug 2022 06:52:54 +0200
> 
> uzibalqa via "Bug reports for GNU Emacs, the Swiss army knife of text
> editors" <bug-gnu-emacs <at> gnu.org> writes:
> 
> > Why is it that things like completing-read not allow cycling of the
> > options by default?
> 
> You mean the completion candidates?  M-<up> and M-<down> do that (by
> default).

As does repeatedly pressing TAB, right?  Or maybe I don't understand
what is meant by "cycling" in this context?  An example of using
completing-read and the lack of cycling would be appreciated.

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

From: uzibalqa <uzibalqa <at> proton.me>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: Michael Heerdegen <michael_heerdegen <at> web.de>, 57163 <at> debbugs.gnu.org
Subject: Re: bug#57163: completing-read not allow cycling of the options by
 default
Date: Sat, 13 Aug 2022 14:32:02 +0000

------- Original Message -------
On Saturday, August 13th, 2022 at 6:01 AM, Eli Zaretskii <eliz <at> gnu.org> wrote:


> > Cc: uzibalqa <at> proton.me
> > From: Michael Heerdegen michael_heerdegen <at> web.de
> > Date: Sat, 13 Aug 2022 06:52:54 +0200
> >
> > uzibalqa via "Bug reports for GNU Emacs, the Swiss army knife of text
> > editors" bug-gnu-emacs <at> gnu.org writes:
> >
> > > Why is it that things like completing-read not allow cycling of the
> > > options by default?
> >
> > You mean the completion candidates? M-<up> and M-<down> do that (by
> > default).
>
>
> As does repeatedly pressing TAB, right? Or maybe I don't understand
> what is meant by "cycling" in this context? An example of using
> completing-read and the lack of cycling would be appreciated.

Correct, TAB, M-<up>, M-<down> do not execute any functionality

Consider the following function.  Call the function with "M-x change-cursor".
TAB produces "[Complete, but not unique]"; whilst "M-down" and "M-up" result
in [M-down is undefined]  and [M-up is undefined].

(defun change-cursor (form)
  "Modify the cursor form."

  (interactive
   (list
    (let ( (cseq '("bar" "hbar" "hollow" "box")) )
      (completing-read " Cursor: " cseq nil t "box"))))

  (pcase form
    ("bar"
     (set-default 'cursor-type 'bar)
    ("hbar"
     (set-default 'cursor-type 'hbar)
    ("hollow"
     (set-default 'cursor-type 'hollow)
    ("box"
     (set-default 'cursor-type 'box))) )

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: uzibalqa <uzibalqa <at> proton.me>
Cc: michael_heerdegen <at> web.de, 57163 <at> debbugs.gnu.org
Subject: Re: bug#57163: completing-read not allow cycling of the options by
 default
Date: Sat, 13 Aug 2022 18:14:43 +0300

> Date: Sat, 13 Aug 2022 14:32:02 +0000
> From: uzibalqa <uzibalqa <at> proton.me>
> Cc: Michael Heerdegen <michael_heerdegen <at> web.de>, 57163 <at> debbugs.gnu.org
> 
> > > You mean the completion candidates? M-<up> and M-<down> do that (by
> > > default).
> 
> > As does repeatedly pressing TAB, right? Or maybe I don't understand
> > what is meant by "cycling" in this context? An example of using
> > completing-read and the lack of cycling would be appreciated.
> 
> Correct, TAB, M-<up>, M-<down> do not execute any functionality

They do here, see below.

> Consider the following function.  Call the function with "M-x change-cursor".
> TAB produces "[Complete, but not unique]"; whilst "M-down" and "M-up" result
> in [M-down is undefined]  and [M-up is undefined].
> 
> (defun change-cursor (form)
>   "Modify the cursor form."
> 
>   (interactive
>    (list
>     (let ( (cseq '("bar" "hbar" "hollow" "box")) )
>       (completing-read " Cursor: " cseq nil t "box"))))
> 
>   (pcase form
>     ("bar"
>      (set-default 'cursor-type 'bar)
>     ("hbar"
>      (set-default 'cursor-type 'hbar)
>     ("hollow"
>      (set-default 'cursor-type 'hollow)
>     ("box"
>      (set-default 'cursor-type 'box))) )

If I evaluate

    (let ( (cseq '("bar" "hbar" "hollow" "box")) )
      (completing-read " Cursor: " cseq nil t "box"))

then I can cycle through all the candidates with M-n and M-p.  TAB
doesn't do anything because the window showing the candidates is small
and shows all of them at once.

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

From: uzibalqa <uzibalqa <at> proton.me>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: michael_heerdegen <at> web.de, 57163 <at> debbugs.gnu.org
Subject: Re: bug#57163: completing-read not allow cycling of the options by
 default
Date: Sat, 13 Aug 2022 16:09:53 +0000

------- Original Message -------
On Saturday, August 13th, 2022 at 3:14 PM, Eli Zaretskii <eliz <at> gnu.org> wrote:


> > Date: Sat, 13 Aug 2022 14:32:02 +0000
> > From: uzibalqa uzibalqa <at> proton.me
> > Cc: Michael Heerdegen michael_heerdegen <at> web.de, 57163 <at> debbugs.gnu.org
> >
> > > > You mean the completion candidates? M-<up> and M-<down> do that (by
> > > > default).
> >
> > > As does repeatedly pressing TAB, right? Or maybe I don't understand
> > > what is meant by "cycling" in this context? An example of using
> > > completing-read and the lack of cycling would be appreciated.
> >
> > Correct, TAB, M-<up>, M-<down> do not execute any functionality
>
>
> They do here, see below.
>
> > Consider the following function. Call the function with "M-x change-cursor".
> > TAB produces "[Complete, but not unique]"; whilst "M-down" and "M-up" result
> > in [M-down is undefined] and [M-up is undefined].
> >
> > (defun change-cursor (form)
> > "Modify the cursor form."
> >
> > (interactive
> > (list
> > (let ( (cseq '("bar" "hbar" "hollow" "box")) )
> > (completing-read " Cursor: " cseq nil t "box"))))
> >
> > (pcase form
> > ("bar"
> > (set-default 'cursor-type 'bar)
> > ("hbar"
> > (set-default 'cursor-type 'hbar)
> > ("hollow"
> > (set-default 'cursor-type 'hollow)
> > ("box"
> > (set-default 'cursor-type 'box))) )
>
>
> If I evaluate
>
> (let ( (cseq '("bar" "hbar" "hollow" "box")) )
> (completing-read " Cursor: " cseq nil t "box"))
>
> then I can cycle through all the candidates with M-n and M-p. TAB
> doesn't do anything because the window showing the candidates is small
> and shows all of them at once.

M-n and M-p work as you say.  Have noticed that when one is using debug-on-error,
using M-n until the last option gives

Debugger entered--Lisp error: (user-error "End of defaults; no next item")
  signal(user-error ("End of defaults; no next item"))
  user-error("End of defaults; no next item")

After that, doing M-p gives [M-p is undefined]

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: uzibalqa <uzibalqa <at> proton.me>
Cc: michael_heerdegen <at> web.de, 57163 <at> debbugs.gnu.org
Subject: Re: bug#57163: completing-read not allow cycling of the options by
 default
Date: Sat, 13 Aug 2022 20:21:57 +0300

> Date: Sat, 13 Aug 2022 16:09:53 +0000
> From: uzibalqa <uzibalqa <at> proton.me>
> Cc: michael_heerdegen <at> web.de, 57163 <at> debbugs.gnu.org
> 
> M-n and M-p work as you say.  Have noticed that when one is using debug-on-error,
> using M-n until the last option gives
> 
> Debugger entered--Lisp error: (user-error "End of defaults; no next item")
>   signal(user-error ("End of defaults; no next item"))
>   user-error("End of defaults; no next item")

Well, don't set debug-on-error, then.

> After that, doing M-p gives [M-p is undefined]

Because you are in the debugger, in recursive-edit.  Type C-] to exit
that.

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

From: uzibalqa <uzibalqa <at> proton.me>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: michael_heerdegen <at> web.de, 57163 <at> debbugs.gnu.org
Subject: Re: bug#57163: completing-read not allow cycling of the options by
 default
Date: Sat, 13 Aug 2022 18:15:26 +0000

------- Original Message -------
On Saturday, August 13th, 2022 at 5:21 PM, Eli Zaretskii <eliz <at> gnu.org> wrote:


> > Date: Sat, 13 Aug 2022 16:09:53 +0000
> > From: uzibalqa uzibalqa <at> proton.me
> > Cc: michael_heerdegen <at> web.de, 57163 <at> debbugs.gnu.org
> >
> > M-n and M-p work as you say. Have noticed that when one is using debug-on-error,
> > using M-n until the last option gives
> >
> > Debugger entered--Lisp error: (user-error "End of defaults; no next item")
> > signal(user-error ("End of defaults; no next item"))
> > user-error("End of defaults; no next item")
>
>
> Well, don't set debug-on-error, then.
>
> > After that, doing M-p gives [M-p is undefined]
>
>
> Because you are in the debugger, in recursive-edit. Type C-] to exit
> that.

Should it be a user-error though?  Is there any scheme to set another keybinding
for `M-n` and `M-p` for things like completing-read?  Being able to use [up] and
[down] would be both convenient and intuitive (particularly people who use packages
like company-mode), but cannot see that completing-read could allow that.

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: uzibalqa <uzibalqa <at> proton.me>
Cc: michael_heerdegen <at> web.de, 57163 <at> debbugs.gnu.org
Subject: Re: bug#57163: completing-read not allow cycling of the options by
 default
Date: Sat, 13 Aug 2022 21:20:33 +0300

> Date: Sat, 13 Aug 2022 18:15:26 +0000
> From: uzibalqa <uzibalqa <at> proton.me>
> Cc: michael_heerdegen <at> web.de, 57163 <at> debbugs.gnu.org
> 
> > > Debugger entered--Lisp error: (user-error "End of defaults; no next item")
> > > signal(user-error ("End of defaults; no next item"))
> > > user-error("End of defaults; no next item")
> >
> >
> > Well, don't set debug-on-error, then.
> >
> > > After that, doing M-p gives [M-p is undefined]
> >
> >
> > Because you are in the debugger, in recursive-edit. Type C-] to exit
> > that.
> 
> Should it be a user-error though?

A low-level API such as completing-read has no business in deciding
which errors are user-errors and which aren't.  That's for the calling
application to decide.

>  there any scheme to set another keybinding
> for `M-n` and `M-p` for things like completing-read?  Being able to use [up] and
> [down] would be both convenient and intuitive (particularly people who use packages
> like company-mode), but cannot see that completing-read could allow that.

<UP> and <DOWN> arrow keys work here, they do the same as M-p and M-n.

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

From: uzibalqa <uzibalqa <at> proton.me>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: michael_heerdegen <at> web.de, 57163 <at> debbugs.gnu.org
Subject: Re: bug#57163: completing-read not allow cycling of the options by
 default
Date: Sat, 13 Aug 2022 18:28:52 +0000

------- Original Message -------
On Saturday, August 13th, 2022 at 6:20 PM, Eli Zaretskii <eliz <at> gnu.org> wrote:


> > Date: Sat, 13 Aug 2022 18:15:26 +0000
> > From: uzibalqa uzibalqa <at> proton.me
> > Cc: michael_heerdegen <at> web.de, 57163 <at> debbugs.gnu.org
> >
> > > > Debugger entered--Lisp error: (user-error "End of defaults; no next item")
> > > > signal(user-error ("End of defaults; no next item"))
> > > > user-error("End of defaults; no next item")
> > >
> > > Well, don't set debug-on-error, then.
> > >
> > > > After that, doing M-p gives [M-p is undefined]
> > >
> > > Because you are in the debugger, in recursive-edit. Type C-] to exit
> > > that.
> >
> > Should it be a user-error though?
>
>
> A low-level API such as completing-read has no business in deciding
> which errors are user-errors and which aren't. That's for the calling
> application to decide.
>
> > there any scheme to set another keybinding
> > for `M-n` and `M-p` for things like completing-read? Being able to use [up] and
> > [down] would be both convenient and intuitive (particularly people who use packages
> > like company-mode), but cannot see that completing-read could allow that.
>
>
> <UP> and <DOWN> arrow keys work here, they do the same as M-p and M-n.
>

Cannot see <UP> and <DOWN> arrow keys described in "8.1 Using the Minibuffer" or after that.

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: uzibalqa <uzibalqa <at> proton.me>
Cc: michael_heerdegen <at> web.de, 57163 <at> debbugs.gnu.org
Subject: Re: bug#57163: completing-read not allow cycling of the options by
 default
Date: Sat, 13 Aug 2022 21:46:01 +0300

> Date: Sat, 13 Aug 2022 18:28:52 +0000
> From: uzibalqa <uzibalqa <at> proton.me>
> Cc: michael_heerdegen <at> web.de, 57163 <at> debbugs.gnu.org
> 
> > <UP> and <DOWN> arrow keys work here, they do the same as M-p and M-n.
> >
> 
> Cannot see <UP> and <DOWN> arrow keys described in "8.1 Using the Minibuffer" or after that.

Wrong place.  Look in "Minibuffer History".

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

From: uzibalqa <uzibalqa <at> proton.me>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: michael_heerdegen <at> web.de, 57163 <at> debbugs.gnu.org
Subject: Re: bug#57163: completing-read not allow cycling of the options by
 default
Date: Sat, 13 Aug 2022 19:31:39 +0000

------- Original Message -------
On Saturday, August 13th, 2022 at 6:46 PM, Eli Zaretskii <eliz <at> gnu.org> wrote:


> > Date: Sat, 13 Aug 2022 18:28:52 +0000
> > From: uzibalqa uzibalqa <at> proton.me
> > Cc: michael_heerdegen <at> web.de, 57163 <at> debbugs.gnu.org
> >
> > > <UP> and <DOWN> arrow keys work here, they do the same as M-p and M-n.
> >
> > Cannot see <UP> and <DOWN> arrow keys described in "8.1 Using the Minibuffer" or after that.
>
>
> Wrong place. Look in "Minibuffer History".

I have a problem with that, because I cannot see how someone reading "Minibuffer History"
would associate those commands with moving through the options when using the minibuffer.

For many users, information listing the key-associated commands that can be employed when using
the minibuffer, is more useful in the part "8.1 Using the Minibuffer", rather than finding it much
much later and within the context of minibuffer history.

Message #48 received at 57163-done <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: uzibalqa <uzibalqa <at> proton.me>
Cc: michael_heerdegen <at> web.de, 57163-done <at> debbugs.gnu.org
Subject: Re: bug#57163: completing-read not allow cycling of the options by
 default
Date: Sun, 14 Aug 2022 08:55:48 +0300

> Date: Sat, 13 Aug 2022 19:31:39 +0000
> From: uzibalqa <uzibalqa <at> proton.me>
> Cc: michael_heerdegen <at> web.de, 57163 <at> debbugs.gnu.org
> 
> > > Cannot see <UP> and <DOWN> arrow keys described in "8.1 Using the Minibuffer" or after that.
> >
> >
> > Wrong place. Look in "Minibuffer History".
> 
> I have a problem with that, because I cannot see how someone reading "Minibuffer History"
> would associate those commands with moving through the options when using the minibuffer.
> 
> For many users, information listing the key-associated commands that can be employed when using
> the minibuffer, is more useful in the part "8.1 Using the Minibuffer", rather than finding it much
> much later and within the context of minibuffer history.

Well, you are supposed to read the entire chapter, not just one
section.  Reading a single section is for those who know what they are
after, and get to the section via the index entries.

Anyway, I've now added an explicit reference to completion to the text
in "Minibuffer History", and also added an index entry about
walking through completion candidates, leading there.

And with that, I'm closing this bug report.

Message #51 received at 57163-done <at> debbugs.gnu.org (full text, mbox):

From: uzibalqa <uzibalqa <at> proton.me>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: michael_heerdegen <at> web.de, 57163-done <at> debbugs.gnu.org
Subject: Re: bug#57163: completing-read not allow cycling of the options by
 default
Date: Sun, 14 Aug 2022 16:14:40 +0000

------- Original Message -------
On Sunday, August 14th, 2022 at 5:55 AM, Eli Zaretskii <eliz <at> gnu.org> wrote:


> > Date: Sat, 13 Aug 2022 19:31:39 +0000
> > From: uzibalqa uzibalqa <at> proton.me
> > Cc: michael_heerdegen <at> web.de, 57163 <at> debbugs.gnu.org
> >
> > > > Cannot see <UP> and <DOWN> arrow keys described in "8.1 Using the Minibuffer" or after that.
> > >
> > > Wrong place. Look in "Minibuffer History".
> >
> > I have a problem with that, because I cannot see how someone reading "Minibuffer History"
> > would associate those commands with moving through the options when using the minibuffer.
> >
> > For many users, information listing the key-associated commands that can be employed when using
> > the minibuffer, is more useful in the part "8.1 Using the Minibuffer", rather than finding it much
> > much later and within the context of minibuffer history.
>
>
> Well, you are supposed to read the entire chapter, not just one
> section. Reading a single section is for those who know what they are
> after, and get to the section via the index entries.

Expecting the reading of entire chapters, and then having to associate
commands under different headings to different functionalities is a failing
strategy.

> Anyway, I've now added an explicit reference to completion to the text
> in "Minibuffer History", and also added an index entry about
> walking through completion candidates, leading there.

> And with that, I'm closing this bug report.
>

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: uzibalqa <uzibalqa <at> proton.me>
Cc: michael_heerdegen <at> web.de, 57163 <at> debbugs.gnu.org
Subject: Re: bug#57163: completing-read not allow cycling of the options by
 default
Date: Sun, 14 Aug 2022 19:18:23 +0300

> Date: Sun, 14 Aug 2022 16:14:40 +0000
> From: uzibalqa <uzibalqa <at> proton.me>
> Cc: michael_heerdegen <at> web.de, 57163-done <at> debbugs.gnu.org
> 
> > Well, you are supposed to read the entire chapter, not just one
> > section. Reading a single section is for those who know what they are
> > after, and get to the section via the index entries.
> 
> Expecting the reading of entire chapters, and then having to associate
> commands under different headings to different functionalities is a failing
> strategy.

That's the recommended practice of learning about this subject when
you are not familiar with it (as you seem to be).  Reading single
sections in this situation is not a very effective way of learning
about this.

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

From: uzibalqa <uzibalqa <at> proton.me>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: michael_heerdegen <at> web.de, 57163 <at> debbugs.gnu.org
Subject: Re: bug#57163: completing-read not allow cycling of the options by
 default
Date: Sun, 14 Aug 2022 16:34:42 +0000

Sent with Proton Mail secure email.

------- Original Message -------
On Sunday, August 14th, 2022 at 4:18 PM, Eli Zaretskii <eliz <at> gnu.org> wrote:


> > Date: Sun, 14 Aug 2022 16:14:40 +0000
> > From: uzibalqa uzibalqa <at> proton.me
> > Cc: michael_heerdegen <at> web.de, 57163-done <at> debbugs.gnu.org
> >
> > > Well, you are supposed to read the entire chapter, not just one
> > > section. Reading a single section is for those who know what they are
> > > after, and get to the section via the index entries.
> >
> > Expecting the reading of entire chapters, and then having to associate
> > commands under different headings to different functionalities is a failing
> > strategy.
>
>
> That's the recommended practice of learning about this subject when
> you are not familiar with it (as you seem to be). Reading single
> sections in this situation is not a very effective way of learning
> about this.

Completion is defined as a feature that fills in the rest of a name starting from an
abbreviation for it.  Easily leads to confusion because one does not commonly associate
completion with next selection element.

Have looked at "Variable: minibuffer-local-map" which states that it is the default local keymap for reading from the minibuffer. By default, it makes the following bindings:

But that list is not complete because it associates M-n and M-p only with history elements.

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: uzibalqa <uzibalqa <at> proton.me>
Cc: michael_heerdegen <at> web.de, 57163 <at> debbugs.gnu.org
Subject: Re: bug#57163: completing-read not allow cycling of the options by
 default
Date: Sun, 14 Aug 2022 19:51:04 +0300

> Date: Sun, 14 Aug 2022 16:34:42 +0000
> From: uzibalqa <uzibalqa <at> proton.me>
> Cc: michael_heerdegen <at> web.de, 57163 <at> debbugs.gnu.org
> 
> > > Expecting the reading of entire chapters, and then having to associate
> > > commands under different headings to different functionalities is a failing
> > > strategy.
> >
> >
> > That's the recommended practice of learning about this subject when
> > you are not familiar with it (as you seem to be). Reading single
> > sections in this situation is not a very effective way of learning
> > about this.
> 
> Completion is defined as a feature that fills in the rest of a name starting from an
> abbreviation for it.  Easily leads to confusion because one does not commonly associate
> completion with next selection element.
> 
> Have looked at "Variable: minibuffer-local-map" which states that it is the default local keymap for reading from the minibuffer. By default, it makes the following bindings:
> 
> But that list is not complete because it associates M-n and M-p only with history elements.

You are again reading in the wrong place.  Keymaps have nothing to do
with this.

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

From: uzibalqa <uzibalqa <at> proton.me>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: michael_heerdegen <at> web.de, 57163 <at> debbugs.gnu.org
Subject: Re: bug#57163: completing-read not allow cycling of the options by
 default
Date: Sun, 14 Aug 2022 17:11:40 +0000

------- Original Message -------
On Sunday, August 14th, 2022 at 4:51 PM, Eli Zaretskii <eliz <at> gnu.org> wrote:


> > Date: Sun, 14 Aug 2022 16:34:42 +0000
> > From: uzibalqa uzibalqa <at> proton.me
> > Cc: michael_heerdegen <at> web.de, 57163 <at> debbugs.gnu.org
> >
> > > > Expecting the reading of entire chapters, and then having to associate
> > > > commands under different headings to different functionalities is a failing
> > > > strategy.
> > >
> > > That's the recommended practice of learning about this subject when
> > > you are not familiar with it (as you seem to be). Reading single
> > > sections in this situation is not a very effective way of learning
> > > about this.
> >
> > Completion is defined as a feature that fills in the rest of a name starting from an
> > abbreviation for it. Easily leads to confusion because one does not commonly associate
> > completion with next selection element.
> >
> > Have looked at "Variable: minibuffer-local-map" which states that it is the default local keymap for reading from the minibuffer. By default, it makes the following bindings:
> >
> > But that list is not complete because it associates M-n and M-p only with history elements.
>
>
> You are again reading in the wrong place. Keymaps have nothing to do
> with this.

Agreed, because I switched to the Emacs Lisp Manual instead of the Emacs Manual.

A straighforward way is to describe the keybindings immediately in "8.3 Editing in the Minibuffer"
then refer to 8.3 when you get to "8.5 Minibuffer History".  And not the other way round.

Message #66 received at 57163-done <at> debbugs.gnu.org (full text, mbox):

From: Jean Louis <bugs <at> gnu.support>
To: uzibalqa <uzibalqa <at> proton.me>
Cc: michael_heerdegen <at> web.de, Eli Zaretskii <eliz <at> gnu.org>,
 57163-done <at> debbugs.gnu.org
Subject: Re: bug#57163: completing-read not allow cycling of the options by
 default
Date: Tue, 16 Aug 2022 07:48:19 +0300

* uzibalqa via "Bug reports for GNU Emacs, the Swiss army knife of text editors <bug-gnu-emacs <at> gnu.org> [2022-08-14 19:16]:
> Expecting the reading of entire chapters, and then having to
> associate commands under different headings to different
> functionalities is a failing strategy.

Main obstacles in learning are misunderstood words. If there is any
word you do not understand, ask for its meaning or try to find out its
meaning, use dictionary, that way you may understand full sentences
and its meanings.

-- 
Jean

Take action in Free Software Foundation campaigns:
https://www.fsf.org/campaigns

In support of Richard M. Stallman
https://stallmansupport.org/

Message #69 received at 57163-done <at> debbugs.gnu.org (full text, mbox):

From: uzibalqa <uzibalqa <at> proton.me>
To: Jean Louis <bugs <at> gnu.support>
Cc: michael_heerdegen <at> web.de, Eli Zaretskii <eliz <at> gnu.org>,
 57163-done <at> debbugs.gnu.org
Subject: Re: bug#57163: completing-read not allow cycling of the options by
 default
Date: Tue, 16 Aug 2022 05:07:36 +0000

------- Original Message -------
On Tuesday, August 16th, 2022 at 4:48 AM, Jean Louis <bugs <at> gnu.support> wrote:


> * uzibalqa via "Bug reports for GNU Emacs, the Swiss army knife of text editors bug-gnu-emacs <at> gnu.org [2022-08-14 19:16]:
>
> > Expecting the reading of entire chapters, and then having to
> > associate commands under different headings to different
> > functionalities is a failing strategy.
>
>
> Main obstacles in learning are misunderstood words. If there is any
> word you do not understand, ask for its meaning or try to find out its
> meaning, use dictionary, that way you may understand full sentences
> and its meanings.
>
> --
> Jean

Appropriate functionality should be discussed as soon as it becomes relevant, not at much later
stages.  For the Emacs Manual, I cannot see description of what keys are available for use with
the minibuffer, particularly for completing-read, where options are available but there is no
clear way to know what key can move through the options.  Keys for displaying history is quite
different from normal usage where there might not exist previous history.

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

From: Jean Louis <bugs <at> gnu.support>
To: uzibalqa <uzibalqa <at> proton.me>
Cc: michael_heerdegen <at> web.de, Eli Zaretskii <eliz <at> gnu.org>,
 57163 <at> debbugs.gnu.org
Subject: Re: bug#57163: completing-read not allow cycling of the options by
 default
Date: Tue, 16 Aug 2022 08:24:21 +0300

* uzibalqa via "Bug reports for GNU Emacs, the Swiss army knife of text editors <bug-gnu-emacs <at> gnu.org> [2022-08-14 19:36]:
> Completion is defined as a feature that fills in the rest of a name
> starting from an abbreviation for it.  Easily leads to confusion
> because one does not commonly associate completion with next
> selection element.

That is why I said that misunderstood words are one of main obstacles
in learning. We have computer terminology, we have English, then other
languages, and then Emacs terminology, and there may be similar
words. We have to be careful to find the right definition of a word in
a right context.

Recommended place in maniual is:

(info "(elisp) Completion")

21.6 Completion
===============

“Completion” is a feature that fills in the rest of a name starting from
an abbreviation for it.  Completion works by comparing the user’s input
against a list of valid names and determining how much of the name is
determined uniquely by what the user has typed.  For example, when you
type ‘C-x b’ (‘switch-to-buffer’) and then type the first few letters of
the name of the buffer to which you wish to switch, and then type <TAB>
(‘minibuffer-complete’), Emacs extends the name as far as it can.

   Standard Emacs commands offer completion for names of symbols, files,
buffers, and processes; with the functions in this section, you can
implement completion for other kinds of names.

   The ‘try-completion’ function is the basic primitive for completion:
it returns the longest determined completion of a given initial string,
with a given set of strings to match against.

   The function ‘completing-read’ provides a higher-level interface for
completion.  A call to ‘completing-read’ specifies how to determine the
list of valid names.  The function then activates the minibuffer with a
local keymap that binds a few keys to commands useful for completion.
Other functions provide convenient simple interfaces for reading certain
kinds of names with completion.

> Have looked at "Variable: minibuffer-local-map" which states that it
> is the default local keymap for reading from the minibuffer. By
> default, it makes the following bindings:
> 
> But that list is not complete because it associates M-n and M-p only
> with history elements.

That is right. History elements do not represent completion
candidates.

IMPORTANT: history elements may be different than completion
candidates. You may come into situation that by choosing a history
element you are not able to choose the true completion candidate, and
by attempting to choose a history element you may not even be able to
accept the candidate because they may be different.

M-p runs the command previous-history-element (found in
minibuffer-local-must-match-map), which is an interactive
byte-compiled Lisp function in ‘simple.el’.

(previous-history-element N)

Puts previous element of the minibuffer history in the minibuffer.
With argument N, it uses the Nth previous element.

Example from real life:

In my personal work and research I am using Hyperscope as database
backed note taking tool. Each note has its name. 

- my completion candidates are automatically choosen from database,
  there are for example note names, such as "My note 1", "My note 2"

- imagine I am doing completion and choose "My note 1", that one
  remains in history.

- Then maybe I rename "My note 1" to "August 2022 Notes"

- Then again I use completion, but it is using history elements, so
  M-n and M-p will rather show me "My note 1" even though it is not
  one of completion candidates any more.

I also understand that some of suggestions for completion candidates
on the mailing list, maybe on GNU Emacs Help, was to use M-n or M-p
but please remember, those are for history elements.

To make history elements more relevant to your completion candidates
you should use history variables.

When there are many various applications of completions it becomes
boring to always define a new history variable and take care of it.

For that reason I have choosen to generate such variables
automatically based on the prompt. If prompt is unique and relevant,
the history variable will be unique and relevant.

Here is the function that I use to generate history variable automatically:

(defun rcd-symbol-if-not-exist (variable &optional value description)
  "Return symbol for VARIABLE string. 

It will generate new VARIABLE if it does not exist."
  (let* ((variable (replace-regexp-in-string "[^[:alnum:]]" "-" (downcase variable)))
	 (rcd-symbol (intern variable))
	 (description (or description (format "Generated variable `%s'" variable))))
    (if (boundp rcd-symbol)
	rcd-symbol
      (eval (list 'defvar rcd-symbol value description)))))

(rcd-symbol-if-not-exist "Enter name of person: ") ⇒ enter-name-of-person--

Thus history variable becomes `enter-name-of-person--' for the prompt "Enter name of person: ".

Then I have a higher level function that uses `completing-read'
function and automatically generates history variables:

(defun rcd-choose (list &optional prompt predicate initial-input def)
  "Ask user for LIST of choices.
If only one element, function `y-or-n-p' will be used.
For multiple elements `completing-read' is used.

If nothing chosen it will return empty string."
  (let* ((completion-ignore-case t)
	 (prompt (or prompt "Choose: "))
	 (description (format "History for `%s' completion prompt." prompt))
	 (history (rcd-symbol-if-not-exist (concat "rcd-" prompt "-history") nil description))
	 (input (cond ((length= list 1) (if (y-or-n-p (nth 0 list)) (nth 0 list) ""))
		      (t (rcd-repeat-until-not-empty-string 'completing-read prompt list predicate t initial-input history def t)))))
    input))

Then I can simply say:

(rcd-choose '("One" "Two" "Three")) and I am not using any prompt there. It will be automatically "Choose: ". That will generate history variable for the prompt "Choose: " and hold various history elements.

But if I am using a prompt:
(rcd-choose '("One" "Two" "Three") "Choose a number: ")

then such prompt"Choose a number: " will automatically result with history variable generated for
me, and it will hold those specific elements for that specific
prompt.

That is the way how I completely forget about defining history
variables but I still have them for each and everything.

Helper function to repeat a function until it gives non empty string:

(defun rcd-repeat-until-not-empty-string (function &rest args)
  "Repeat FUNCTION with optional ARGS until result is not empty string."
  (let ((result))
    (while (string-empty-p (setq result (apply function args))))
      result))

Back to "completion cycling":

I use TAB to view completion candidates if necessary and then I start
typing one of them.

If I know any string inside of a completion, I may start typing it
with the wildcard:

Choose: *eth and then by pressing TAB I can see those candidates
matchin *eth which comes very handy to choose the right one.

My completion candidates are dynamically changed and there are many,
often there may be 70,000 candidates.

For you I recomend using some add-on packages such as `ivy-mode' as
that one may visually show you completion candidates and instead of
history elements you may use M-n and M-p to cycle through completion
candidates instead through history elements.

My personal work tells me that I everything works faster and more
efficient by using built-in Emacs completion without add-on packages,
as I have extensive numbers of candidates where the wildcard method
works better for me.

-- 
Jean

Take action in Free Software Foundation campaigns:
https://www.fsf.org/campaigns

In support of Richard M. Stallman
https://stallmansupport.org/

Previous Next

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