bug#67661: 30.0.50; *Completions* has started popping up for icomplete-in-buffer

bug#67661: 30.0.50; *Completions* has started popping up for icomplete-in-buffer

[Sean Whitton]

X-debbugs-cc: juri@linkov.net

Hello,

1. emacs -q
2. (setopt icomplete-in-buffer t)
3. M-x icomplete-mode
4. M-x eshell
5. try to tab-complete something where there is more than one possible
   completion, e.g. ls<TAB> in a directory with many files.

Previously you would get the icomplete in buffer completion.
Now, additionally, *Completions* pops up, but it doesn't make sense to
have both.

-- 
Sean Whitton

bug#67661: 30.0.50; *Completions* has started popping up for icomplete-in-buffer

[Juri Linkov]

> 1. emacs -q
> 2. (setopt icomplete-in-buffer t)
> 3. M-x icomplete-mode
> 4. M-x eshell
> 5. try to tab-complete something where there is more than one possible
>    completion, e.g. ls<TAB> in a directory with many files.
>
> Previously you would get the icomplete in buffer completion.
> Now, additionally, *Completions* pops up, but it doesn't make sense to
> have both.

Is this related to bug#61943?

bug#67661: 30.0.50; *Completions* has started popping up for icomplete-in-buffer

[Sean Whitton]

Hello,

On Wed 06 Dec 2023 at 07:13pm +02, Juri Linkov wrote:

>> 1. emacs -q
>> 2. (setopt icomplete-in-buffer t)
>> 3. M-x icomplete-mode
>> 4. M-x eshell
>> 5. try to tab-complete something where there is more than one possible
>>    completion, e.g. ls<TAB> in a directory with many files.
>>
>> Previously you would get the icomplete in buffer completion.
>> Now, additionally, *Completions* pops up, but it doesn't make sense to
>> have both.
>
> Is this related to bug#61943?

I'm not using fido-mode anymore, so I doubt it.

-- 
Sean Whitton

bug#67661: 30.0.50; *Completions* has started popping up for icomplete-in-buffer

[Eli Zaretskii]

> Cc: juri@linkov.net
> From: Sean Whitton <spwhitton@spwhitton.name>
> Date: Wed, 06 Dec 2023 15:30:12 +0000
> 
> X-debbugs-cc: juri@linkov.net
> 
> Hello,
> 
> 1. emacs -q
> 2. (setopt icomplete-in-buffer t)
> 3. M-x icomplete-mode
> 4. M-x eshell
> 5. try to tab-complete something where there is more than one possible
>    completion, e.g. ls<TAB> in a directory with many files.
> 
> Previously you would get the icomplete in buffer completion.
> Now, additionally, *Completions* pops up, but it doesn't make sense to
> have both.

AFAICT, the above description of the problem is inaccurate.  The
*Completions* buffer would pop up in previous versions as well, but
only after a second TAB.  Whereas the in-buffer completion would show
after the first TAB.  Now in Emacs 30 after the first TAB nothing
happens, and after the second TAB you see the same display as
previously after the second TAB: both in-buffer completion and the
*Completions* buffer popped up.

So I think the problem is that the first TAB does NOT show in-buffer
completion anymore in the above scenario.

bug#67661: 30.0.50; *Completions* has started popping up for icomplete-in-buffer

[Sean Whitton]

Hello,

On Wed 06 Dec 2023 at 08:41pm +02, Eli Zaretskii wrote:

>> Cc: juri@linkov.net
>> From: Sean Whitton <spwhitton@spwhitton.name>
>> Date: Wed, 06 Dec 2023 15:30:12 +0000
>>
>> X-debbugs-cc: juri@linkov.net
>>
>> Hello,
>>
>> 1. emacs -q
>> 2. (setopt icomplete-in-buffer t)
>> 3. M-x icomplete-mode
>> 4. M-x eshell
>> 5. try to tab-complete something where there is more than one possible
>>    completion, e.g. ls<TAB> in a directory with many files.
>>
>> Previously you would get the icomplete in buffer completion.
>> Now, additionally, *Completions* pops up, but it doesn't make sense to
>> have both.
>
> AFAICT, the above description of the problem is inaccurate.  The
> *Completions* buffer would pop up in previous versions as well, but
> only after a second TAB.  Whereas the in-buffer completion would show
> after the first TAB.  Now in Emacs 30 after the first TAB nothing
> happens, and after the second TAB you see the same display as
> previously after the second TAB: both in-buffer completion and the
> *Completions* buffer popped up.
>
> So I think the problem is that the first TAB does NOT show in-buffer
> completion anymore in the above scenario.

Confirmed, thank you.

-- 
Sean Whitton

bug#67661: 30.0.50; *Completions* has started popping up for icomplete-in-buffer

[Sean Whitton]

Hello,

On Wed 06 Dec 2023 at 08:41pm +02, Eli Zaretskii wrote:

> AFAICT, the above description of the problem is inaccurate.  The
> *Completions* buffer would pop up in previous versions as well, but
> only after a second TAB.  Whereas the in-buffer completion would show
> after the first TAB.  Now in Emacs 30 after the first TAB nothing
> happens, and after the second TAB you see the same display as
> previously after the second TAB: both in-buffer completion and the
> *Completions* buffer popped up.
>
> So I think the problem is that the first TAB does NOT show in-buffer
> completion anymore in the above scenario.

Commit 5416896d608 is responsible for the problem.
It would seem that it turns off completion-in-region-mode too early.

Eshel, Juri, can you take a look, please?

Thanks.

-- 
Sean Whitton

bug#67661: 30.0.50; *Completions* has started popping up for icomplete-in-buffer

