From: Ergus <spacibba@aol.com>
To: Eli Zaretskii <eliz@gnu.org>
Cc: juri@linkov.net, larsi@gnus.org, emacs-devel@gnu.org
Subject: Re: Select completions from the minibuffer
Date: Tue, 22 Mar 2022 16:21:50 +0100 [thread overview]
Message-ID: <20220322152150.xnghbiufg6fvspio@Ergus> (raw)
In-Reply-To: <831qyuf3e0.fsf@gnu.org>
On Tue, Mar 22, 2022 at 04:49:59PM +0200, Eli Zaretskii wrote:
>> Date: Tue, 22 Mar 2022 15:18:15 +0100
>> From: Ergus <spacibba@aol.com>
>> Cc: Juri Linkov <juri@linkov.net>, larsi@gnus.org, emacs-devel@gnu.org
>>
>> > +@code{t} the completions are hidden when some unique completion is
>> > +executed.
>> >
>> >What do you mean by "unique completion is executed"? Both the
>> >"unique" and the "executed" parts need clarification.
>> >
>> unique means that, there is a single candidate o prefix so the <tab>
>> "added" some letter. example: com<tab>pi<tab> -> compil
>>
>> The first tab shows completions but the second hides it... it is a bit
>> confusing compared to any other completion engine (bash, zsh,
>> fish)... that's why I started this changes...
>
>So we could simply say
>
> when Emacs is able to complete some characters
>
>is that right?
>
I think so,
>> > If @code{completion-auto-help} is set to @code{always}, the
>> > +completion commands are always shown after a completion attempt, or
>> >
>> >"Commands"? didn't you mean "candidates" or "alternatives"? (The same
>> >problem exists in the doc string of this variable, btw.)
>> >
>> Maybe candidates is better,
>
>If it's just "better", then please explain what you mean by
>"commands". The text I quoted above says "the completion commands are
>always shown". What are those "commands" that are shown after a
>completion attempt?
>
We are just in violent agreement here I thing.. I am saying that as you
suggested "candidates" is a better word, more precise.
>> > If the value is @code{visible}, Emacs displays completion the
>> > completion alternatives when it is unable to complete for the first
>> > time; thereafter the completion list buffer remains visible and is
>> > updated as you type.
>> >
>> >Is this accurate and correct?
>> >
>> "and is updated as you type."
>>
>> I am not sure that last part is accurate. updates need <tab> to update
>> in all cases. "as you type" suggests more an icomplete-like behavior I
>> thinks.
>
>Ok, so "the completion list buffer remains visible for all the
>subsequent completion attempts". Better?
>
yes,
>> > +current completion candidate will be highlighted with that face. The
>> > +default value is @code{completions-highlight}. When the value is
>> > +@code{nil}, no highlighting is performed. This feature sets the text
>> > +property @code{cursor-face}.
>> >
>> >This should explain what is "the current completion candidate". It
>> >isn't trivial: trying the current defaults with completion commands, I
>> >sometimes see a candidate highlighted, and sometimes don't. I
>> >couldn't figure out why.
>> >
>>
>> when it is not highlighting? So far the only way to not have a candidate
>> highlighted is when there is not candidate effectively selected (like
>> when completions are just updated (with no completion-auto-select) and
>> the cursor is before the help line; I that case there is not "current
>> candidate"); a return in that moment won't execute anything because
>> there is nothing to select, so "current completion candidate" means
>> that... Maybe you have a better way to explain it?
>
>Wouldn't it make sense to move point to the first candidate, so that
>some candidate is always highlighted?
>
That may change the current behavior in a more intrusive way and I
didn't want to affect current behavior.
What you suggest is something I already considered:
completion-auto-select t makes 3 things I think should have been spitted
into 2:
1) it selects *Completions*
2) Select completions window
3) Go to the first candidate.
These options may be probably independent because the user may want to:
1) show completion and highlight (or put cursor) in the first candidate
but without selecting the *Completions* Window
2) Select completions window without putting cursor in the first
candidate.
I thought on this because in zsh the usual approach for this is:
First tab: attempts to complete common and shows completions
Second tab: go to completions and select first candidate.
Following tabs: move to next candidate
Right now the combination to get this behavior is not possible, but at
least we are closer than before and we give a more familiar interaction
with more options...
>Btw, when a candidate is highlighted, it is always the first one in
>the list, which kinda makes me wonder why this highlighting is useful,
>if it always shows the candidate in a fixed location on display?
>
I don't understand what you mean... The highlight is just the same that
used to happen before when the point selected a candidate, then arrow
navigation selects a candidate... We just added a more visible hint; not
just the pointer...
>> Please if you have the time change it... Otherwise I will do in some
>> days.
>
>Will do.
next prev parent reply other threads:[~2022-03-22 15:21 UTC|newest]
Thread overview: 92+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-03-10 18:58 Select completions from the minibuffer Juri Linkov
2022-03-10 19:32 ` Lars Ingebrigtsen
2022-03-10 19:51 ` Juri Linkov
2022-03-10 20:32 ` Lars Ingebrigtsen
2022-03-11 8:58 ` Juri Linkov
2022-03-12 17:08 ` Lars Ingebrigtsen
2022-03-12 18:55 ` Juri Linkov
2022-03-13 14:05 ` Lars Ingebrigtsen
2022-03-13 18:05 ` Juri Linkov
2022-03-14 9:13 ` Lars Ingebrigtsen
2022-03-21 19:28 ` Juri Linkov
2022-03-21 19:30 ` Lars Ingebrigtsen
2022-03-22 8:24 ` Juri Linkov
2022-03-22 13:38 ` Eli Zaretskii
2022-03-22 13:44 ` Eric S Fraga
2022-03-22 14:18 ` Ergus
2022-03-22 14:49 ` Eli Zaretskii
2022-03-22 15:21 ` Ergus [this message]
2022-03-22 18:38 ` Juri Linkov
2022-03-22 19:07 ` Ergus
2022-03-22 19:24 ` Ergus
2022-03-23 8:47 ` Juri Linkov
2022-03-23 12:07 ` Ergus
2022-03-23 18:28 ` Juri Linkov
2022-03-24 9:07 ` Ergus
2022-03-22 15:46 ` Ergus
2022-03-22 16:59 ` Eli Zaretskii
2022-03-22 17:10 ` Ergus
2022-03-22 17:58 ` Eli Zaretskii
2022-03-22 17:56 ` Juri Linkov
2022-03-22 17:23 ` Ergus
2022-03-22 17:52 ` Juri Linkov
2022-03-22 18:31 ` Juri Linkov
2022-03-14 8:41 ` Juri Linkov
2022-03-14 9:08 ` Ergus
2022-03-14 18:19 ` Juri Linkov
2022-03-14 19:46 ` Ergus
2022-03-14 20:58 ` Stefan Monnier
2022-03-14 22:28 ` Ergus
2022-03-14 22:34 ` Stefan Monnier
2022-03-15 15:22 ` Stefan Monnier
2022-03-14 19:34 ` Juri Linkov
2022-03-17 18:01 ` Ergus
2022-03-17 18:47 ` Ergus
2022-03-17 20:56 ` Juri Linkov
2022-03-17 21:26 ` Stefan Monnier
2022-03-17 21:33 ` Ergus
2022-03-17 22:44 ` Stefan Monnier
2022-03-17 22:44 ` Ergus
2022-03-18 6:25 ` Eli Zaretskii
2022-03-17 23:10 ` Ergus
2022-03-18 6:28 ` Eli Zaretskii
2022-03-18 11:16 ` Ergus
2022-03-18 11:33 ` Eli Zaretskii
2022-03-18 12:04 ` Stefan Monnier
2022-03-18 12:11 ` Eli Zaretskii
2022-03-18 12:23 ` Ergus
2022-03-18 12:35 ` Stefan Monnier
2022-03-18 12:38 ` Ergus
2022-03-18 12:57 ` Eli Zaretskii
2022-03-18 9:27 ` Juri Linkov
2022-03-18 11:26 ` Eli Zaretskii
2022-03-18 11:53 ` Ergus
2022-03-18 12:06 ` Eli Zaretskii
2022-03-18 21:31 ` Ergus
2022-03-19 19:03 ` Juri Linkov
2022-03-19 20:43 ` Ergus
2022-03-19 20:46 ` Ergus
2022-03-20 18:42 ` Juri Linkov
2022-03-20 22:00 ` Ergus
2022-03-21 8:32 ` Juri Linkov
2022-03-18 12:08 ` Stefan Monnier
2022-03-18 12:13 ` Eli Zaretskii
2022-03-12 0:14 ` Ergus
2022-03-12 17:04 ` Lars Ingebrigtsen
2022-03-12 17:29 ` Eli Zaretskii
2022-03-12 17:37 ` Ergus
2022-03-12 18:14 ` Eli Zaretskii
2022-03-12 19:30 ` Ergus
2022-03-12 19:39 ` Eli Zaretskii
2022-03-13 18:55 ` Ergus
2022-03-13 17:47 ` Juri Linkov
2022-03-13 18:52 ` Ergus
2022-03-12 19:11 ` [External] : " Drew Adams
2022-03-10 19:55 ` Drew Adams
2022-03-10 19:59 ` Juri Linkov
2022-03-10 23:13 ` Drew Adams
2022-03-10 19:58 ` Eli Zaretskii
2022-03-10 20:23 ` Lars Ingebrigtsen
2022-03-10 20:38 ` Eli Zaretskii
2022-03-12 18:52 ` Juri Linkov
2022-03-12 19:16 ` Eli Zaretskii
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
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20220322152150.xnghbiufg6fvspio@Ergus \
--to=spacibba@aol.com \
--cc=eliz@gnu.org \
--cc=emacs-devel@gnu.org \
--cc=juri@linkov.net \
--cc=larsi@gnus.org \
/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 external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.