Question about completion behavior

Question about completion behavior

[Ergus]

Hi:

I am wondering if this behavior is totally intended and consistent.

emacs -Q
M-x c<tab>: shows-completions
o<tab>:     updates-completions
mp<tab>:    updates-completions
i<tab>:     inserts l and hides completions??

I would expect that in this case the last tab inserts l and update
completions as well. And have the current behavior (hide completions)
only when completion-auto-help == 'lazy or when the completion is exact
and unique.

In the code that hides the completions there is actually a comment about
this:

;; We could also decide to refresh the completions,
;; if they're displayed (and assuming there are
;; completions left).

Is anyone working on this?

Was all this behavior intended or how do you propose to solve this?

Re: Question about completion behavior

[Stefan Monnier]

Ergus [2022-03-09 01:10:13] wrote:
> In the code that hides the completions there is actually a comment about
> this:
>
> ;; We could also decide to refresh the completions,
> ;; if they're displayed (and assuming there are
> ;; completions left).
>
> Is anyone working on this?

When I wrote that code (and that comment), my main goal was to rewrite
the C code into ELisp, introduce the `completion-styles` system and add
`partial-completion` to the default.

To maximize the chances that it be accepted, I made every effort to try
and preserve the old behavior w.r.t everything else.

> Was all this behavior intended or how do you propose to solve this?

I think this can be changed.
Patches welcome.


        Stefan

Re: Question about completion behavior

[Ergus]

On Tue, Mar 08, 2022 at 07:22:11PM -0500, Stefan Monnier wrote:
>Ergus [2022-03-09 01:10:13] wrote:
>> In the code that hides the completions there is actually a comment about
>> this:
>>
>> ;; We could also decide to refresh the completions,
>> ;; if they're displayed (and assuming there are
>> ;; completions left).
>>
>> Is anyone working on this?
>
>When I wrote that code (and that comment), my main goal was to rewrite
>the C code into ELisp, introduce the `completion-styles` system and add
>`partial-completion` to the default.
>
>To maximize the chances that it be accepted, I made every effort to try
>and preserve the old behavior w.r.t everything else.
>
>> Was all this behavior intended or how do you propose to solve this?
>
>I think this can be changed.
>Patches welcome.
>
I am struggling how to preserve the old behavior indeed, because what I
find a bit confusing is actually the default behavior.

We could just add an extra custom to change this detail on demand, but
my initial concert was about the inconsistency itself in the default
behavior. For me it seems like the hide-completions may be inside the
if.

Something like:

```
(completed
        (when exact
          (minibuffer-hide-completions)
          ;; If completion did not put point at end of field,
          ;; it's a sign that completion is not finished.
          (completion--done completion
                            (if (< comp-pos (length completion))
                                'exact 'unknown))
          ))
```

gives a consistent behavior IMO.

But as I know that changing a behavior may be impossible maybe we need
another custom with something like:


```
(completed
        (when (or exact the-new-custom)
             (minibuffer-hide-completions))
        (when exact
            ;; If completion did not put point at end of field,
            ;; it's a sign that completion is not finished.
          (completion--done completion
                            (if (< comp-pos (length completion))
                                'exact 'unknown))))
```

Do think that you any of those may be valid? Some side effect I am not
aware of?


>
>        Stefan
>
Thanks,
Ergus

Re: Question about completion behavior

[Stefan Monnier]

>>> Was all this behavior intended or how do you propose to solve this?
>>I think this can be changed.
>>Patches welcome.
> I am struggling how to preserve the old behavior indeed, because what I
> find a bit confusing is actually the default behavior.