[Eshel Yaron via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Hi Sean,

Sean Whitton <spwhitton@spwhitton.name> writes:

> Previously you would get the icomplete in buffer completion.  Now,
> additionally, *Completions* pops up, but it doesn't make sense to have
> both.

I agree that having both interface together is a bit much, but AFAICT
that has been the case at least since Emacs 27 whenever the text before
point was the longest common prefix of several completion candidates.
For example, try completing "l" instead of "ls" in eshell.  On both
Emacs 27 and on master, this shows both the *Completions* buffer and the
in-buffer `icomplete` interface.  Is this what you get as well?

Sean Whitton <spwhitton@spwhitton.name> writes:

> Hello,
>
> On Wed 06 Dec 2023 at 08:41pm +02, Eli Zaretskii wrote:
>
>> AFAICT, the above description of the problem is inaccurate.  The
>> *Completions* buffer would pop up in previous versions as well, but
>> only after a second TAB.  Whereas the in-buffer completion would show
>> after the first TAB.  Now in Emacs 30 after the first TAB nothing
>> happens, and after the second TAB you see the same display as
>> previously after the second TAB: both in-buffer completion and the
>> *Completions* buffer popped up.
>>
>> So I think the problem is that the first TAB does NOT show in-buffer
>> completion anymore in the above scenario.
>
> Commit 5416896d608 is responsible for the problem.
> It would seem that it turns off completion-in-region-mode too early.

IIUC, the problem of showing both interfaces is inherent to how
`icomplete-in-buffer` is implemented.  It's just that in this case of
completing "ls" the *Completions* doesn't show up at first because it's
an exact match.  What allowed the `icomplete` to show up is that
although the *Completions* buffer wasn't shown,
`completion-in-region-mode` would remain on, and that caused only the
`icomplete` interface to appear in this specific case.

The reason we now disable `completion-in-region-mode` when it doesn't
show the *Completions* buffer, is to avoid having the key bindings that
this minor mode sets up from lingering and shadowing other bindings.


If it doesn't make sense for `icomplete-in-buffer` to appear along with
the *Completions* buffer, perhaps `icomplete-in-buffer` should simply be
an alternative `completion-in-region-function`?


Best,

Eshel

bug#67661: 30.0.50; *Completions* has started popping up for icomplete-in-buffer

[Eli Zaretskii]

> From: Eshel Yaron <me@eshelyaron.com>
> Cc: Juri Linkov <juri@linkov.net>,  67661@debbugs.gnu.org,  Eli Zaretskii
>  <eliz@gnu.org>,  67001@debbugs.gnu.org
> Date: Sat, 09 Dec 2023 14:08:45 +0100
> 
> Sean Whitton <spwhitton@spwhitton.name> writes:
> 
> > Previously you would get the icomplete in buffer completion.  Now,
> > additionally, *Completions* pops up, but it doesn't make sense to have
> > both.
> 
> I agree that having both interface together is a bit much, but AFAICT
> that has been the case at least since Emacs 27 whenever the text before
> point was the longest common prefix of several completion candidates.
> For example, try completing "l" instead of "ls" in eshell.  On both
> Emacs 27 and on master, this shows both the *Completions* buffer and the
> in-buffer `icomplete` interface.  Is this what you get as well?

This is not the regression that needs to be fixed here.

> > On Wed 06 Dec 2023 at 08:41pm +02, Eli Zaretskii wrote:
> >
> >> AFAICT, the above description of the problem is inaccurate.  The
> >> *Completions* buffer would pop up in previous versions as well, but
> >> only after a second TAB.  Whereas the in-buffer completion would show
> >> after the first TAB.  Now in Emacs 30 after the first TAB nothing
> >> happens, and after the second TAB you see the same display as
> >> previously after the second TAB: both in-buffer completion and the
> >> *Completions* buffer popped up.
> >>
> >> So I think the problem is that the first TAB does NOT show in-buffer
> >> completion anymore in the above scenario.
> >
> > Commit 5416896d608 is responsible for the problem.
> > It would seem that it turns off completion-in-region-mode too early.
> 
> IIUC, the problem of showing both interfaces is inherent to how
> `icomplete-in-buffer` is implemented.

Once again, the fact that the second TAB shows both completion
interfaces is not the problem: as you point out that was how Emacs
behaved since long ago.  The problem here is that the _first_ TAB does
NOT show in-buffer completions.  This should be fixed, since it is a
regression wrt Emacs 29.

> It's just that in this case of
> completing "ls" the *Completions* doesn't show up at first because it's
> an exact match.  What allowed the `icomplete` to show up is that
> although the *Completions* buffer wasn't shown,
> `completion-in-region-mode` would remain on, and that caused only the
> `icomplete` interface to appear in this specific case.
> 
> The reason we now disable `completion-in-region-mode` when it doesn't
> show the *Completions* buffer, is to avoid having the key bindings that
> this minor mode sets up from lingering and shadowing other bindings.

That sounds like some very technical problem, and it should be fixed
by some other means than disabling completion-in-region-mode.

> If it doesn't make sense for `icomplete-in-buffer` to appear along with
> the *Completions* buffer

Again, this is not the problem to solve.

bug#67661: 30.0.50; *Completions* has started popping up for icomplete-in-buffer

[Eshel Yaron via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Eshel Yaron <me@eshelyaron.com>
>>
>> Sean Whitton <spwhitton@spwhitton.name> writes:
>>
>> > Previously you would get the icomplete in buffer completion.  Now,
>> > additionally, *Completions* pops up, but it doesn't make sense to have
>> > both.
>>
>> I agree that having both interface together is a bit much, but AFAICT
>> that has been the case at least since Emacs 27 whenever the text before
>> point was the longest common prefix of several completion candidates.
>> For example, try completing "l" instead of "ls" in eshell.  On both
>> Emacs 27 and on master, this shows both the *Completions* buffer and the
>> in-buffer `icomplete` interface.  Is this what you get as well?
>> [...]
>> IIUC, the problem of showing both interfaces is inherent to how
>> `icomplete-in-buffer` is implemented.
>
> Once again, the fact that the second TAB shows both completion
> interfaces is not the problem: as you point out that was how Emacs
> behaved since long ago.  The problem here is that the _first_ TAB does
> NOT show in-buffer completions.

Yes, but what I pointed out was that the first TAB has been showing both
interfaces since Emacs 27, just not with this particular recipe.

>> If it doesn't make sense for `icomplete-in-buffer` to appear along
>> with the *Completions* buffer
>
> Again, this is not the problem to solve.

Could you explain what you mean here?  If this behavior doesn't make
sense, isn't it worth trying to solve it for all cases, rather than just
for one specific case?

bug#67661: 30.0.50; *Completions* has started popping up for icomplete-in-buffer

[Eli Zaretskii]

> From: Eshel Yaron <me@eshelyaron.com>
> Cc: spwhitton@spwhitton.name,  juri@linkov.net,  67661@debbugs.gnu.org,
>   67001@debbugs.gnu.org
> Date: Sat, 09 Dec 2023 15:13:53 +0100
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > Once again, the fact that the second TAB shows both completion
> > interfaces is not the problem: as you point out that was how Emacs
> > behaved since long ago.  The problem here is that the _first_ TAB does
> > NOT show in-buffer completions.
> 
> Yes, but what I pointed out was that the first TAB has been showing both
> interfaces since Emacs 27, just not with this particular recipe.

That's not what I see in Emacs 29.  There' the first TAB shows only
the in-buffer completions, and the second TAB pops up the
*Completions* buffer (without removing the in-buffer completions).

> >> If it doesn't make sense for `icomplete-in-buffer` to appear along
> >> with the *Completions* buffer
> >
> > Again, this is not the problem to solve.
> 
> Could you explain what you mean here?  If this behavior doesn't make
> sense, isn't it worth trying to solve it for all cases, rather than just
> for one specific case?

I don't think I understand what you mean by "one specific case".
Which case, and why is it specific?

Sean reported a regression in behavior under icomplete-in-buffer, so I
looked into the recipe he posted.  What I saw was that Emacs 29 shows
the in-buffer completions after the first TAB and adds to that the
*Completions* buffer after the second TAB.  By contrast, Emacs 30
shows nothing after the first TAB, and shows both in-buffer
completions and the *Completions* buffer after the second TAB.  So my
conclusion was that the regression is the behavior after the first
TAB.  If this conclusion is incorrect, please tell what did I miss.

bug#67661: 30.0.50; *Completions* has started popping up for icomplete-in-buffer

[Sean Whitton]

Hello,

On Sat 09 Dec 2023 at 04:40pm +02, Eli Zaretskii wrote:

> Sean reported a regression in behavior under icomplete-in-buffer, so I
> looked into the recipe he posted.  What I saw was that Emacs 29 shows
> the in-buffer completions after the first TAB and adds to that the
> *Completions* buffer after the second TAB.  By contrast, Emacs 30
> shows nothing after the first TAB, and shows both in-buffer
> completions and the *Completions* buffer after the second TAB.  So my
> conclusion was that the regression is the behavior after the first
> TAB.  If this conclusion is incorrect, please tell what did I miss.

This is exactly how I understand the situation.

icomplete-in-buffer didn't work at all for years, until Juri (iirc)
fixed it for Emacs 29.  So what happens in much older Emacs doesn't seem
important.  It's a regression since Emacs 29.

-- 
Sean Whitton

bug#67661: 30.0.50; *Completions* has started popping up for icomplete-in-buffer

[Eshel Yaron via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Eshel Yaron <me@eshelyaron.com>
>> Cc: spwhitton@spwhitton.name,  juri@linkov.net,  67661@debbugs.gnu.org,
>>   67001@debbugs.gnu.org
>> Date: Sat, 09 Dec 2023 15:13:53 +0100
>>
>> Eli Zaretskii <eliz@gnu.org> writes:
>>
>> > Once again, the fact that the second TAB shows both completion
>> > interfaces is not the problem: as you point out that was how Emacs
>> > behaved since long ago.  The problem here is that the _first_ TAB does
>> > NOT show in-buffer completions.
>>
>> Yes, but what I pointed out was that the first TAB has been showing both
>> interfaces since Emacs 27, just not with this particular recipe.
>
> That's not what I see in Emacs 29.  There' the first TAB shows only
> the in-buffer completions, and the second TAB pops up the
> *Completions* buffer (without removing the in-buffer completions).

Did you try with "l" before point instead of "ls" as I suggested?

Sean, how about you?

>> >> If it doesn't make sense for `icomplete-in-buffer` to appear along
>> >> with the *Completions* buffer
>> >
>> > Again, this is not the problem to solve.
>>
>> Could you explain what you mean here?  If this behavior doesn't make
>> sense, isn't it worth trying to solve it for all cases, rather than just
>> for one specific case?
>
> I don't think I understand what you mean by "one specific case".
> Which case, and why is it specific?

I was referring to the specific case that Sean's recipe illustrated.
This case exhibits a change in behavior that you clearly described, and
that change is supposedly for the worse.  IIUC what bothers Sean is that
both interfaces appear together, but the thing is that that seems to be
inherent to how `icomplete-in-buffer` currently works.

> Sean reported a regression in behavior under icomplete-in-buffer, so I
> looked into the recipe he posted.  What I saw was that Emacs 29 shows
> the in-buffer completions after the first TAB and adds to that the
> *Completions* buffer after the second TAB.  By contrast, Emacs 30
> shows nothing after the first TAB, and shows both in-buffer
> completions and the *Completions* buffer after the second TAB.  So my
> conclusion was that the regression is the behavior after the first
> TAB.  If this conclusion is incorrect, please tell what did I miss.

I think your reasoning is perfectly sound, but since already in Emacs 29
(and beforehand) both interfaces would appear together after the first
TAB if you complete another string, restoring the behavior of Emacs 29
wouldn't fully address this problem.

Put plainly, I'm not sure the Emacs 29 behavior of `icomplete-in-buffer`
is any more intended than the current behavior.  Stefan Monnier wrote[0]
a couple of years ago about `icomplete-in-buffer`:

  I wrote it this way [as a defvar] because I consider(ed) that code
  just "proof of concept" and not working well enough to inflict it on
  unsuspecting users.

Followed by:

  The problem is not so much in the code but in the behavior.  If you
  think the behavior is good enough, then by all means use it, but I
  think it's a bit rough around the edges.


I don't use `icomplete-in-buffer` myself, but seems like Sean does, so
my suggestion was that we implement this in earnest as a
`completion-in-region-function`, while specifying the intended behavior
regarding TABs, overlays, and the *Completions* buffer.


Best,

Eshel

[0] https://yhetil.org/emacs/jwvzgv1yec5.fsf-monnier+emacs@gnu.org/

bug#67661: 30.0.50; *Completions* has started popping up for icomplete-in-buffer

[Sean Whitton]

Hello,

On Sat 09 Dec 2023 at 05:03pm +01, Eshel Yaron wrote:

> Did you try with "l" before point instead of "ls" as I suggested?
>
> Sean, how about you?

I haven't tried this, because it does not seem to be relevant.

> I was referring to the specific case that Sean's recipe illustrated.
> This case exhibits a change in behavior that you clearly described, and
> that change is supposedly for the worse.  IIUC what bothers Sean is that
> both interfaces appear together, but the thing is that that seems to be
> inherent to how `icomplete-in-buffer` currently works.

No, what bothers me is the regression as described by Eli.

I apologise for not being clearer in my initial report.
Thank you for your engagement.

-- 
Sean Whitton

bug#67661: 30.0.50; *Completions* has started popping up for icomplete-in-buffer

[Juri Linkov]

>> I was referring to the specific case that Sean's recipe illustrated.
>> This case exhibits a change in behavior that you clearly described, and
>> that change is supposedly for the worse.  IIUC what bothers Sean is that
>> both interfaces appear together, but the thing is that that seems to be
>> inherent to how `icomplete-in-buffer` currently works.
>
> No, what bothers me is the regression as described by Eli.

By definition a regression is a bug where a feature that has worked before
stops working.  As you noted, icomplete-in-buffer didn't work for years,
until I fixed it for Emacs 29 (as least brought it to a usable state).
The test case that you described shows its effect only by accident,
until Eshel improved the related behavior of completion-in-region-mode,
so that now icomplete-in-buffer works consistently when it enables
both at the same time: in-buffer completions and in *Completions*.

So instead of trying to restore an arbitrary behavior at the moment
just after icomplete-in-buffer became usable, it would be much more
useful to invest energy to deciding how better to finish this feature.

bug#67661: 30.0.50; *Completions* has started popping up for icomplete-in-buffer

[Sean Whitton]

Hello,

On Sat 09 Dec 2023 at 07:19pm +02, Juri Linkov wrote:

>>> I was referring to the specific case that Sean's recipe illustrated.
>>> This case exhibits a change in behavior that you clearly described, and
>>> that change is supposedly for the worse.  IIUC what bothers Sean is that
>>> both interfaces appear together, but the thing is that that seems to be
>>> inherent to how `icomplete-in-buffer` currently works.
>>
>> No, what bothers me is the regression as described by Eli.
>
> By definition a regression is a bug where a feature that has worked before
> stops working.  As you noted, icomplete-in-buffer didn't work for years,
> until I fixed it for Emacs 29 (as least brought it to a usable state).
> The test case that you described shows its effect only by accident,
> until Eshel improved the related behavior of completion-in-region-mode,
> so that now icomplete-in-buffer works consistently when it enables
> both at the same time: in-buffer completions and in *Completions*.
>
> So instead of trying to restore an arbitrary behavior at the moment
> just after icomplete-in-buffer became usable, it would be much more
> useful to invest energy to deciding how better to finish this feature.

Okay, well, if we think about it in terms of finishing the feature, then
as the person who worked on it previously, could you share how you think
it ought to work?

ISTM that a single tab in Eshell starting completion, and a single tab
not popping up a *Completions* buffer, are pretty clearly what we would
want it to do, but maybe I just got used to it :)

-- 
Sean Whitton

bug#67661: 30.0.50; *Completions* has started popping up for icomplete-in-buffer

[Juri Linkov]

> Okay, well, if we think about it in terms of finishing the feature, then
> as the person who worked on it previously, could you share how you think
> it ought to work?
>
> ISTM that a single tab in Eshell starting completion, and a single tab
> not popping up a *Completions* buffer, are pretty clearly what we would
> want it to do, but maybe I just got used to it :)

I think that Eshel is right about setting `completion-in-region-function`
to a new function.  This function should be like `completion--in-region`
but without this line:

  (completion--in-region-1 start end)

If you just remove this line from `completion--in-region` then
it should work like you expected without popping up *Completions*.

bug#67661: 30.0.50; *Completions* has started popping up for icomplete-in-buffer

[Sean Whitton]

Hello,

On Sun 10 Dec 2023 at 07:46pm +02, Juri Linkov wrote:

>> Okay, well, if we think about it in terms of finishing the feature, then
>> as the person who worked on it previously, could you share how you think
>> it ought to work?
>>
>> ISTM that a single tab in Eshell starting completion, and a single tab
>> not popping up a *Completions* buffer, are pretty clearly what we would
>> want it to do, but maybe I just got used to it :)
>
> I think that Eshel is right about setting `completion-in-region-function`
> to a new function.  This function should be like `completion--in-region`
> but without this line:
>
>   (completion--in-region-1 start end)
>
> If you just remove this line from `completion--in-region` then
> it should work like you expected without popping up *Completions*.

