From: Eli Zaretskii <eliz@gnu.org>
To: Juri Linkov <juri@linkov.net>
Cc: 59486@debbugs.gnu.org
Subject: bug#59486: completion-auto-wrap disobeyed by vertical navigation
Date: Thu, 02 Nov 2023 10:11:31 +0200 [thread overview]
Message-ID: <83a5rw8tho.fsf@gnu.org> (raw)
In-Reply-To: <86a5rxwf9v.fsf@mail.linkov.net> (message from Juri Linkov on Wed, 01 Nov 2023 19:45:50 +0200)
> From: Juri Linkov <juri@linkov.net>
> Date: Wed, 01 Nov 2023 19:45:50 +0200
>
> Now here is a patch that implements the long-discussed feature of
> using arrow keys for navigating completions from the minibuffer
> only when the *Completions* buffer is visible.
>
> It's disabled by default and can be enabled by the option
> 'minibuffer-completion-visible'. It works nicely for
> the in-buffer completions as well:
Thanks. I have a few comments.
> +(defcustom minibuffer-completion-visible t
> + "Non-nil means to navigate completions with arrows from the minibuffer.
> +This has effect only when the window with the *Completions* buffer
> +is visible on the screen."
This doc string needs to be improved, as it currently doesn't explain
its effect in enough detail, IMO. Maybe because "non-nil means to
navigate" is awkward/confusing English.
Regarding the last sentence of the doc string: does it mean that if
the *Completions* buffer is not in any window, the arrow keys in the
minibuffer will not move point in that buffer? If so, why this
strange design?
> +(defun minibuffer-bind-visible (binding)
> + `(menu-item
> + "" ,binding
> + :filter ,(lambda (cmd)
> + (when (get-buffer-window "*Completions*" 0)
> + cmd))))
This function needs a doc string and possibly a better name, to match
what it actually does.
The argument zero to get-buffer-window AFAIU means that it will return
non-nil when the buffer is shown in some window on an iconified frame,
and I wonder why we would consider such a buffer "visible".
> + "RET" (minibuffer-bind-visible #'minibuffer-choose-completion)
AFAICT, this important binding is not mentioned or hinted in the doc
string of the new option.
> -(defun minibuffer-next-completion (&optional n)
> +(defun minibuffer-next-completion (&optional n vertical)
> "Move to the next item in its completions window from the minibuffer.
> +When the optional argument VERTICAL is non-nil, move vertically.
The "move vertically" part contradicts the "to the next item" part,
doesn't it? Thus, I think the added sentence should be more detailed,
and should explicitly say that the result will be a move to the next
line, not the next item (and perhaps also include a link to
next-line-completion).
> +(defun minibuffer-next-line-completion (&optional n)
> + "Move to the next completion line from the minibuffer.
This sentence is misleading, IMO. Assuming I understood what you
mean, I would rephrase:
Move to the completion candidate on the next line in the completions buffer.
> +When `minibuffer-completion-auto-choose' is non-nil, then also
> +insert the selected completion to the minibuffer."
Please make a habit of talking about "completion candidate" in these
cases, not about "completion". The latter is ambiguous, since it can
refer both to a candidate and to the action of performing completion.
> +(defun minibuffer-previous-line-completion (&optional n)
> + "Move to the previous completion line from the minibuffer.
> +When `minibuffer-completion-auto-choose' is non-nil, then also
> +insert the selected completion to the minibuffer."
Same here.
next prev parent reply other threads:[~2023-11-02 8:11 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-11-22 17:38 bug#59486: completion-auto-wrap disobeyed by vertical navigation Juri Linkov
2022-11-23 18:49 ` Juri Linkov
2022-11-24 7:59 ` Juri Linkov
2022-11-24 8:13 ` Eli Zaretskii
2022-11-24 18:30 ` Juri Linkov
2022-11-24 18:43 ` Eli Zaretskii
2022-11-25 7:47 ` Juri Linkov
2022-11-25 8:38 ` Eli Zaretskii
2022-11-28 7:56 ` Juri Linkov
2023-10-31 7:44 ` Juri Linkov
2023-11-01 17:45 ` Juri Linkov
2023-11-02 8:11 ` Eli Zaretskii [this message]
2023-11-02 17:14 ` Juri Linkov
2023-11-05 17:53 ` Juri Linkov
2023-11-15 17:45 ` Juri Linkov
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=83a5rw8tho.fsf@gnu.org \
--to=eliz@gnu.org \
--cc=59486@debbugs.gnu.org \
--cc=juri@linkov.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).