I think we should first consider *not* preserving the behavior.
I.e. as suggested by the comment, rather than hide the completions, we
should update them (if they're displayed).


        Stefan

Re: Question about completion behavior

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: emacs-devel@gnu.org
> Date: Tue, 08 Mar 2022 22:05:52 -0500
> 
> >>> Was all this behavior intended or how do you propose to solve this?
> >>I think this can be changed.
> >>Patches welcome.
> > I am struggling how to preserve the old behavior indeed, because what I
> > find a bit confusing is actually the default behavior.
> 
> I think we should first consider *not* preserving the behavior.
> I.e. as suggested by the comment, rather than hide the completions, we
> should update them (if they're displayed).

But please don't keep updating the completions buffer if TAB arrives
at a complete (but not necessarily unique) candidate.  That would be
an annoyance.

Re: Question about completion behavior

[Ergus]

On Wed, Mar 09, 2022 at 05:37:37AM +0200, Eli Zaretskii wrote:
>> From: Stefan Monnier <monnier@iro.umontreal.ca>
>> Cc: emacs-devel@gnu.org
>> Date: Tue, 08 Mar 2022 22:05:52 -0500
>>
>> >>> Was all this behavior intended or how do you propose to solve this?
>> >>I think this can be changed.
>> >>Patches welcome.
>> > I am struggling how to preserve the old behavior indeed, because what I
>> > find a bit confusing is actually the default behavior.
>>
>> I think we should first consider *not* preserving the behavior.
>> I.e. as suggested by the comment, rather than hide the completions, we
>> should update them (if they're displayed).
>
>But please don't keep updating the completions buffer if TAB arrives
>at a complete (but not necessarily unique) candidate.  That would be
>an annoyance.
>

Hi Eli:

Thanks for replying. What do you mean by "at a complete"? 

there are several conditions to handle:

These are the current more or less the conditions we have now:

1. no unique        (shows or update completions)
2. unique common    (complete-common and hides completion)
3. unique candidate (complete and hides completion)
4. unique common but completion is a valid entry (complete-common and hides completion)

Is the 4 to what you refer?

For example when we have:

magit
magit-commit
magit-push
....

and we do: magi<tab>

the completion goes up to magit (adds the t) but it is a valid
candidate.

What I propose is:

1. no unique        (shows or update completions)
2. unique common    (complete-common and UPDATE completions)
3. unique candidate (complete and hides completion)
4. unique common but completion is a valid entry (complete-common and hides completion)

Is this behavior fine??

Best,
Ergus

Re: Question about completion behavior

[Ergus]

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

Hi again Eli:

Look at the attached patch, it may need some small improve to solve the
case 4. but so far it gives a consistent behavior with any value of
completion-auto-help (and it is actually simpler than the current code)

Alternatively we may add another custom, something like:

completions-on-complete-action which may have 3 possible values:

'always to update
'hide for the current behavior
nil to do nothing (not hide the completions but keep them visible)

WDYT? (personally I prefer the simpler... but I know... it's emacs)
Ergus

On Wed, Mar 09, 2022 at 11:11:59AM +0100, Ergus wrote:
>On Wed, Mar 09, 2022 at 05:37:37AM +0200, Eli Zaretskii wrote:
>
>Hi Eli:
>
>Thanks for replying. What do you mean by "at a complete"?
>
>there are several conditions to handle:
>
>These are the current more or less the conditions we have now:
>
>1. no unique        (shows or update completions)
>2. unique common    (complete-common and hides completion)
>3. unique candidate (complete and hides completion)
>4. unique common but completion is a valid entry (complete-common and hides completion)
>
>Is the 4 to what you refer?
>
>For example when we have:
>
>magit
>magit-commit
>magit-push
>....
>
>and we do: magi<tab>
>
>the completion goes up to magit (adds the t) but it is a valid
>candidate.
>
>What I propose is:
>
>1. no unique        (shows or update completions)
>2. unique common    (complete-common and UPDATE completions)
>3. unique candidate (complete and hides completion)
>4. unique common but completion is a valid entry (complete-common and hides completion)
>
>Is this behavior fine??
>
>Best,
>Ergus
>

[-- Attachment #2: completion.patch --]
[-- Type: text/plain, Size: 1973 bytes --]

diff --git a/lisp/minibuffer.el b/lisp/minibuffer.el
index a06986fdb7..fbb72f3d32 100644
--- a/lisp/minibuffer.el
+++ b/lisp/minibuffer.el
@@ -1342,24 +1342,22 @@ completion--do-completion
               (setq completed t exact t)
               (completion--cache-all-sorted-completions beg end comps)
               (minibuffer-force-complete beg end))
-             (completed
-              ;; We could also decide to refresh the completions,
-              ;; if they're displayed (and assuming there are
-              ;; completions left).
-              (minibuffer-hide-completions)
-              (if exact
-                  ;; If completion did not put point at end of field,
-                  ;; it's a sign that completion is not finished.
-                  (completion--done completion
-                                    (if (< comp-pos (length completion))
-                                        'exact 'unknown))))
              ;; Show the completion table, if requested.
              ((not exact)
 	      (if (pcase completion-auto-help
                     ('lazy (eq this-command last-command))
                     (_ completion-auto-help))
                   (minibuffer-completion-help beg end)
+                (minibuffer-hide-completions)
                 (completion--message "Next char not unique")))
+             (completed
+              ;; We could also decide to refresh the completions,
+              ;; if they're displayed (and assuming there are
+              ;; completions left).
+              (minibuffer-hide-completions)
+              (completion--done completion
+                                (if (< comp-pos (length completion))
+                                    'exact 'unknown)))
              ;; If the last exact completion and this one were the same, it
              ;; means we've already given a "Complete, but not unique" message
              ;; and the user's hit TAB again, so now we give him help.

Re: Question about completion behavior

[Eli Zaretskii]

> Date: Wed, 9 Mar 2022 11:11:59 +0100
> From: Ergus <spacibba@aol.com>
> Cc: Stefan Monnier <monnier@iro.umontreal.ca>, emacs-devel@gnu.org
> 
> What I propose is:
> 
> 1. no unique        (shows or update completions)
> 2. unique common    (complete-common and UPDATE completions)
> 3. unique candidate (complete and hides completion)
> 4. unique common but completion is a valid entry (complete-common and hides completion)
> 
> Is this behavior fine??

Sorry, I don't think I understand what you mean by each of the
descriptions "unique common", "unique candidate", etc.  And I don't
want to guess wrongly.  So I cannot answer your question; please
describe each situation as accurately as you can, to make the
discussion effective and useful.

Thanks.

Re: Question about completion behavior

[Eli Zaretskii]

> Date: Wed, 9 Mar 2022 12:46:54 +0100
> From: Ergus <spacibba@aol.com>
> Cc: Stefan Monnier <monnier@iro.umontreal.ca>, emacs-devel@gnu.org
> 
> Look at the attached patch, it may need some small improve to solve the
> case 4. but so far it gives a consistent behavior with any value of
> completion-auto-help (and it is actually simpler than the current code)
> 
> Alternatively we may add another custom, something like:
> 
> completions-on-complete-action which may have 3 possible values:

We don't need a new option, we can add a new value to the
completion-auto-help.

But yes, I think this behavior you propose _must_ be optional, most
probably opt-in for starters.  Not everyone will want it.

See also completion-cycle-threshold: this new behavior should not
tramp that option.

Re: Question about completion behavior

[Po Lu]

Eli Zaretskii <eliz@gnu.org> writes:

> But yes, I think this behavior you propose _must_ be optional, most
> probably opt-in for starters.  Not everyone will want it.

I agree completely.  I'm sure many people have developed a lot of muscle
memory regarding completion, and even tiny changes will probably be a
nusiance to them.

Re: Question about completion behavior

[Ergus]

On Wed, Mar 09, 2022 at 03:10:57PM +0200, Eli Zaretskii wrote:
>> Date: Wed, 9 Mar 2022 11:11:59 +0100
>> From: Ergus <spacibba@aol.com>
>> Cc: Stefan Monnier <monnier@iro.umontreal.ca>, emacs-devel@gnu.org
>>
>> What I propose is:
>>
>> 1. no unique        (shows or update completions)
>> 2. unique common    (complete-common and UPDATE completions)
>> 3. unique candidate (complete and hides completion)
>> 4. unique common but completion is a valid entry (complete-common and hides completion)
>>
>> Is this behavior fine??
>
>Sorry, I don't think I understand what you mean by each of the
>descriptions "unique common", "unique candidate", etc.  And I don't
>want to guess wrongly.  So I cannot answer your question; please
>describe each situation as accurately as you can, to make the
>discussion effective and useful.
>
>Thanks.
>

2. "unique common"

compi<tab> -> compil

And there are other candidates with "compil" prefix (compilation-mode,
compile, etc) but "compil" itself is not a valid one (or exact).

3. "unique candidate"

compilation-mo<tab> -> compilation-mode

And it is the only candidate.

4. "unique common but completion is a valid entry"

magi<tab> -> magit and there are more candidates, but "magit" itself is
already valid (but there is magit-diff, magit-status, etc).

Re: Question about completion behavior

[Ergus]

On Wed, Mar 09, 2022 at 03:16:17PM +0200, Eli Zaretskii wrote:
>> Date: Wed, 9 Mar 2022 12:46:54 +0100
>> From: Ergus <spacibba@aol.com>
>> Cc: Stefan Monnier <monnier@iro.umontreal.ca>, emacs-devel@gnu.org
>>
>> Look at the attached patch, it may need some small improve to solve the
>> case 4. but so far it gives a consistent behavior with any value of
>> completion-auto-help (and it is actually simpler than the current code)
>>
>> Alternatively we may add another custom, something like:
>>
>> completions-on-complete-action which may have 3 possible values:
>
>We don't need a new option, we can add a new value to the
>completion-auto-help.
>
>But yes, I think this behavior you propose _must_ be optional, most
>probably opt-in for starters.  Not everyone will want it.
>
>See also completion-cycle-threshold: this new behavior should not
>tramp that option.

I tend to agree Eli, but actually I started a thread because the default
behavior is indeed inconsistent with completion-auto-help as the same
Stefan mentioned.

The current behavior mixes the completion-auto-help==t with
completion-auto-help=='lazy when there is some completion and the
completions are already visible (hiding them).

If we do:

compi<tab> it should be completed, but if the completions list is
somehow visible, then after the tab it is not correct, so we currently
hide it, when we must just update it right?

The fix in any case is extremely simple and I think that with a new vale
for completion-auto-help to 'always it will work, but may be even
complicated to explain in the documentation...

[PATCH] Question about completion behavior

[Ergus]

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

Please give a look to the attached patch...

It adds two new values:

visible: to update when visible else do nothing (as Stefan suggested).

always: to always update or show completions (Like bash
show-all-if-ambiguous)

BTW: the lazy value is more like show-all-if-unmodified i think


On Wed, Mar 09, 2022 at 03:30:16PM +0100, Ergus wrote:
>On Wed, Mar 09, 2022 at 03:16:17PM +0200, Eli Zaretskii wrote:
>>>Date: Wed, 9 Mar 2022 12:46:54 +0100
>>>From: Ergus <spacibba@aol.com>
>>>Cc: Stefan Monnier <monnier@iro.umontreal.ca>, emacs-devel@gnu.org
>>>
>>>Look at the attached patch, it may need some small improve to solve the
>>>case 4. but so far it gives a consistent behavior with any value of
>>>completion-auto-help (and it is actually simpler than the current code)
>>>
>>>Alternatively we may add another custom, something like:
>>>
>>>completions-on-complete-action which may have 3 possible values:
>>
>>We don't need a new option, we can add a new value to the
>>completion-auto-help.
>>
>>But yes, I think this behavior you propose _must_ be optional, most
>>probably opt-in for starters.  Not everyone will want it.
>>
>>See also completion-cycle-threshold: this new behavior should not
>>tramp that option.
>
>I tend to agree Eli, but actually I started a thread because the default
>behavior is indeed inconsistent with completion-auto-help as the same
>Stefan mentioned.
>
>The current behavior mixes the completion-auto-help==t with
>completion-auto-help=='lazy when there is some completion and the
>completions are already visible (hiding them).
>
>If we do:
>
>compi<tab> it should be completed, but if the completions list is
>somehow visible, then after the tab it is not correct, so we currently
>hide it, when we must just update it right?
>
>The fix in any case is extremely simple and I think that with a new vale
>for completion-auto-help to 'always it will work, but may be even
>complicated to explain in the documentation...
>
>

[-- Attachment #2: completion_custom.patch --]
[-- Type: text/plain, Size: 2238 bytes --]

diff --git a/lisp/minibuffer.el b/lisp/minibuffer.el
index 36b8d80841..c6a803cbc4 100644
--- a/lisp/minibuffer.el
+++ b/lisp/minibuffer.el
@@ -898,7 +898,11 @@ completion-auto-help
 is requested but cannot be done.
 If the value is `lazy', the *Completions* buffer is only displayed after
 the second failed attempt to complete."
-  :type '(choice (const nil) (const t) (const lazy)))
+  :type '(choice (const :tag "Disabled" nil)
+                 (const :tag "Enabled legacy" t)
+                 (const :tag "After a second attempt" lazy)
+                 (const :tag "Visible update" visible)
+                 (const :tag "Always update" always)))
 
 (defvar completion-styles-alist
   '((emacs21
@@ -1343,16 +1347,19 @@ completion--do-completion
               (completion--cache-all-sorted-completions beg end comps)
               (minibuffer-force-complete beg end))
              (completed
-              ;; We could also decide to refresh the completions,
-              ;; if they're displayed (and assuming there are
-              ;; completions left).
-              (minibuffer-hide-completions)
-              (if exact
-                  ;; If completion did not put point at end of field,
-                  ;; it's a sign that completion is not finished.
-                  (completion--done completion
-                                    (if (< comp-pos (length completion))
-                                        'exact 'unknown))))
+              (cond
+               (exact
+                ;; If completion did not put point at end of field,
+                ;; it's a sign that completion is not finished.
+                (minibuffer-hide-completions)
+                (completion--done completion
+                                  (if (< comp-pos (length completion))
+                                      'exact 'unknown)))
+               ((pcase completion-auto-help
+                  ('visible (get-buffer-window "*Completions*" 0))
+                  ('always t))
+                (minibuffer-completion-help beg end))
+               (t (minibuffer-hide-completions))))
              ;; Show the completion table, if requested.
              ((not exact)
 	      (if (pcase completion-auto-help

Re: Question about completion behavior

[Eli Zaretskii]

> Date: Wed, 9 Mar 2022 15:30:16 +0100
> From: Ergus <spacibba@aol.com>
> Cc: monnier@iro.umontreal.ca, emacs-devel@gnu.org
> 
> The current behavior mixes the completion-auto-help==t with
> completion-auto-help=='lazy when there is some completion and the
> completions are already visible (hiding them).
> 
> If we do:
> 
> compi<tab> it should be completed, but if the completions list is
> somehow visible, then after the tab it is not correct, so we currently
> hide it, when we must just update it right?

No.  This is on purpose: with the current behavior, the user can type
a few more characters to fit a single candidate, then hit RET and be
done.

Showing the completions buffer when it is not necessarily needed is a
distraction when you type TAB not to see the candidates, but to have
Emacs type stuff for you.

> The fix in any case is extremely simple and I think that with a new vale
> for completion-auto-help to 'always it will work, but may be even
> complicated to explain in the documentation...

Changes in this area must be optional, because Emacs has behaved like
that for eons.

Re: Question about completion behavior

[Stefan Monnier]

Po Lu [2022-03-09 21:46:06] wrote:
> Eli Zaretskii <eliz@gnu.org> writes:
>> But yes, I think this behavior you propose _must_ be optional, most
>> probably opt-in for starters.  Not everyone will want it.
> I agree completely.  I'm sure many people have developed a lot of muscle
> memory regarding completion, and even tiny changes will probably be a
> nusiance to them.

Then again, it's only by enabling it by default that we'll get a clear
picture of which changes are annoyances are which aren't.

So I'd start by changing the default on `master` and after a month or
so, collect feedback to decide how to go about adding it: either by just
changing the behavior willy-nilly, or introduce it but add an option to
revert to the old behavior, or leave the default unchanged but add an
option to get the new behavior, ...


        Stefan

Re: Question about completion behavior

[Ergus]

On Wed, Mar 09, 2022 at 12:32:14PM -0500, Stefan Monnier wrote:
>Po Lu [2022-03-09 21:46:06] wrote:
>> Eli Zaretskii <eliz@gnu.org> writes:
>>> But yes, I think this behavior you propose _must_ be optional, most
>>> probably opt-in for starters.  Not everyone will want it.
>> I agree completely.  I'm sure many people have developed a lot of muscle
>> memory regarding completion, and even tiny changes will probably be a
>> nusiance to them.

Hi Stefan:

>
>Then again, it's only by enabling it by default that we'll get a clear
>picture of which changes are annoyances are which aren't.
>
I just sent a patch here with new custom values for completion-auto-help
as Eli suggested.


>So I'd start by changing the default on `master` and after a month or
>so, collect feedback to decide how to go about adding it: either by just
>changing the behavior willy-nilly, or introduce it but add an option to
>revert to the old behavior, or leave the default unchanged but add an
>option to get the new behavior, ...
>

I agree with this approach by 110%.  I think it is sensible and we can
try to put the 'visual value as default without excessive complains. As
it is consistent enough but also improves a bit the behavior based on
your initial comment without affecting too much the previous behavior.
>
>        Stefan
>

Re: Question about completion behavior

[Po Lu]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

> Then again, it's only by enabling it by default that we'll get a clear
> picture of which changes are annoyances are which aren't.
>
> So I'd start by changing the default on `master` and after a month or
> so, collect feedback to decide how to go about adding it: either by just
> changing the behavior willy-nilly, or introduce it but add an option to
> revert to the old behavior, or leave the default unchanged but add an
> option to get the new behavior, ...

This really doesn't warrant month-long experiments.  Larger changes like
variable-pitch modelines might, but IMHO this is too small a change.

I would prefer just adding an option to get the new behavior, and asking
people to try that.

Thanks.

Re: Question about completion behavior

[Ergus]

Hi Po:

On Thu, Mar 10, 2022 at 08:42:55AM +0800, Po Lu wrote:
>Stefan Monnier <monnier@iro.umontreal.ca> writes:
>
>> Then again, it's only by enabling it by default that we'll get a clear
>> picture of which changes are annoyances are which aren't.
>>
>> So I'd start by changing the default on `master` and after a month or
>> so, collect feedback to decide how to go about adding it: either by just
>> changing the behavior willy-nilly, or introduce it but add an option to
>> revert to the old behavior, or leave the default unchanged but add an
>> option to get the new behavior, ...
>
>This really doesn't warrant month-long experiments.  Larger changes like
>variable-pitch modelines might, but IMHO this is too small a change.
>
If it is small, then should be easier to do. Maybe?

Bigger changes on defaults are actually almost impossible to agree for
what I have seen these years. That's why I only try small ones now.

This changes make the new user's experience consistent and just a bit
more dynamic. Ex: going for the 'visible alternative is such a subtle
change that 50% of the users may not even note it.

Old users usually know how to add 1 line to their config if they really
feel annoyed and want to revert. But most of them use
ido/vertico/selectrum/ivy or something else (for a reason btw).

>I would prefer just adding an option to get the new behavior, and asking
>people to try that.
>
(Please ignore the next part if you want as it is totally off-topic)

One of the main issues in Emacs (we have discussed in this same mailing
list several times) is that communication with the community and
external developers is not very efficient. I won't expect emacs to be a
rockstart, but at least a country artist with some seasonal fashion from
time to time.

On every release the NEWS file is so long and most changes are cryptic
for external users; the manual is usually more difficult to explore
(almost impossible to find, or search in for a new user) and the first
impression is in general very bad. I have new students every year and I
try them to use emacs, after a while I notice that they only "stand it"
because (and while) I insist, some of them try external inits from
github to start, some others try customizations like spacemacs or
similes... but at the end all of them end using vim, vscode and so on.

Many of the defaults are very "archaic"... and some are like that
because of hardware limitations from 20-30 years ago. As it is not on
github, contributing, feature requests and issues report system is very
unfamiliar for any <30 years old user and the releases take so long and
contain so many changes (most of them hidden by default) that we still
have users that use the external packages like linum or
fill-column-indicator...

In conclusion we don't have any effective way to "to ask the people to
try" things that maybe they need.

>Thanks.
>
Best,
Ergus

Re: Question about completion behavior

[Po Lu]

Ergus <spacibba@aol.com> writes:

> If it is small, then should be easier to do. Maybe?

No, let's just add an option for it and let people decide for
themselves.  Thanks.

> Old users usually know how to add 1 line to their config if they really
> feel annoyed and want to revert. But most of them use
> ido/vertico/selectrum/ivy or something else (for a reason btw).

If they are happy with ivy or ido, then I don't see why we have to
change anything at all.  Ido is built-in, and ivy is available on ELPA.

> On every release the NEWS file is so long and most changes are cryptic
> for external users; the manual is usually more difficult to explore
> (almost impossible to find, or search in for a new user) and the first
> impression is in general very bad.

Don't we also have a "what's new in..." section in the FAQ, which should
be much shorter than NEWS?  There's also customize-changed, and the user
manual is available from the menu bar (along with the commands to search
in the user manual, and the FAQ.)

> I have new students every year and I try them to use emacs, after a
> while I notice that they only "stand it" because (and while) I insist,
> some of them try external inits from github to start, some others try
> customizations like spacemacs or similes... but at the end all of them
> end using vim, vscode and so on.

I think vim is a very bad example here, since things aren't much
different on their side of the iron curtain.

> Many of the defaults are very "archaic"... and some are like that
> because of hardware limitations from 20-30 years ago.

I can't actually think of instances of that particular reason.  We do
turn on font locking by default now, for example, including in C-like
languages which are in general quite slow to fontify even on today's
hardware.

> In conclusion we don't have any effective way to "to ask the people to
> try" things that maybe they need.

Let's ask on info-gnu-emacs, it should reach a wide enough amount of
people.

Thanks.

Re: Question about completion behavior

[Ergus]

Hi:

I just added a new branch feature/completions-customs.

The changes there are minimal and finished in my opinion.  Whenever any
of the maintainers decide they can correct, fix, or merge into
master. (there is a small issue with the reference in the manual, so
please fix it, but I don't have any more time)

The changes include the max-height for completion window, a
completions-highlight-mode and the new values for completion-auto-help.

==

I didn't include the zcomplete-mode because I am not sure how to name it
and didn't receive any feedback except from Juri.  In total it is 53
lines and provides an interaction similar to zsh (as explained before)
which may be very suitable for new users.

Apart from that I am wondering if it makes sense to add an option to
propertise/configure the Initial line in the Completions buffer (there
is one to remove the help, but not the other)

(for example to remove it or add properties like intangible, a face etc)
could we also add a sort of counter there to indicate the total number
of candidates?


Best,
Ergus.

Re: Question about completion behavior

[Juri Linkov]

> I just added a new branch feature/completions-customs.

Thank you.  I hope these small steps that add new options
will gradually place the default completion UI on a par with
modern completion packages.

One question - please explain what values of completion-auto-help
nil/t/lazy/visible/always now do in these cases that you posted earlier:

  1. no unique        (shows or update completions)
  2. unique common    (complete-common and UPDATE completions)
  3. unique candidate (complete and hides completion)
  4. unique common but completion is a valid entry (complete-common and hides completion)

> The changes there are minimal and finished in my opinion.  Whenever any
> of the maintainers decide they can correct, fix, or merge into
> master. (there is a small issue with the reference in the manual, so
> please fix it, but I don't have any more time)

I fixed these and some other issues in the branch.

> The changes include the max-height for completion window, a
> completions-highlight-mode and the new values for completion-auto-help.

Why not highlight the completions by default?  Unlike other changes,
highlighting doesn't change the previous behavior.

> I didn't include the zcomplete-mode because I am not sure how to name it
> and didn't receive any feedback except from Juri.  In total it is 53
> lines and provides an interaction similar to zsh (as explained before)
> which may be very suitable for new users.

I'm still unsure about this mode.  It's unclear what is the answer
to the main question: should it select the completion buffer or not?

I'll soon post a patch to allows navigation in the completion buffer
without selecting it, i.e. from the minibuffer.  This will handle
the problem of self-inserting keys that will continue working
in the minibuffer.  When this will prove to be insufficient,
then we could add new mode to auto-select the completions buffer.
But then why don't just use the recently added completion-auto-select?

> Apart from that I am wondering if it makes sense to add an option to
> propertise/configure the Initial line in the Completions buffer (there
> is one to remove the help, but not the other)

Do you mean completion-show-help whose nil doesn't remove
text "Possible completions are:"?

> (for example to remove it or add properties like intangible, a face etc)
> could we also add a sort of counter there to indicate the total number
> of candidates?

Good idea.

Re: Question about completion behavior

[Ergus]

Hi juri

On March 10, 2022 7:50:43 PM GMT+01:00, Juri Linkov <juri@linkov.net> wrote:
>> I just added a new branch feature/completions-customs.
>
>Thank you.  I hope these small steps that add new options
>will gradually place the default completion UI on a par with
>modern completion packages.
>
>One question - please explain what values of completion-auto-help
>nil/t/lazy/visible/always now do in these cases that you posted earlier:
>
>  1. no unique        (shows or update completions)
>  2. unique common    (complete-common and UPDATE completions)

The new values only change this case. Always shows or update  completions and visible only updates if they are already visible. The other previous values just hide completions.

>  3. unique candidate (complete and hides completion)
>  4. unique common but completion is a valid entry (complete-common and hides completion)
>
>> The changes there are minimal and finished in my opinion.  Whenever any
>> of the maintainers decide they can correct, fix, or merge into
>> master. (there is a small issue with the reference in the manual, so
>> please fix it, but I don't have any more time)
>
>I fixed these and some other issues in the branch.
>

Thanks :)

>> The changes include the max-height for completion window, a
>> completions-highlight-mode and the new values for completion-auto-help.
>
>Why not highlight the completions by default?  Unlike other changes,
>highlighting doesn't change the previous behavior.
>

You know...

>> I didn't include the zcomplete-mode because I am not sure how to name it
>> and didn't receive any feedback except from Juri.  In total it is 53
>> lines and provides an interaction similar to zsh (as explained before)
>> which may be very suitable for new users.
>
>I'm still unsure about this mode.  It's unclear what is the answer
>to the main question: should it select the completion buffer or not?
>

This one only works with the buffer selected. I minimized the hacks as much as possible. The only change is that when pressing a letter key or when attempting to edit the read only completions buffer, it will try to go to the mini buffer immediately and execute the key command there. Just give it a luck.

>I'll soon post a patch to allows navigation in the completion buffer
>without selecting it, i.e. from the minibuffer. 

We already tried that, but you are a much better lisper... Let's hope ;)

 This will handle
>the problem of self-inserting keys that will continue working
>in the minibuffer.  When this will prove to be insufficient,
>then we could add new mode to auto-select the completions buffer.
>But then why don't just use the recently added completion-auto-select?
>

The zcomplete-mode is intended to be used with completion-auto-select for a better experience indeed. As I said what it does is just to skip the completions when any letter, DEL or edit attempt is done in the Completions. Then it tries to execute the command directly in the mini-buffer before signaling an error... Basically it saves to explicitly jump to the mini-buffer before inserting another letter or delete one. 


>> Apart from that I am wondering if it makes sense to add an option to
>> propertise/configure the Initial line in the Completions buffer (there
>> is one to remove the help, but not the other)
>
>Do you mean completion-show-help whose nil doesn't remove
>text "Possible completions are:"?
>
Yep

>> (for example to remove it or add properties like intangible, a face etc)
>> could we also add a sort of counter there to indicate the total number
>> of candidates?
>
>Good idea.
>
Best,
Ergus
-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

Re: Question about completion behavior

[Ergus]

>> (for example to remove it or add properties like intangible, a face etc)
>> could we also add a sort of counter there to indicate the total number
>> of candidates?
>
>Good idea.

Done, please check it. Should we give it a default value?

Re: Question about completion behavior

[Juri Linkov]

>>One question - please explain what values of completion-auto-help
>>nil/t/lazy/visible/always now do in these cases that you posted earlier:
>>
>>  1. no unique        (shows or update completions)
>>  2. unique common    (complete-common and UPDATE completions)
>
> The new values only change this case.  Always shows or update
> completions and visible only updates if they are already visible.
> The other previous values just hide completions.
>
>>  3. unique candidate (complete and hides completion)
>>  4. unique common but completion is a valid entry (complete-common and hides completion)

Shouldn't some value disable hiding completions in the last case when
there are more completions available with a valid entry as a prefix?
Maybe the same values 'visible'/'always' should be applicable for this case
as well?

Re: Question about completion behavior

[Juri Linkov]

>>> (for example to remove it or add properties like intangible, a face etc)
>>> could we also add a sort of counter there to indicate the total number
>>> of candidates?
>>
>>Good idea.
>
> Done, please check it. Should we give it a default value?

Thanks.  Maybe better to have the whole string with all text properties
as the default value of 'completion-header-text-property-list'
that then could be renamed to e.g. 'completion-header-string'?

Regarding 'completion-lazy-count': it would be even better to allow
customization of this format like in 'icomplete-matches-format'
that was recently added in 28.1.

RE: [External] : Re: Question about completion behavior

[Drew Adams]

> configure the Initial line in the Completions buffer
> ... add a sort of counter there to indicate the
> total number of candidates

I assume you mean the current number of candidates,
i.e., the matches of your current minibuffer input.
(For empty input this is the number of candidates
in the matching domain, i.e., all-completions.)

A better place for such a count, IMO, as well as
for other info about the current completion state
(completion style/mode, sort order etc.), is the
_mode-line_ of the `*Completions* window.

That's what Icicles does.  (In Icicles you can
change things like completion style/mode, and
sort order on the fly, and their defaults can be
configured per command.)

E.g., `M-x forw TAB' might show you this in the
*Completions* mode-line:

 18 candidates, vanilla completion, sorting alphabetical (reversed)
 ^^^^^^^^^^^^^

(Plus other completion status info.)

You can limit the number of candidates displayed,
in which case, e.g., "142 candidates shown/3247",
meaning that you're shown 142 out of 3247 total.

And (by default) when cycling, the *Completions*
mode-line briefly shows you short help about the
current candidate (it then returns to showing the
current general completion status).

E.g. `M-x forw TAB', with candidate `forward-char'
current (which means highlighted in *Completions*
and present in the minibuffer), briefly shows the
first line of its doc string:

 Move point N characters forward (backward if N is negative)

And `C-x C-f' foo TAB', might show this briefly
for the current file-name candidate:

 Bytes: 10083, Saved: 1/14/2022 12:52:46 PM, Access: 3/12/2022 11:05:27 AM, Perm: -rw-rw-rw-

More info about what's shown:

https://www.emacswiki.org/emacs/Icicles_-_Completions_Display#CompletionsModeLine

Re: Question about completion behavior

[Ergus]

On Sat, Mar 12, 2022 at 08:34:18PM +0200, Juri Linkov wrote:
>>>> (for example to remove it or add properties like intangible, a face etc)
>>>> could we also add a sort of counter there to indicate the total number
>>>> of candidates?
>>>
>>>Good idea.
>>
>> Done, please check it. Should we give it a default value?
>
>Thanks.  Maybe better to have the whole string with all text properties
>as the default value of 'completion-header-text-property-list'
>that then could be renamed to e.g. 'completion-header-string'?
>
I don't know a simple way for creating a string with the properties in a
single call.  We may need a sort of wrapper function that initializes
the string and call set properties in a single call otherwise the user
may need to do it manually... 

Something like:

(defun make-text-with-properties (string properties)
        (let ((out string))
             (set-text-properties ...)
             out))

Any better idea?

The other detail is that there are 2 strings: "Possible completions are"
and "There are no possible completions of what you have typed."

>Regarding 'completion-lazy-count': it would be even better to allow
>customization of this format like in 'icomplete-matches-format'
>that was recently added in 28.1.
>
Probably the best is to join the two variables in
completion-header-string and allow it to have a %s for a count... I will
go in that way.

Is it OK?
Best,
Ergus

Re: Question about completion behavior

[Ergus]

On Sat, Mar 12, 2022 at 08:31:57PM +0200, Juri Linkov wrote:
>>>One question - please explain what values of completion-auto-help
>>>nil/t/lazy/visible/always now do in these cases that you posted earlier:
>>>
>>>  1. no unique        (shows or update completions)
>>>  2. unique common    (complete-common and UPDATE completions)
>>
>> The new values only change this case.  Always shows or update
>> completions and visible only updates if they are already visible.
>> The other previous values just hide completions.
>>
>>>  3. unique candidate (complete and hides completion)
>>>  4. unique common but completion is a valid entry (complete-common and hides completion)
>
>Shouldn't some value disable hiding completions in the last case when
>there are more completions available with a valid entry as a prefix?
>Maybe the same values 'visible'/'always' should be applicable for this case
>as well?

Such modification may create an even simpler code.  But we need a way to
hide the completions because there is no way to hide completions in case
the user just wants that.

Alternatives are:

    a) To make minibuffer-hide-completions an interactive function and
find a binding for it. (zsh uses C-g or DEL to first hide completions
and then execute the normal command after a repet.

    b) We could add a feature to toggle completions (ex: add an extra
value 'toggle, that toggles completions in some cases, but that may
exclude 'always or 'visible).

    c) We could hide completions after a second tab after no completion
    was made when vale is 'always or 'visible and completions are
    visible. But that may disable next-completion with tab from the
    minibuffer.

Any idea?
Best,
Ergus

Re: Question about completion behavior

[Juri Linkov]

>> Maybe better to have the whole string with all text properties
>> as the default value of 'completion-header-text-property-list'
>> that then could be renamed to e.g. 'completion-header-string'?
>>
> I don't know a simple way for creating a string with the properties in a
> single call.  We may need a sort of wrapper function that initializes
> the string and call set properties in a single call otherwise the user
> may need to do it manually... Something like:
>
> (defun make-text-with-properties (string properties)
>        (let ((out string))
>             (set-text-properties ...)
>             out))
>
> Any better idea?

Something like

  (defvar completion-header-format
    (propertize "%s possible completions:"
                'face 'shadow
                :help "Please select a completion")
    "Format of completion header.")

> The other detail is that there are 2 strings: "Possible completions are"
> and "There are no possible completions of what you have typed."

In case of no completions it will be formatted to: "0 possible completions".

>> Regarding 'completion-lazy-count': it would be even better to allow
>> customization of this format like in 'icomplete-matches-format'
>> that was recently added in 28.1.
>>
> Probably the best is to join the two variables in
> completion-header-string and allow it to have a %s for a count... I will
> go in that way.
>
> Is it OK?

It's OK, like above.

Re: Question about completion behavior

[Ergus]

On Sun, Mar 13, 2022 at 07:44:49PM +0200, Juri Linkov wrote:
>>> Maybe better to have the whole string with all text properties
>>> as the default value of 'completion-header-text-property-list'
>>> that then could be renamed to e.g. 'completion-header-string'?
>>>
>> I don't know a simple way for creating a string with the properties in a
>> single call.  We may need a sort of wrapper function that initializes
>> the string and call set properties in a single call otherwise the user
>> may need to do it manually... Something like:
>>
>> (defun make-text-with-properties (string properties)
>>        (let ((out string))
>>             (set-text-properties ...)
>>             out))
>>
>> Any better idea?
>
>Something like
>
>  (defvar completion-header-format
>    (propertize "%s possible completions:"
>                'face 'shadow
>                :help "Please select a completion")
>    "Format of completion header.")
>
Interesting... I couldn't find the propertize function in the text
property section of the manual... Done.

>> The other detail is that there are 2 strings: "Possible completions are"
>> and "There are no possible completions of what you have typed."
>
>In case of no completions it will be formatted to: "0 possible completions".
>
I am perfectly fine with that I was just wondering is anyone will
complain just becaus the previous message changed.

>>> Regarding 'completion-lazy-count': it would be even better to allow
>>> customization of this format like in 'icomplete-matches-format'
>>> that was recently added in 28.1.
>>>
>> Probably the best is to join the two variables in
>> completion-header-string and allow it to have a %s for a count... I will
>> go in that way.
>>
>> Is it OK?
>
>It's OK, like above.

Thanks, please check/correct it.

Re: Question about completion behavior

[Eli Zaretskii]

> Date: Sun, 13 Mar 2022 19:50:56 +0100
> From: Ergus <spacibba@aol.com>
> Cc: Po Lu <luangruo@yahoo.com>, Eli Zaretskii <eliz@gnu.org>,
>  Stefan Monnier <monnier@iro.umontreal.ca>, emacs-devel@gnu.org
> 
> >  (defvar completion-header-format
> >    (propertize "%s possible completions:"
> >                'face 'shadow
> >                :help "Please select a completion")
> >    "Format of completion header.")
> >
> Interesting... I couldn't find the propertize function in the text
> property section of the manual...

It's described in the second section of the Text Properties chapter;
the section's name is "Changing Text Properties".  So it is strange
that you didn't find it.

Re: Question about completion behavior

[Ergus]

On Sun, Mar 13, 2022 at 08:57:35PM +0200, Eli Zaretskii wrote:
>> Date: Sun, 13 Mar 2022 19:50:56 +0100
>> From: Ergus <spacibba@aol.com>
>> Cc: Po Lu <luangruo@yahoo.com>, Eli Zaretskii <eliz@gnu.org>,
>>  Stefan Monnier <monnier@iro.umontreal.ca>, emacs-devel@gnu.org
>>
>> >  (defvar completion-header-format
>> >    (propertize "%s possible completions:"
>> >                'face 'shadow
>> >                :help "Please select a completion")
>> >    "Format of completion header.")
>> >
>> Interesting... I couldn't find the propertize function in the text
>> property section of the manual...
>
>It's described in the second section of the Text Properties chapter;
>the section's name is "Changing Text Properties".  So it is strange
>that you didn't find it.
>
Hi Eli:

Yes, now I got it... my bad. I think that the completions-custom branch
is ready for review/correct/merge. So, when you decide I will merge
it...

Best,
Ergus.

RE: [External] : Re: Question about completion behavior

[Drew Adams]

> In case of no completions it will be formatted to: "0 possible
> completions".

Why?  Why wouldn't *Completions* just be
removed?  And "[No match]" is already echoed.

Sounds like things are getting more, not less,
complicated for users (maybe overengineering?).

Why would we ever say "0 possible completions"?

Why bother with "possible"?  We never show
IMpossible completions, do we?

When there are no matches we just tell users
there's no match.  Always have.  Simple.

Re: [External] : Re: Question about completion behavior

[Ergus]

On Sun, Mar 13, 2022 at 08:48:22PM +0000, Drew Adams wrote:
>> In case of no completions it will be formatted to: "0 possible
>> completions".
>
>Why?  Why wouldn't *Completions* just be
>removed?  And "[No match]" is already echoed.
>
In the original code there is a message to print when there are no
completions, that's where the original question came from. Actually the
new code is simpler.

>Sounds like things are getting more, not less,
>complicated for users (maybe overengineering?).
>
For the user everything is pretty much the same.

>Why would we ever say "0 possible completions"?
>
>Why bother with "possible"?  We never show
>IMpossible completions, do we?
>
>When there are no matches we just tell users
>there's no match.  Always have.  Simple.
>

RE: [External] : Re: Question about completion behavior

[Drew Adams]

> >> In case of no completions it will be formatted to: "0 possible
> >> completions".
> >
> > Why?  Why wouldn't *Completions* just be
> > removed?  And "[No match]" is already echoed.
>
> In the original code there is a message to print when there are no
> completions, that's where the original question came from. Actually the
> new code is simpler.

Dunno what that means.  What "original code"?
And I see nothing in your "original question"
(the start of this thread) about any of this.

I don't care whether "the new code is simpler"
(and simpler than what - what old code?).

I'm interested in the user experience.
Coding that experience isn't the problem
(shouldn't be, anyway).

> > Sounds like things are getting more, not less,
> > complicated for users (maybe overengineering?).
>
> For the user everything is pretty much the same.

Doesn't sound like it - not regarding what I
asked about, at least.

I have nothing against keeping *Completions*
showing and updating it as a user changes the
pattern to match (and either explicitly asks
for a rematch or has elected to get automatic
rematching).

In fact, I invented such behavior for Emacs
(a couple decades ago).

But why would we not _remove_ *Completions*
when there are no matches?

We tell users in the echo area that there are
no matches.  Why also show an empty buffer,
for nonexistent completions, with a redundant
message there saying there are none?

(That's IBM's "This page intentionally left
blank."  But at least there was a reason for
that notice.)

Maybe "the new code is simpler".  It sounds
like the new user experience is less simple
- and maybe a step backward.

I understand your feature would be optional.
It sounds like it has room for improvement.

> > Why would we ever say "0 possible completions"?
> >
> > Why bother with "possible"?  We never show
> > IMpossible completions, do we?
> >
> > When there are no matches we just tell users
> > there's no match.  Always have.  Simple.

And your answer is?

Re: [External] : Re: Question about completion behavior

[Ergus]

On Sun, Mar 13, 2022 at 11:14:56PM +0000, Drew Adams wrote:

Hi Drew:

Man, please relax...

>
>Doesn't sound like it - not regarding what I
>asked about, at least.
>
>I have nothing against keeping *Completions*
>showing and updating it as a user changes the
>pattern to match (and either explicitly asks
>for a rematch or has elected to get automatic
>rematching).
>
>In fact, I invented such behavior for Emacs
>(a couple decades ago).
>
>But why would we not _remove_ *Completions*
>when there are no matches?
>
>We tell users in the echo area that there are
>no matches.  Why also show an empty buffer,
>for nonexistent completions, with a redundant
>message there saying there are none?
>
>(That's IBM's "This page intentionally left
>blank."  But at least there was a reason for
>that notice.)
>
>Maybe "the new code is simpler".  It sounds
>like the new user experience is less simple
>- and maybe a step backward.
>
>I understand your feature would be optional.
>It sounds like it has room for improvement.
>
The user experience is exactly the same than before.  Just that now
there is an option to change, suppress or/and get a counter with the
total number of completions where there was before just a bit
superfluous hard-coded message: "Possible completions are:"

That's it. Everything else is exactly the same. As usual, I am not doing
rocket engineering here; I am just adding something simple and obvious
that nobody wanted to give any attention before; in spite of many more
experienced lispers like you could implement this in 30 minutes two
decades ago ;p.

>> > Why would we ever say "0 possible completions"?
>> >
>> > Why bother with "possible"?  We never show
>> > IMpossible completions, do we?
>> >
>> > When there are no matches we just tell users
>> > there's no match.  Always have.  Simple.
>
>And your answer is?

Because the original message was: "Possible completions are:" and it has
been there since ever without hearing your complains about that the
completions are not IMpossible.

I don't care anything about one word at all and if the user doesn't like
the word or you want to put there "Drews completions are:", at least now
you have an option to customize it as you prefer...

Best,
Ergus

RE: [External] : Re: Question about completion behavior

[Drew Adams]

> Man, please relax...

Oh, I'm relaxed.  Believe me, Man. ;-)

> The user experience is exactly the same than before.  Just that now
> there is an option to change, suppress or/and get a counter with the
> total number of completions

I already welcomed that, in a previous message.
It's helpful to tell users how many completions
there are.

(I suggested that the *Completions* mode-line
might be a better place for it.)

> where there was before just a bit superfluous
> hard-coded message: "Possible completions are:"
> 
> That's it. Everything else is exactly the same.

My message wasn't about your addition of the
number of matches at the top of *Completions*
(when there _are_ matches).

> >> > Why would we ever say "0 possible completions"?
> >> > Why bother with "possible"?  We never show
> >> > IMpossible completions, do we?
> >> >
> >> > When there are no matches we just tell users
> >> > there's no match.  Always have.  Simple.
> >
> >And your answer is?
> 
> Because the original message was: "Possible
> completions are:" and it has been there since
> ever without hearing your complains about that
> the completions are not IMpossible.

I don't see "Possible completions are:" when there
are no completions.  What I see is that window
*Completions* is removed when you try to complete
a pattern that has no matches.

(Granted, I'm looking at the latest release, 27.2,
not any new work-in-progress.  But you say this
thing I don't see has been there forever, so I'm
perplexed.  We must not be smoking the same thing.)

My point was that, compared to the vanilla, age-old
behavior of removing the *Completions* window when
you try to match an unmatchable pattern, a proposed
new behavior of continuing to show *Completions*,
but with a message at the top saying "0 possible
completions" (or any other wording of that), sounds
like a step backward, to me.  That's all.  Just one
opinion.

(And I don't even use the vanilla *Completions*
behavior.  I just happen to care about Emacs beyond
my own use of it.)

> I don't care anything about one word at all and if
> the user doesn't like the word or you want to put
> there "Drews completions are:", at least now
> you have an option to customize it as you prefer...

I don't want to put anything there.  I'm asking why
we'd want to show a buffer that lists no completions,
instead of just removing that window.  I'm asking
why that would be an improvement - or even a good
option to offer.