Thanks, that does indeed restore the behaviour.

Should we change this to a different completion-in-region-function in
icomplete.el, then?  Or what did you have in mind?

-- 
Sean Whitton

bug#67661: 30.0.50; *Completions* has started popping up for icomplete-in-buffer

[Juri Linkov]

>>   (completion--in-region-1 start end)
>>
>> If you just remove this line from `completion--in-region` then
>> it should work like you expected without popping up *Completions*.
>
> Thanks, that does indeed restore the behaviour.
>
> Should we change this to a different completion-in-region-function in
> icomplete.el, then?  Or what did you have in mind?

What I think is that ideally icomplete-in-buffer in a regular buffer
should work like in the minibuffer, i.e. to be active all the time.
This is more like completion-preview-mode where in-buffer candidates
are shown as you type, whereas explicitly typing M-C-i pops up
the *Completions* buffer.  Do you agree this would be nice to do?

bug#67661: 30.0.50; *Completions* has started popping up for icomplete-in-buffer

[Sean Whitton]

Hello,

On Mon 11 Dec 2023 at 07:15pm +02, Juri Linkov wrote:

>>>   (completion--in-region-1 start end)
>>>
>>> If you just remove this line from `completion--in-region` then
>>> it should work like you expected without popping up *Completions*.
>>
>> Thanks, that does indeed restore the behaviour.
>>
>> Should we change this to a different completion-in-region-function in
>> icomplete.el, then?  Or what did you have in mind?
>
> What I think is that ideally icomplete-in-buffer in a regular buffer
> should work like in the minibuffer, i.e. to be active all the time.
> This is more like completion-preview-mode where in-buffer candidates
> are shown as you type, whereas explicitly typing M-C-i pops up
> the *Completions* buffer.  Do you agree this would be nice to do?

