Re: master 15ac51e0fd: Merge branch 'feature/completions-customs'

Re: master 15ac51e0fd: Merge branch 'feature/completions-customs'

[Po Lu]

Juri Linkov <juri@jurta.org> writes:

> +(defcustom completions-header-format
> +  (propertize "%s possible completions:\n"
> +              'face 'shadow
> +              :help "Please select a completion")
> +  "Format of completions header.
> +It may contain one %s to show the total count of completions.
> +When nil, no header is shown."
> +  :type '(choice (const :tag "No header" nil)
> +                 (string :tag "Header format string"))
> +  :version "29.1")

IHMO this should be off by default.  It wastes a line of space in the
completions buffer for no real gain, and it's distracting.

Also, I don't know which part of this change causes the following
behavior, but if I say M-x and then press TAB twice, the item at the
start of the window displaying the completions buffer becomes
highlighted, even though it isn't selected.  That should also be off by
default, since it's an unnecessary visual distraction.

Thanks.

Re: master 15ac51e0fd: Merge branch 'feature/completions-customs'

[Lars Ingebrigtsen]

Po Lu <luangruo@yahoo.com> writes:

> IHMO this should be off by default.  It wastes a line of space in the
> completions buffer for no real gain, and it's distracting.

It used to be:

----
Click on a completion to select it.
In this buffer, type RET to select the completion near point.

Possible completions are:
----

And now it's:

----
Click on a completion to select it.
In this buffer, type RET to select the completion near point.

134 possible completions:
----

So it doesn't waste any space, and it provides more information.

I'd rather do something about the first three lines, though.  Either
remove them completely (it's pretty self-evident that that's what you do
in that buffer, and especially now that you get mouse/point highlights,
indicating that things are "buttons").

Perhaps it might make sense to remove all four lines, and put the number
of completions in the mode line instead.

> Also, I don't know which part of this change causes the following
> behavior, but if I say M-x and then press TAB twice, the item at the
> start of the window displaying the completions buffer becomes
> highlighted, even though it isn't selected.  That should also be off by
> default, since it's an unnecessary visual distraction.

Yes, that's somewhat confusing.  Would it be possible to not activate
the point highlight before the user has selected the completions window
(one way or another)?

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

RE: [External] : Re: master 15ac51e0fd: Merge branch 'feature/completions-customs'

[Drew Adams]

> put the number of completions in the mode line instead.

Yes, I suggested that.  And explained what other
completion status it can also be useful to show
there (in the mode-line).  And pointed to doc
with screenshots about this, as food for thought.
(No response, no reply about this, sad to say.)

> Yes, that's somewhat confusing.  Would it be possible to not activate
> the point highlight before the user has selected the completions window
> (one way or another)?

FWIW:

In Icicles, highlighting of the current candidate
goes along with changing the current candidate
(duh).  IOW, it happens when you cycle from one
candidate to another.  (There are also other ways
to change the current candidate.)

When no candidate is current, none is highlighted.

When a candidate becomes current it's at the same
time placed in the minibuffer, so hitting RET etc.
chooses it.

You don't need to switch focus to *Completions*
to cycle.  But you can do so.  Users never really
need to select window *Completions*, and they
seldom do so.  But a few actions can be easier to
carry out there.  You typically do everything in
the minibuffer: edit, complete, cycle, choose,...

`TAB' and some other keys cycle among candidates.
`TAB' also initiates completion.  The second `TAB'
in a row starts cycling - to the first candidate,
then the second, etc. in the current sort order.