Hmm.  This is an interesting idea.  I don't think it would suit me,
though -- it sounds like it would be quite visually noisy.  Do you think
we can provide both?

-- 
Sean Whitton

bug#67661: 30.0.50; *Completions* has started popping up for icomplete-in-buffer

[Juri Linkov]

>>>>   (completion--in-region-1 start end)
>>>>
>>>> If you just remove this line from `completion--in-region` then
>>>> it should work like you expected without popping up *Completions*.
>>>
>>> Thanks, that does indeed restore the behaviour.
>>>
>>> Should we change this to a different completion-in-region-function in
>>> icomplete.el, then?  Or what did you have in mind?
>>
>> What I think is that ideally icomplete-in-buffer in a regular buffer
>> should work like in the minibuffer, i.e. to be active all the time.
>> This is more like completion-preview-mode where in-buffer candidates
>> are shown as you type, whereas explicitly typing M-C-i pops up
>> the *Completions* buffer.  Do you agree this would be nice to do?
>
> Hmm.  This is an interesting idea.  I don't think it would suit me,
> though -- it sounds like it would be quite visually noisy.  Do you think
> we can provide both?

Both are already shown: M-C-i pops up the *Completions* buffer
and activates in-buffer candidates.  If you want M-C-i only
to activate in-buffer candidates, then the line above
should be removed from `completion--in-region`.

bug#67661: 30.0.50; *Completions* has started popping up for icomplete-in-buffer

[Sean Whitton]

Hello,

On Tue 19 Dec 2023 at 07:29pm +02, Juri Linkov wrote:

> Both are already shown: M-C-i pops up the *Completions* buffer
> and activates in-buffer candidates.  If you want M-C-i only
> to activate in-buffer candidates, then the line above
> should be removed from `completion--in-region`.

When I said "provide both", I meant both your idea of how the feature
should work, and my idea of how it should work.  I didn't mean both the
in-buffer candidates and the *Completions* buffer.

What you've said isn't true, though: a single TAB, which is bound to
completion-at-point in Eshell, does not show in-buffer candidates, nor
does it pop up the *Completions* buffer.

-- 
Sean Whitton

bug#67661: 30.0.50; *Completions* has started popping up for icomplete-in-buffer

[Juri Linkov]

>> Both are already shown: M-C-i pops up the *Completions* buffer
>> and activates in-buffer candidates.  If you want M-C-i only
>> to activate in-buffer candidates, then the line above
>> should be removed from `completion--in-region`.
>
> When I said "provide both", I meant both your idea of how the feature
> should work, and my idea of how it should work.  I didn't mean both the
> in-buffer candidates and the *Completions* buffer.
>
> What you've said isn't true, though: a single TAB, which is bound to
> completion-at-point in Eshell, does not show in-buffer candidates, nor
> does it pop up the *Completions* buffer.

Because ls<TAB> is complete, but not unique.  So it requires the second TAB,
exactly as in the minibuffer.  A single TAB does this on incomplete candidate,
e.g. l<TAB>.

bug#67661: 30.0.50; *Completions* has started popping up for icomplete-in-buffer

[Sean Whitton]

Hello,

On Tue 19 Dec 2023 at 08:58pm +02, Juri Linkov wrote:

>>> Both are already shown: M-C-i pops up the *Completions* buffer
>>> and activates in-buffer candidates.  If you want M-C-i only
>>> to activate in-buffer candidates, then the line above
>>> should be removed from `completion--in-region`.
>>
>> When I said "provide both", I meant both your idea of how the feature
>> should work, and my idea of how it should work.  I didn't mean both the
>> in-buffer candidates and the *Completions* buffer.
>>
>> What you've said isn't true, though: a single TAB, which is bound to
>> completion-at-point in Eshell, does not show in-buffer candidates, nor
>> does it pop up the *Completions* buffer.
>
> Because ls<TAB> is complete, but not unique.  So it requires the second TAB,
> exactly as in the minibuffer.  A single TAB does this on incomplete candidate,
> e.g. l<TAB>.

Ah.  This is not the bug.  We may have been subtly miscommunicating.
I am talking about completing the first argument to the command, not
the 'ls' command itself.

So for example:

1. emacs -q
2. (setopt icomplete-in-buffer t)
3. M-x icomplete-mode
4. M-x eshell
5. cd ~/src/emacs/
6. ls l<TAB>

It takes a second <TAB> to have Emacs display leim, lib, lib-src, lisp etc..

-- 
Sean Whitton

bug#67661: 30.0.50; *Completions* has started popping up for icomplete-in-buffer

[Juri Linkov]

>> Because ls<TAB> is complete, but not unique.  So it requires the second TAB,
>> exactly as in the minibuffer.  A single TAB does this on incomplete candidate,
>> e.g. l<TAB>.
>
> Ah.  This is not the bug.  We may have been subtly miscommunicating.
> I am talking about completing the first argument to the command, not
> the 'ls' command itself.
>
> So for example:
>
> 1. emacs -q
> 2. (setopt icomplete-in-buffer t)
> 3. M-x icomplete-mode
> 4. M-x eshell
> 5. cd ~/src/emacs/
> 6. ls l<TAB>
>
> It takes a second <TAB> to have Emacs display leim, lib, lib-src, lisp etc..

Thanks for the reproducible test case.  It seems there is a bug somewhere in
pcomplete-completions-at-point.  Without icomplete:

1. emacs -q
2. M-x eshell
3. ls l<TAB>

says "Complete, but not unique" that is not true.

There is no such problem with shell that uses comint-completion-at-point
instead of pcomplete-completions-at-point.

bug#67661: 30.0.50; *Completions* has started popping up for icomplete-in-buffer

[Sean Whitton]

retitle 67661 30.0.50; Completion problem introduced by commit 5416896d608
thanks

Hello,

On Wed 20 Dec 2023 at 07:14pm +02, Juri Linkov wrote:

> Thanks for the reproducible test case.  It seems there is a bug somewhere in
> pcomplete-completions-at-point.  Without icomplete:
>
> 1. emacs -q
> 2. M-x eshell
> 3. ls l<TAB>
>
> says "Complete, but not unique" that is not true.
>
> There is no such problem with shell that uses comint-completion-at-point
> instead of pcomplete-completions-at-point.

I have confirmed that 5416896d608 is the commit that introduces/reveals
the problem, for my revised test case.

-- 
Sean Whitton

bug#67661: 30.0.50; *Completions* has started popping up for icomplete-in-buffer

[Juri Linkov]