You don't need to use `TAB' to cycle.  You can
instead use keys such as `down', in which case
there's no need for the key to do double duty,
so no need to hit it twice to start cycling.

(It's also possible to not show any candidates in
*Completions*, i.e., to just cycle them into the
minibuffer.  That behavior's used less often, but
it's available at any time.)

Re: master 15ac51e0fd: Merge branch 'feature/completions-customs'

[Po Lu]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> Po Lu <luangruo@yahoo.com> writes:
>
>> IHMO this should be off by default.  It wastes a line of space in the
>> completions buffer for no real gain, and it's distracting.
>
> It used to be:
>
> ----
> Click on a completion to select it.
> In this buffer, type RET to select the completion near point.
>
> Possible completions are:
> ----
>
> And now it's:
>
> ----
> Click on a completion to select it.
> In this buffer, type RET to select the completion near point.
>
> 134 possible completions:
> ----
>
> So it doesn't waste any space, and it provides more information.

Hmm.  It's odd how I never noticed the first.

> I'd rather do something about the first three lines, though.  Either
> remove them completely (it's pretty self-evident that that's what you
> do in that buffer, and especially now that you get mouse/point
> highlights, indicating that things are "buttons").  Perhaps it might
> make sense to remove all four lines,

I don't think that highlighting the item at point makes it clear that
pressing RET will select the completion in question.

But the first line could be removed and replaced by a tooltip on the
individual completion items.

> and put the number of completions in the mode line instead.

Yes, the best place to put it would probably be the completion list
lighter on the mode line.

Thanks.

Re: master 15ac51e0fd: Merge branch 'feature/completions-customs'

[Ergus]

On Tue, Mar 22, 2022 at 05:28:59PM +0800, Po Lu wrote:
>Juri Linkov <juri@jurta.org> writes:
>
>> +(defcustom completions-header-format
>> +  (propertize "%s possible completions:\n"
>> +              'face 'shadow
>> +              :help "Please select a completion")
>> +  "Format of completions header.
>> +It may contain one %s to show the total count of completions.
>> +When nil, no header is shown."
>> +  :type '(choice (const :tag "No header" nil)
>> +                 (string :tag "Header format string"))
>> +  :version "29.1")
>
>IHMO this should be off by default.  It wastes a line of space in the
>completions buffer for no real gain, and it's distracting.
>
The header was already there so no new space
wasted... completion-show-help is nil in my system... I didn't add it to
the modeline to make it simpler...

BUT: we could add a completions-header-format special value 'modeline
and then show there the count of completions... I am not interested at
all because in my system y hide the mode-line for completions....

>Also, I don't know which part of this change causes the following
>behavior, but if I say M-x and then press TAB twice, the item at the
>start of the window displaying the completions buffer becomes
>highlighted, even though it isn't selected.  That should also be off by
>default, since it's an unnecessary visual distraction.
>

Ok I think I know... I haven't observed this before...

The completions-highlight-mode relies on the new cursor-face that shows
the highlight when the cursor is over the text...

It seems that when M-x <tab> <tab> 

according to completion--in-region-1 the second <tab> scrolls the
Completions buffer, so the cursor goes to the start of the screen after
the scroll, as there is a candidate, that's why you see it
highlighted...

I suggest two solutions here:

1) Not enable cursor-face-highlight-nonselected-window for
completions... this will disable the highlight whenever the Completions
window is not the active one...

2) Extend the highlight to consider cursor-in-non-selected-windows and
set it to nil in Completions by default...

The first is the simples one, but will fore the Juri's code to
setq-local the variable in a hook or in his function wrapper...

So just tell what do you prefer...


>Thanks.
>

Re: master 15ac51e0fd: Merge branch 'feature/completions-customs'

[Po Lu]

Ergus <spacibba@aol.com> writes:

> I suggest two solutions here:
>
> 1) Not enable cursor-face-highlight-nonselected-window for
> completions... this will disable the highlight whenever the Completions
> window is not the active one...
>
> 2) Extend the highlight to consider cursor-in-non-selected-windows and
> set it to nil in Completions by default...
>
> The first is the simples one, but will fore the Juri's code to
> setq-local the variable in a hook or in his function wrapper...
>
> So just tell what do you prefer...

I'm not sure what you mean by hook or Juri's function wrapper, so I
can't say.

Thanks.