>> Thanks for the reproducible test case.  It seems there is a bug somewhere in
>> pcomplete-completions-at-point.  Without icomplete:
>>
>> 1. emacs -q
>> 2. M-x eshell
>> 3. ls l<TAB>
>>
>> says "Complete, but not unique" that is not true.
>>
>> There is no such problem with shell that uses comint-completion-at-point
>> instead of pcomplete-completions-at-point.
>
> I have confirmed that 5416896d608 is the commit that introduces/reveals
> the problem, for my revised test case.

This means that 5416896d608 exposed a bug in pcomplete-completions-at-point.

bug#67661: 30.0.50; *Completions* has started popping up for icomplete-in-buffer

[Sean Whitton]

retitle 67661 30.0.50; *Completions* has started popping up for icomplete-in-buffer
thanks

Hello,

On Wed 20 Dec 2023 at 10:34am GMT, Sean Whitton wrote:

> Ah.  This is not the bug.  We may have been subtly miscommunicating.
> I am talking about completing the first argument to the command, not
> the 'ls' command itself.
>
> So for example:
>
> 1. emacs -q
> 2. (setopt icomplete-in-buffer t)
> 3. M-x icomplete-mode
> 4. M-x eshell
> 5. cd ~/src/emacs/
> 6. ls l<TAB>
>
> It takes a second <TAB> to have Emacs display leim, lib, lib-src, lisp etc..

I've pushed a fix for this problem, which was in pcomplete--entries.
Thanks again to Juri for pointing me to the Pcomplete machinery.

I'm not sure whether to close the bug or not, because there remains the
behavioural change for icomplete-in-buffer since Emacs 29.1.

-- 
Sean Whitton

bug#67661: 30.0.50; *Completions* has started popping up for icomplete-in-buffer

[Sean Whitton]

Hello,

On Fri 29 Dec 2023 at 05:47pm GMT, Sean Whitton wrote:

> I'm not sure whether to close the bug or not, because there remains the
> behavioural change for icomplete-in-buffer since Emacs 29.1.

I've found a work around for the behavioural change:

    (setopt completion-auto-help t)
    (advice-add 'completion-at-point :after #'minibuffer-hide-completions)

So maybe we should just add something explaining this to NEWS?

The default value of completion-auto-help is t, but I had it set to
`lazy'.
If someone wants the Emacs 29 behaviour back, they'll need to ensure
completion-auto-help is t, so I think we should mention it somewhere.
Essentially, completion-auto-help now affects both the *Completions*
buffer and icomplete-in-buffer's display.

-- 
Sean Whitton

bug#67661: 30.0.50; *Completions* has started popping up for icomplete-in-buffer

[Eli Zaretskii]

> From: Sean Whitton <spwhitton@spwhitton.name>
> Cc: 67661@debbugs.gnu.org
> Date: Fri, 29 Dec 2023 18:00:29 +0000
> 
> Hello,
> 
> On Fri 29 Dec 2023 at 05:47pm GMT, Sean Whitton wrote:
> 
> > I'm not sure whether to close the bug or not, because there remains the
> > behavioural change for icomplete-in-buffer since Emacs 29.1.
> 
> I've found a work around for the behavioural change:
> 
>     (setopt completion-auto-help t)
>     (advice-add 'completion-at-point :after #'minibuffer-hide-completions)
> 
> So maybe we should just add something explaining this to NEWS?

To which entry in Emacs 29's NEWS would this be related?

> The default value of completion-auto-help is t, but I had it set to
> `lazy'.
> If someone wants the Emacs 29 behaviour back, they'll need to ensure
> completion-auto-help is t, so I think we should mention it somewhere.
> Essentially, completion-auto-help now affects both the *Completions*
> buffer and icomplete-in-buffer's display.

If your change modifies the default behavior, that should be called
out in NEWS of Emacs 30.

bug#67661: 30.0.50; *Completions* has started popping up for icomplete-in-buffer

[Sean Whitton]

Hello,

On Fri 29 Dec 2023 at 09:27pm +02, Eli Zaretskii wrote:

> To which entry in Emacs 29's NEWS would this be related?

I'm talking about how Juri fixed icomplete-in-buffer for Emacs 29, and
how it's now working differently.  Juri's fix wasn't noted in NEWS.29,
so there isn't a relevant entry.

Let me lay out where I think things stand now that the confounding
Pcomplete bug is fixed.  Here are four reproductions:

,----
|
| 1. emacs -q
| 2. (setopt icomplete-in-buffer t
|            completion-auto-help 'lazy)
| 3. M-x icomplete-mode
|
|
| 4a. M-x eshell
| 5a. cd ~/src/emacs/<RET>
| 6a. ls<SPC>l<TAB>
|     - Emacs 29: in-buffer Icomplete appears
|     - Emacs 30: nothing happens
| 7a. <TAB> a second time
|     - Emacs 29: *Completions* pops up
|     - Emacs 30: in-buffer Icomplete appears & *Completions* pops up
|
|
| 4b. Insert text into *scratch*: (setopt icomplete-
| 5b. C-M-i
|     - Emacs 29: in-buffer Icomplete appears
|     - Emacs 30: nothing happens
| 6b. C-M-i a second time
|     - Emacs 29: accepts the completion
|     - Emacs 30: in-buffer Icomplete appears & *Completion* pops up
|
|----
|
| 1. emacs -q
| 2. (setopt icomplete-in-buffer t)
| 3. M-x icomplete-mode
|
|
| 4a. M-x eshell
| 5a. cd ~/src/emacs/<RET>
| 6a. ls<SPC>l<TAB>
|     - Emacs 29: in-buffer Icomplete appears
|     - Emacs 30: in-buffer Icomplete appears & *Completions* pops up
| 7a. <TAB> a second time
|     - Emacs 29: *Completions* pops up
|     - Emacs 30: n/a
|
|
| 4b. Insert text into *scratch*: (setopt icomplete-
| 5b. C-M-i
|     - Emacsen 29 & 30: in-buffer Icomplete appears & *Completions* pops up.
|----

We could see this as two incompatible changes to icomplete-in-buffer
since Emacs 29:

A. completion-auto-help now controls whether C-M-i or <TAB> must be
   typed twice to display in-buffer Icomplete.
   Previously, completion-auto-help affected only minibuffer completion.
   I must have been thinking of it this way when I set it to `lazy'.

B. *Completions* now always appears at the same time as the in-buffer
   Icomplete.  Previously, in some cases, it would appear only after
   typing C-M-i or <TAB> twice.

An Icomplete user like me is likely to want to respond to both these
changes.  The worst case is how nothing happens after a single <TAB> in
the first reproduction, such that typing two <TAB>s is always required.

Thus, I propose adding a NEWS.30 entry like this:

    There have been some changes which normalise some behaviour of
    in-buffer completion that affect users of icomplete-in-buffer.

    Firstly, completion-auto-help now governs icomplete-in-buffer,
    whereas previously it affected only minibuffer completion.  You may
    wish to review any existing customisation for completion-auto-help
    if in-buffer completion behaves in a way that surprises you.

    Secondly, the *Completions* buffer now always pops up at the same
    time that Icomplete displays its in-buffer completion.  If you would
    prefer to see only Icomplete's display, which is what you might be
    used to, you could use

        (advice-add 'completion-at-point :after #'minibuffer-hide-completions)

The reason I haven't gone ahead and added this already is that Juri has
suggested further changing icomplete-in-buffer's default behaviour.
I don't think that we should do that.

-- 
Sean Whitton

bug#67661: 30.0.50; *Completions* has started popping up for icomplete-in-buffer

[Eli Zaretskii]

> From: Sean Whitton <spwhitton@spwhitton.name>
> Cc: me@eshelyaron.com, 67661@debbugs.gnu.org
> Date: Fri, 29 Dec 2023 20:24:26 +0000
> 
> On Fri 29 Dec 2023 at 09:27pm +02, Eli Zaretskii wrote:
> 
> > To which entry in Emacs 29's NEWS would this be related?
> 
> I'm talking about how Juri fixed icomplete-in-buffer for Emacs 29, and
> how it's now working differently.  Juri's fix wasn't noted in NEWS.29,
> so there isn't a relevant entry.

I thought you were suggesting to add something to NEWS in Emacs 29.
If there's no suitable entry there, then I wonder what did you have in
mind for Emacs 29 in this area.

> Thus, I propose adding a NEWS.30 entry like this:
> 
>     There have been some changes which normalise some behaviour of
>     in-buffer completion that affect users of icomplete-in-buffer.
> 
>     Firstly, completion-auto-help now governs icomplete-in-buffer,
>     whereas previously it affected only minibuffer completion.  You may
>     wish to review any existing customisation for completion-auto-help
>     if in-buffer completion behaves in a way that surprises you.
> 
>     Secondly, the *Completions* buffer now always pops up at the same
>     time that Icomplete displays its in-buffer completion.  If you would
>     prefer to see only Icomplete's display, which is what you might be
>     used to, you could use
> 
>         (advice-add 'completion-at-point :after #'minibuffer-hide-completions)

AFAIU, this should also mention changes in Emacs 29 wrt previous
versions.

Also, the entry should in terms of user-facing behavior, not in terms
of how code works.  It should also be more concrete; phrases like "you
may wish to review existing customizations" are too vague to be
useful.

The last paragraph seems to indicate we lack some user option or a
variable to get back the old behavior, since using advice-add is less
friendly than flipping a variable.

(IMO, we are making too many backward-incompatible changes in this
area lately.  But that's me.)

bug#67661: 30.0.50; *Completions* has started popping up for icomplete-in-buffer

[Sean Whitton]

Hello,

On Sat 30 Dec 2023 at 08:30am +02, Eli Zaretskii wrote:

> AFAIU, this should also mention changes in Emacs 29 wrt previous
> versions.
>
> Also, the entry should in terms of user-facing behavior, not in terms
> of how code works.  It should also be more concrete; phrases like "you
> may wish to review existing customizations" are too vague to be
> useful.

Thank you for the feedback.  I've committed some documentation updates,
and would welcome any further revision.

> The last paragraph seems to indicate we lack some user option or a
> variable to get back the old behavior, since using advice-add is less
> friendly than flipping a variable.
>
> (IMO, we are making too many backward-incompatible changes in this
> area lately.  But that's me.)

I decided to go ahead and commit the documentation updates so that the
current state of play is written down.  Perhaps after further discussion
we'll want to make other changes.

-- 
Sean Whitton

bug#67661: 30.0.50; *Completions* has started popping up for icomplete-in-buffer

[Juri Linkov]

> I decided to go ahead and commit the documentation updates so that the
> current state of play is written down.  Perhaps after further discussion
> we'll want to make other changes.

I noticed in your changes that it's probably better to use the official name
"Icomplete mode":

  diff --git a/doc/emacs/buffers.texi b/doc/emacs/buffers.texi
  @@ -728,7 +728,7 @@ Icomplete
   @findex icomplete-mode
   @cindex Icomplete mode

  -  Icomplete global minor mode provides a convenient way to quickly select an
  +  Icomplete provides a convenient way to quickly select an
   element among the possible completions in a minibuffer.  When enabled, typing
   in the minibuffer continuously displays a list of possible completions that
   match the string you have typed.

i.e. "Icomplete mode provides a convenient way to..."

bug#67661: 30.0.50; *Completions* has started popping up for icomplete-in-buffer

[Sean Whitton]

Hello,

On Sat 30 Dec 2023 at 07:52pm +02, Juri Linkov wrote:

>> I decided to go ahead and commit the documentation updates so that the
>> current state of play is written down.  Perhaps after further discussion
>> we'll want to make other changes.
>
> I noticed in your changes that it's probably better to use the official name
> "Icomplete mode":
>
>   diff --git a/doc/emacs/buffers.texi b/doc/emacs/buffers.texi
>   @@ -728,7 +728,7 @@ Icomplete
>    @findex icomplete-mode
>    @cindex Icomplete mode
>
>   -  Icomplete global minor mode provides a convenient way to quickly select an
>   +  Icomplete provides a convenient way to quickly select an
>    element among the possible completions in a minibuffer.  When enabled, typing
>    in the minibuffer continuously displays a list of possible completions that
>    match the string you have typed.
>
> i.e. "Icomplete mode provides a convenient way to..."

Thanks, done.

-- 
Sean Whitton

bug#67661: 30.0.50; *Completions* has started popping up for icomplete-in-buffer

[Juri Linkov]

> | 4b. Insert text into *scratch*: (setopt icomplete-
> | 5b. C-M-i
> |     - Emacsen 29 & 30: in-buffer Icomplete appears & *Completions* pops up.

This is exactly how icomplete-in-buffer was intended to work.

>     Secondly, the *Completions* buffer now always pops up at the same
>     time that Icomplete displays its in-buffer completion.  If you would
>     prefer to see only Icomplete's display, which is what you might be
>     used to, you could use
>
>         (advice-add 'completion-at-point :after #'minibuffer-hide-completions)
>
> The reason I haven't gone ahead and added this already is that Juri has
> suggested further changing icomplete-in-buffer's default behaviour.
> I don't think that we should do that.

I suggested adding a new option that would disable popping up *Completions*.
This is preferable to instructing users how to use advice-add.  But this
might be not quite straightforward to implement.

bug#67661: 30.0.50; *Completions* has started popping up for icomplete-in-buffer

[Sean Whitton]

Hello,

On Sat 30 Dec 2023 at 07:50pm +02, Juri Linkov wrote:

>> | 4b. Insert text into *scratch*: (setopt icomplete-
>> | 5b. C-M-i
>> |     - Emacsen 29 & 30: in-buffer Icomplete appears & *Completions* pops up.
>
> This is exactly how icomplete-in-buffer was intended to work.

Right, yeah, I now understand that.

In a previous message you said you think that icomplete-in-buffer is
unfinished, and you'd like to consider further changes to how it works.
Is that something you're still considering, or are you setting that
aside for the time being?

I ask because if you are happy with how things are now, we could close
this bug.

>>     Secondly, the *Completions* buffer now always pops up at the same
>>     time that Icomplete displays its in-buffer completion.  If you would
>>     prefer to see only Icomplete's display, which is what you might be
>>     used to, you could use
>>
>>         (advice-add 'completion-at-point :after #'minibuffer-hide-completions)
>>
>> The reason I haven't gone ahead and added this already is that Juri has
>> suggested further changing icomplete-in-buffer's default behaviour.
>> I don't think that we should do that.
>
> I suggested adding a new option that would disable popping up *Completions*.
> This is preferable to instructing users how to use advice-add.  But this
> might be not quite straightforward to implement.

Yes, that would be preferable, if someone wants to work on it at some point.

-- 
Sean Whitton

bug#67661: 30.0.50; *Completions* has started popping up for icomplete-in-buffer

[Juri Linkov]

close 67661 30.0.50
thanks

> In a previous message you said you think that icomplete-in-buffer is
> unfinished, and you'd like to consider further changes to how it works.
> Is that something you're still considering, or are you setting that
> aside for the time being?
>
> I ask because if you are happy with how things are now, we could close
> this bug.

Right, let's close this bug.  If someone wants to implement a new option,
it's easy to open a new feature request.

bug#67661: 30.0.50; *Completions* has started popping up for icomplete-in-buffer

[john muhl via Bug reports for GNU Emacs, the Swiss army knife of text editors]

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

Sean Whitton <spwhitton@spwhitton.name> writes:

I forgot the CCs. Sorry Sean for the double email.

> Hello,
>
> On Fri 29 Dec 2023 at 05:47pm GMT, Sean Whitton wrote:
>
>> I'm not sure whether to close the bug or not, because there remains the
>> behavioural change for icomplete-in-buffer since Emacs 29.1.
>
> I've found a work around for the behavioural change:
>
>     (setopt completion-auto-help t)
>     (advice-add 'completion-at-point :after #'minibuffer-hide-completions)
>
> So maybe we should just add something explaining this to NEWS?
>
> The default value of completion-auto-help is t, but I had it set to
> `lazy'.
> If someone wants the Emacs 29 behaviour back, they'll need to ensure
> completion-auto-help is t, so I think we should mention it somewhere.
> Essentially, completion-auto-help now affects both the *Completions*
> buffer and icomplete-in-buffer's display.

This commit (d7ff14fcba6) caused an eshell test to start
failing. It seems like the test was written to account for the
above mentioned bug in pcomplete but wasn’t sure. Attached is
the test output and the change in the test to fix it.


[-- Attachment #2: em-cmpl-tests.log --]
[-- Type: text/plain, Size: 4900 bytes --]

Running 27 tests (2024-01-09 20:53:56-0600, selector `(not (or (tag :expensive-test) (tag :unstable) (tag :nativecomp)))')
Loading em-alias...
Loading em-banner...
Loading em-basic...
Loading em-extpipe...
Loading em-glob...
Loading em-ls...
Loading em-pred...
Loading em-prompt...
Loading em-script...
Loading em-term...
   passed   1/27  em-cmpl-test/command-completion (0.031879 sec)
   passed   2/27  em-cmpl-test/file-completion/after-list (0.002264 sec)
   passed   3/27  em-cmpl-test/file-completion/glob (0.001335 sec)
Test em-cmpl-test/file-completion/non-unique backtrace:
  signal(ert-test-failed (((should (looking-at "Complete, but not uniq
  ert-fail(((should (looking-at "Complete, but not unique")) :form (lo
  (if (unwind-protect (setq value-67 (apply fn-65 args-66)) (setq form
  (let (form-description-69) (if (unwind-protect (setq value-67 (apply
  (let ((value-67 'ert-form-evaluation-aborted-68)) (let (form-descrip
  (let* ((fn-65 #'looking-at) (args-66 (condition-case err (list "Comp
  (save-excursion (goto-char (point-max)) (forward-line -1) (let* ((fn
  (save-current-buffer (set-buffer (messages-buffer)) (save-excursion 
  (progn (write-region nil nil (expand-file-name "file.txt")) (write-r
  (unwind-protect (progn (write-region nil nil (expand-file-name "file
  (let* ((coding-system-for-write nil) (temp-file (file-name-as-direct
  (save-current-buffer (set-buffer eshell-buffer) (let* ((coding-syste
  (unwind-protect (save-current-buffer (set-buffer eshell-buffer) (let
  (let* ((process-environment (cons "HISTFILE" process-environment)) (
  (progn (let* ((process-environment (cons "HISTFILE" process-environm
  (unwind-protect (progn (let* ((process-environment (cons "HISTFILE" 
  (let* ((coding-system-for-write nil) (temp-file (file-name-as-direct
  (save-current-buffer (let* ((coding-system-for-write nil) (temp-file
  (closure (t) nil (save-current-buffer (let* ((coding-system-for-writ
  #f(compiled-function () #<bytecode 0x13fdb98997904ea3>)()
  handler-bind-1(#f(compiled-function () #<bytecode 0x13fdb98997904ea3
  ert--run-test-internal(#s(ert--test-execution-info :test #s(ert-test
  ert-run-test(#s(ert-test :name em-cmpl-test/file-completion/non-uniq
  ert-run-or-rerun-test(#s(ert--stats :selector ... :tests ... :test-m
  ert-run-tests((not (or (tag :expensive-test) (tag :unstable) (tag :n
  ert-run-tests-batch((not (or (tag :expensive-test) (tag :unstable) (
  ert-run-tests-batch-and-exit((not (or (tag :expensive-test) (tag :un
  eval((ert-run-tests-batch-and-exit '(not (or (tag :expensive-test) (
  command-line-1(("-L" ":." "-l" "ert" "-l" "lisp/eshell/em-cmpl-tests
  command-line()
  normal-top-level()
Test em-cmpl-test/file-completion/non-unique condition:
    (ert-test-failed
     ((should (looking-at "Complete, but not unique")) :form
      (looking-at "Complete, but not unique") :value nil))
   FAILED   4/27  em-cmpl-test/file-completion/non-unique (0.002395 sec) at lisp/eshell/em-cmpl-tests.el:172
   passed   5/27  em-cmpl-test/file-completion/unique (0.002452 sec)
   passed   6/27  em-cmpl-test/lisp-function-completion (0.010890 sec)
   passed   7/27  em-cmpl-test/lisp-symbol-completion (0.007067 sec)
   passed   8/27  em-cmpl-test/parse-arguments/multiple-dots (0.000700 sec)
   passed   9/27  em-cmpl-test/parse-arguments/pipeline (0.000633 sec)
   passed  10/27  em-cmpl-test/parse-arguments/unevaluated-inner-subcommand (0.000742 sec)
   passed  11/27  em-cmpl-test/parse-arguments/unevaluated-lisp-form (0.001168 sec)
   passed  12/27  em-cmpl-test/parse-arguments/unevaluated-subcommand (0.001241 sec)
   passed  13/27  em-cmpl-test/parse-arguments/variable/list (0.000637 sec)
   passed  14/27  em-cmpl-test/parse-arguments/variable/nil (0.000621 sec)
   passed  15/27  em-cmpl-test/parse-arguments/variable/numeric (0.000599 sec)
   passed  16/27  em-cmpl-test/parse-arguments/variable/splice (0.000613 sec)
   passed  17/27  em-cmpl-test/quoted-variable-ref-completion (0.010336 sec)
   passed  18/27  em-cmpl-test/special-ref-completion/buffer (0.004122 sec)
   passed  19/27  em-cmpl-test/special-ref-completion/implicit-buffer (0.002344 sec)
   passed  20/27  em-cmpl-test/special-ref-completion/marker (0.013179 sec)
   passed  21/27  em-cmpl-test/special-ref-completion/type (0.003534 sec)
   passed  22/27  em-cmpl-test/subcommand-completion (0.027562 sec)
   passed  23/27  em-cmpl-test/user-ref-completion (0.001779 sec)
   passed  24/27  em-cmpl-test/variable-assign-completion (0.001592 sec)
   passed  25/27  em-cmpl-test/variable-assign-completion/non-assignment (0.002060 sec)
   passed  26/27  em-cmpl-test/variable-ref-completion (0.006356 sec)
   passed  27/27  em-cmpl-test/variable-ref-completion/directory (0.010075 sec)

Ran 27 tests, 26 results as expected, 1 unexpected (2024-01-09 20:53:56-0600, 0.257441 sec)

1 unexpected results:
   FAILED  em-cmpl-test/file-completion/non-unique


[-- Attachment #3: Type: text/plain, Size: 459 bytes --]


--- a/test/lisp/eshell/em-cmpl-tests.el
+++ b/test/lisp/eshell/em-cmpl-tests.el
@@ -186,7 +186,7 @@ em-cmpl-test/file-completion/non-unique
        (save-excursion
          (goto-char (point-max))
          (forward-line -1)
-         (should (looking-at "Complete, but not unique")))))))
+         (should (looking-at "Making completion list...")))))))
 
 (ert-deftest em-cmpl-test/file-completion/glob ()
   "Test completion of file names using a glob."

bug#67661: 30.0.50; *Completions* has started popping up for icomplete-in-buffer

[Sean Whitton]

Hello,

On Tue 09 Jan 2024 at 09:12pm -06, john muhl wrote:

> This commit (d7ff14fcba6) caused an eshell test to start
> failing. It seems like the test was written to account for the
> above mentioned bug in pcomplete but wasn’t sure. Attached is
> the test output and the change in the test to fix it.
>
>
>
> --- a/test/lisp/eshell/em-cmpl-tests.el
> +++ b/test/lisp/eshell/em-cmpl-tests.el
> @@ -186,7 +186,7 @@ em-cmpl-test/file-completion/non-unique
>         (save-excursion
>           (goto-char (point-max))
>           (forward-line -1)
> -         (should (looking-at "Complete, but not unique")))))))
> +         (should (looking-at "Making completion list...")))))))
>
>  (ert-deftest em-cmpl-test/file-completion/glob ()
>    "Test completion of file names using a glob."

Jim, does this seem reasonable?

-- 
Sean Whitton

bug#67661: 30.0.50; *Completions* has started popping up for icomplete-in-buffer

[Jim Porter]

On 1/10/2024 9:55 AM, Sean Whitton wrote:
>> --- a/test/lisp/eshell/em-cmpl-tests.el
>> +++ b/test/lisp/eshell/em-cmpl-tests.el
>> @@ -186,7 +186,7 @@ em-cmpl-test/file-completion/non-unique
>>          (save-excursion
>>            (goto-char (point-max))
>>            (forward-line -1)
>> -         (should (looking-at "Complete, but not unique")))))))
>> +         (should (looking-at "Making completion list...")))))))
>>
>>   (ert-deftest em-cmpl-test/file-completion/glob ()
>>     "Test completion of file names using a glob."
> 
> Jim, does this seem reasonable?

Sorry, I missed this the first time around (I've got a lot of other 
stuff I'm trying to balance at the moment). I think this would fix the 
issue, but I've instead pushed 5f5faad2497 which solves this in a 
more-direct way by checking whether the *Completions* buffer is visible. 
That's what the test is really trying to test anyway.

bug#67661: 30.0.50; *Completions* has started popping up for icomplete-in-buffer

[Eli Zaretskii]

> From: Eshel Yaron <me@eshelyaron.com>
> Cc: 67661@debbugs.gnu.org,  juri@linkov.net,  67001@debbugs.gnu.org,
>   spwhitton@spwhitton.name
> Date: Sat, 09 Dec 2023 17:03:57 +0100
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > That's not what I see in Emacs 29.  There' the first TAB shows only
> > the in-buffer completions, and the second TAB pops up the
> > *Completions* buffer (without removing the in-buffer completions).
> 
> Did you try with "l" before point instead of "ls" as I suggested?

No, because Sean's recipe clearly said "ls<TAB>".

bug#67661: 30.0.50; *Completions* has started popping up for icomplete-in-buffer

[Juri Linkov]

> 1. emacs -q
> 2. (setopt icomplete-in-buffer t)
> 3. M-x icomplete-mode
> 4. M-x eshell
> 5. try to tab-complete something where there is more than one possible
>    completion, e.g. ls<TAB> in a directory with many files.
>
> Previously you would get the icomplete in buffer completion.
> Now, additionally, *Completions* pops up, but it doesn't make sense to
> have both.

It's possible to hide *Completions* when icomplete-mode is enabled,
but I'm not sure if everyone will like this.  For example,
I'm using both icomplete-mode and the *Completions* buffer
at the same time in the minibuffer.  And in a regular buffer
we should keep for users the ability to pop up *Completions*
in addition to in-buffer completions.

Maybe the best solution would be to use something like
in completion-preview-mode where you can use in-buffer
completions and still be able to type M-C-i to pop up
the *Completions* buffer.

bug#67661: 30.0.50; *Completions* has started popping up for icomplete-in-buffer

[Sean Whitton]

Hello,

On Thu 07 Dec 2023 at 07:28pm +02, Juri Linkov wrote:

>> 1. emacs -q
>> 2. (setopt icomplete-in-buffer t)
>> 3. M-x icomplete-mode
>> 4. M-x eshell
>> 5. try to tab-complete something where there is more than one possible
>>    completion, e.g. ls<TAB> in a directory with many files.
>>
>> Previously you would get the icomplete in buffer completion.
>> Now, additionally, *Completions* pops up, but it doesn't make sense to
>> have both.
>
> It's possible to hide *Completions* when icomplete-mode is enabled,
> but I'm not sure if everyone will like this.  For example,
> I'm using both icomplete-mode and the *Completions* buffer
> at the same time in the minibuffer.  And in a regular buffer
> we should keep for users the ability to pop up *Completions*
> in addition to in-buffer completions.
>
> Maybe the best solution would be to use something like
> in completion-preview-mode where you can use in-buffer
> completions and still be able to type M-C-i to pop up
> the *Completions* buffer.

This is a regression though, right?  It didn't use to pop up.

-- 
Sean Whitton

bug#67661: 30.0.50; *Completions* has started popping up for icomplete-in-buffer

[Eli Zaretskii]

> Cc: 67661@debbugs.gnu.org
> From: Sean Whitton <spwhitton@spwhitton.name>
> Date: Thu, 07 Dec 2023 22:04:18 +0000
> 
> Hello,
> 
> On Thu 07 Dec 2023 at 07:28pm +02, Juri Linkov wrote:
> 
> >> 1. emacs -q
> >> 2. (setopt icomplete-in-buffer t)
> >> 3. M-x icomplete-mode
> >> 4. M-x eshell
> >> 5. try to tab-complete something where there is more than one possible
> >>    completion, e.g. ls<TAB> in a directory with many files.
> >>
> >> Previously you would get the icomplete in buffer completion.
> >> Now, additionally, *Completions* pops up, but it doesn't make sense to
> >> have both.
> >
> > It's possible to hide *Completions* when icomplete-mode is enabled,
> > but I'm not sure if everyone will like this.  For example,
> > I'm using both icomplete-mode and the *Completions* buffer
> > at the same time in the minibuffer.  And in a regular buffer
> > we should keep for users the ability to pop up *Completions*
> > in addition to in-buffer completions.
> >
> > Maybe the best solution would be to use something like
> > in completion-preview-mode where you can use in-buffer
> > completions and still be able to type M-C-i to pop up
> > the *Completions* buffer.
> 
> This is a regression though, right?  It didn't use to pop up.

Once again: it did.  The *Completions* buffer always popped up the
second time you type TAB.  The problem here is that the first TAB
doesn't show the in-buffer completion. _That_ is the regression we
should try fixing.

bug#67661: 30.0.50; *Completions* has started popping up for icomplete-in-buffer

[Sean Whitton]

Hello,

On Fri 08 Dec 2023 at 08:28am +02, Eli Zaretskii wrote:

>> Cc: 67661@debbugs.gnu.org
>> From: Sean Whitton <spwhitton@spwhitton.name>
>> Date: Thu, 07 Dec 2023 22:04:18 +0000
>>
>> Hello,
>>
>> On Thu 07 Dec 2023 at 07:28pm +02, Juri Linkov wrote:
>>
>> >> 1. emacs -q
>> >> 2. (setopt icomplete-in-buffer t)
>> >> 3. M-x icomplete-mode
>> >> 4. M-x eshell
>> >> 5. try to tab-complete something where there is more than one possible
>> >>    completion, e.g. ls<TAB> in a directory with many files.
>> >>
>> >> Previously you would get the icomplete in buffer completion.
>> >> Now, additionally, *Completions* pops up, but it doesn't make sense to
>> >> have both.
>> >
>> > It's possible to hide *Completions* when icomplete-mode is enabled,
>> > but I'm not sure if everyone will like this.  For example,
>> > I'm using both icomplete-mode and the *Completions* buffer
>> > at the same time in the minibuffer.  And in a regular buffer
>> > we should keep for users the ability to pop up *Completions*
>> > in addition to in-buffer completions.
>> >
>> > Maybe the best solution would be to use something like
>> > in completion-preview-mode where you can use in-buffer
>> > completions and still be able to type M-C-i to pop up
>> > the *Completions* buffer.
>>
>> This is a regression though, right?  It didn't use to pop up.
>
> Once again: it did.  The *Completions* buffer always popped up the
> second time you type TAB.  The problem here is that the first TAB
> doesn't show the in-buffer completion. _That_ is the regression we
> should try fixing.

Right, that's what I meant.

-- 
Sean Whitton