New multi-command facility displays in the wrong echo area.

New multi-command facility displays in the wrong echo area.

[Alan Mackenzie]

Hello, Emacs.

With a recent master:

(i) In a GUI environment, create two frames, each displaying a buffer.
(ii) In frame F1, do C-x b `switch-to-buffer', but don't type anything
more.
(iii) Move to frame F2, and start an isearch with C-s some-text.

Although currently in F2, the isearch's pattern is displayed in the echo
area for F1.  This is wrong.

It's wrong because F1's echo area isn't necessarily visible.  It may
have been moved off the screen by GUI facilities.  The effect is then
missing text in the echo area.

Instead do the same on a TTY, where frame switching commands have been
bound to keys.  The effect of the missing echo area text is more
pronounced, since there is no way of ever seeing it - on pressing the
key to return to F1, the command in F2 is cancelled along with its echo
text.

I wasn't previously aware of this multiple command facility.  I think
the above should be fixed, somehow.

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: New multi-command facility displays in the wrong echo area.

[Stefan Monnier]

> (i) In a GUI environment, create two frames, each displaying a buffer.
> (ii) In frame F1, do C-x b `switch-to-buffer', but don't type anything
> more.
> (iii) Move to frame F2, and start an isearch with C-s some-text.
>
> Although currently in F2, the isearch's pattern is displayed in the echo
> area for F1.  This is wrong.

FWIW, this behavior has been with us at least since Emacs-21.


        Stefan

Re: New multi-command facility displays in the wrong echo area.

[Alan Mackenzie]

Hello, Stefan.

On Fri, Oct 09, 2020 at 15:47:15 -0400, Stefan Monnier wrote:
> > (i) In a GUI environment, create two frames, each displaying a buffer.
> > (ii) In frame F1, do C-x b `switch-to-buffer', but don't type anything
> > more.
> > (iii) Move to frame F2, and start an isearch with C-s some-text.
> >
> > Although currently in F2, the isearch's pattern is displayed in the echo
> > area for F1.  This is wrong.

> FWIW, this behavior has been with us at least since Emacs-21.

Yes.  At least, it's present in Emacs 27.1.  How come I've never noticed
it before?

This morning, it was C-x C-s which failed to give me any output,
although I was expecting to see "(No files need saving)".

I still say it's wrong, but I suppose if I want it fixed, I'll have to
fix it myself.

>         Stefan

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: New multi-command facility displays in the wrong echo area.

[Gregory Heytings via Emacs development discussions.]

Hi Stefan,

>> (i) In a GUI environment, create two frames, each displaying a buffer.
>> (ii) In frame F1, do C-x b `switch-to-buffer', but don't type anything more.
>> (iii) Move to frame F2, and start an isearch with C-s some-text.
>>
>> Although currently in F2, the isearch's pattern is displayed in the 
>> echo area for F1.  This is wrong.
>
> FWIW, this behavior has been with us at least since Emacs-21.
>

I fear that's not correct.  I don't see this behavior in Emacs 21 to 26 
(inclusive), it is new in Emacs 27.1.  More precisely, it is because the 
new variable set-message-function has the default value 
set-minibuffer-message.  To restore the previous default behavior:

(setq set-message-function nil)

Re: New multi-command facility displays in the wrong echo area.

[Gregory Heytings via Emacs development discussions.]

Hi Stefan,

>>> (i) In a GUI environment, create two frames, each displaying a buffer.
>>> (ii) In frame F1, do C-x b `switch-to-buffer', but don't type anything more.
>>> (iii) Move to frame F2, and start an isearch with C-s some-text.
>>> 
>>> Although currently in F2, the isearch's pattern is displayed in the 
>>> echo area for F1.  This is wrong.
>> 
>> FWIW, this behavior has been with us at least since Emacs-21.
>> 
>
> I fear that's not correct.  I don't see this behavior in Emacs 21 to 26 
> (inclusive), it is new in Emacs 27.1.  More precisely, it is because the 
> new variable set-message-function has the default value 
> set-minibuffer-message. To restore the previous default behavior:
>
> (setq set-message-function nil)
>

IMO this could/should be fixed in set-minibuffer-message, by checking that 
the active minibuffer is on the same frame:

(when (and (not noninteractive)
            (window-live-p (active-minibuffer-window))
            (eq (window-frame) (window-frame (active-minibuffer-window))))

Re: New multi-command facility displays in the wrong echo area.

[Stefan Monnier]

> I still say it's wrong, but I suppose if I want it fixed, I'll have to
> fix it myself.

Just to clarify: I didn't mean to say that "it's been that way for so
long that it must be right", but just pointing out that it's not
a new problem.

I have no idea how easy it is to address.
Tho I think there is one way to avoid the problem: make isearch signal
an error in that case.  You'd get an error if isearch used a minibuffer
(because it'd be a recursive minibuffer which are disallowed by
default), and whether isearch uses a minibuffer or not is (to a large
extent) an internal implementation detail.


        Stefan

RE: New multi-command facility displays in the wrong echo area.

[Drew Adams]

> make isearch signal
> an error in that case.  You'd get an error if isearch used a minibuffer
> (because it'd be a recursive minibuffer which are disallowed by
> default), and whether isearch uses a minibuffer or not is (to a large
> extent) an internal implementation detail.

Not sure it's the same thing, but if you're also saying
that it should be an error to use a recursive _edit_
during Isearch then I disagree with that.

I have Isearch keys that open a recursive edit.

(And a recursive edit could use a minibuffer and even
recursive minibuffers.)

Re: New multi-command facility displays in the wrong echo area.

[Eli Zaretskii]

> Date: Fri, 9 Oct 2020 20:38:10 +0000
> From: Alan Mackenzie <acm@muc.de>
> Cc: emacs-devel@gnu.org
> 
> > FWIW, this behavior has been with us at least since Emacs-21.
> 
> Yes.  At least, it's present in Emacs 27.1.  How come I've never noticed
> it before?
> 
> This morning, it was C-x C-s which failed to give me any output,
> although I was expecting to see "(No files need saving)".
> 
> I still say it's wrong, but I suppose if I want it fixed, I'll have to
> fix it myself.

It is quite unusual to leave an active minibuffer and switch to
another frame to start an Isearch.

If you want to fix that, let's please first talk about what kind if
fix are you looking for.  Do you intend to leave the active minibuffer
on the original frame, and use the other frame for Isearch?  Note that
Isearch also uses the minibuffer.

Re: New multi-command facility displays in the wrong echo area.

[Alan Mackenzie]

Hello, Gregory.

On Fri, Oct 09, 2020 at 21:48:49 +0000, Gregory Heytings wrote:

> Hi Stefan,

> >>> (i) In a GUI environment, create two frames, each displaying a buffer.
> >>> (ii) In frame F1, do C-x b `switch-to-buffer', but don't type anything more.
> >>> (iii) Move to frame F2, and start an isearch with C-s some-text.

> >>> Although currently in F2, the isearch's pattern is displayed in the 
> >>> echo area for F1.  This is wrong.

> >> FWIW, this behavior has been with us at least since Emacs-21.


> > I fear that's not correct.  I don't see this behavior in Emacs 21 to 26 
> > (inclusive), it is new in Emacs 27.1.  More precisely, it is because the 
> > new variable set-message-function has the default value 
> > set-minibuffer-message. To restore the previous default behavior:

> > (setq set-message-function nil)


> IMO this could/should be fixed in set-minibuffer-message, by checking that 
> the active minibuffer is on the same frame:

> (when (and (not noninteractive)
>             (window-live-p (active-minibuffer-window))
>             (eq (window-frame) (window-frame (active-minibuffer-window)))

Thanks!  I've just tried this out, and it appears to work well.

In particular, in the scenario I outlined, on a TTY, the echo area for
frame F2 is used when F2 is the current frame, even if there is a
minibuffer active in F1.

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: New multi-command facility displays in the wrong echo area.

[Alan Mackenzie]

Hello, Eli.

On Sat, Oct 10, 2020 at 09:52:33 +0300, Eli Zaretskii wrote:
> > Date: Fri, 9 Oct 2020 20:38:10 +0000
> > From: Alan Mackenzie <acm@muc.de>
> > Cc: emacs-devel@gnu.org

> > > FWIW, this behavior has been with us at least since Emacs-21.

> > Yes.  At least, it's present in Emacs 27.1.  How come I've never noticed
> > it before?

> > This morning, it was C-x C-s which failed to give me any output,
> > although I was expecting to see "(No files need saving)".

> > I still say it's wrong, but I suppose if I want it fixed, I'll have to
> > fix it myself.

> It is quite unusual to leave an active minibuffer and switch to
> another frame to start an Isearch.

It's rather something I tend to do by accident.  I start a command in
frame F1 which uses the minibuffer, I swap to F2 to look for the text I
want to enter in F1, then sometimes forget I've got the command in F1
still active.

> If you want to fix that, let's please first talk about what kind if
> fix are you looking for.

Above all, I want the command in F2 to use the echo area of F2, not that
of F1 (which in my TTY setup is not visible).

> Do you intend to leave the active minibuffer on the original frame, and
> use the other frame for Isearch?  Note that Isearch also uses the
> minibuffer.

I'm not understanding that, properly.  When I enter characters into
isearch in F2, this doesn't throw an error when the F1 minibuffer is
still active.  Is isearch perhaps just using the echo area, here?

Anyway, I tried the suggestion of Gregory Heytings from yesterday evening
at 21:48:49 +0000.  He put an extra condition into
set-minibuffer-message, so that it only does its thing when the current
frame is also the minibuffer's frame.  It appears to work well.

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: New multi-command facility displays in the wrong echo area.

[Eli Zaretskii]

> Date: Sat, 10 Oct 2020 10:32:33 +0000
> From: Alan Mackenzie <acm@muc.de>
> Cc: monnier@iro.umontreal.ca, emacs-devel@gnu.org
> 
> > Do you intend to leave the active minibuffer on the original frame, and
> > use the other frame for Isearch?  Note that Isearch also uses the
> > minibuffer.
> 
> I'm not understanding that, properly.  When I enter characters into
> isearch in F2, this doesn't throw an error when the F1 minibuffer is
> still active.  Is isearch perhaps just using the echo area, here?
> 
> Anyway, I tried the suggestion of Gregory Heytings from yesterday evening
> at 21:48:49 +0000.  He put an extra condition into
> set-minibuffer-message, so that it only does its thing when the current
> frame is also the minibuffer's frame.  It appears to work well.

Does that work if you set tty-menu-open-use-tmm non-nil, then press
f10 while the I-search: prompt is active?  This is one case where
Isearch reads from the minibuffer.

Another, perhaps more important, use case is when you type "M-s e"
during Isearch: that enters the minibuffer to let you edit the search
string.  Yet another similar use case is when you type "C-x 8 RET"
during Isearch: that reads the character's name/codepoint from the
minibuffer.

These are the use cases I had in mind when I asked about Isearch using
the minibuffer.

Re: New multi-command facility displays in the wrong echo area.

[Gregory Heytings via Emacs development discussions.]

>
> Does that work if you set tty-menu-open-use-tmm non-nil, then press f10 
> while the I-search: prompt is active?  This is one case where Isearch 
> reads from the minibuffer.
>

This gives "Command attempted to use minibuffer while in minibuffer", with 
earlier and current Emacs versions, with or without the bugfix.

>
> Another, perhaps more important, use case is when you type "M-s e" 
> during Isearch: that enters the minibuffer to let you edit the search 
> string.
>

This gives "Command attempted to use minibuffer while in minibuffer", with 
earlier and current Emacs versions, with or without the bugfix.

>
> Yet another similar use case is when you type "C-x 8 RET" during 
> Isearch: that reads the character's name/codepoint from the minibuffer.
>

This one works (the active minibuffer is moved to the current frame), with 
earlier and current Emacs versions, with or without the bugfix.

In short: these three use cases are orthogonal to the problem at hand, 
they are not improved or worsened by the bugfix.

Re: New multi-command facility displays in the wrong echo area.

[Alan Mackenzie]

Hello, Eli.

On Sat, Oct 10, 2020 at 14:13:32 +0300, Eli Zaretskii wrote:
> > Date: Sat, 10 Oct 2020 10:32:33 +0000
> > From: Alan Mackenzie <acm@muc.de>
> > Cc: monnier@iro.umontreal.ca, emacs-devel@gnu.org

> > > Do you intend to leave the active minibuffer on the original frame, and
> > > use the other frame for Isearch?  Note that Isearch also uses the
> > > minibuffer.

> > I'm not understanding that, properly.  When I enter characters into
> > isearch in F2, this doesn't throw an error when the F1 minibuffer is
> > still active.  Is isearch perhaps just using the echo area, here?

> > Anyway, I tried the suggestion of Gregory Heytings from yesterday evening
> > at 21:48:49 +0000.  He put an extra condition into
> > set-minibuffer-message, so that it only does its thing when the current
> > frame is also the minibuffer's frame.  It appears to work well.

> Does that work if you set tty-menu-open-use-tmm non-nil, then press
> f10 while the I-search: prompt is active?  This is one case where
> Isearch reads from the minibuffer.

Ah, yes.  Sorry for being a bit dim, there.

When just the isearch is active, f10 does indeed work.  When,
additionally, C-x b is active on another frame, it throws the error
"Command attempted to use minibuffer while in minibuffer".  This is
surely correct.  However, the isearch highlighting doesn't get removed in
this error case.  That is incorrect.

> Another, perhaps more important, use case is when you type "M-s e"
> during Isearch: that enters the minibuffer to let you edit the search
> string.

This works fine.  Without the C-x b in another frame, it just works.
With the C-x b in the other frame it throws the "Command ... minibuffer"
error and removes the highlighting.

> Yet another similar use case is when you type "C-x 8 RET" during
> Isearch: that reads the character's name/codepoint from the minibuffer.

This goes wrong.  With C-x b active on frame F1, move to F2, start an
isearch, C-x 8 RET, use TAB completion to select a character and RET.
This displays

    Switch to buffer (default xdisp.c):  [Failing I-search: su�] 

on F2.  On terminating the isearch and completing the C-x b action in
F2's minibufer, the buffer switch has worked in frame F1.

At a guess, C-x 8 RET uses a recursive edit, but fails to bind the
variable holding the minibuffer frame.  It changes this variable, but on
exiting the recursive edit, fails to restore it.  Or something like that.

> These are the use cases I had in mind when I asked about Isearch using
> the minibuffer.

OK.

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: New multi-command facility displays in the wrong echo area.

[Eli Zaretskii]

> Date: Sat, 10 Oct 2020 12:44:46 +0000
> Cc: monnier@iro.umontreal.ca, emacs-devel@gnu.org
> From: Alan Mackenzie <acm@muc.de>
> 
> When just the isearch is active, f10 does indeed work.  When,
> additionally, C-x b is active on another frame, it throws the error
> "Command attempted to use minibuffer while in minibuffer".  This is
> surely correct.  However, the isearch highlighting doesn't get removed in
> this error case.  That is incorrect.

Is this different from what happened in versions of Emacs before 27.1?

> > Another, perhaps more important, use case is when you type "M-s e"
> > during Isearch: that enters the minibuffer to let you edit the search
> > string.
> 
> This works fine.  Without the C-x b in another frame, it just works.
> With the C-x b in the other frame it throws the "Command ... minibuffer"
> error and removes the highlighting.
> 
> > Yet another similar use case is when you type "C-x 8 RET" during
> > Isearch: that reads the character's name/codepoint from the minibuffer.
> 
> This goes wrong.  With C-x b active on frame F1, move to F2, start an
> isearch, C-x 8 RET, use TAB completion to select a character and RET.
> This displays
> 
>     Switch to buffer (default xdisp.c):  [Failing I-search: su�] 
> 
> on F2.  On terminating the isearch and completing the C-x b action in
> F2's minibufer, the buffer switch has worked in frame F1.

Same question here.

If Gregory's change doesn't make things worse than they were before
Emacs 27.1, then I think we should install it.  In the emacs-27
branch, please.

Thanks.

Re: New multi-command facility displays in the wrong echo area.

[Eli Zaretskii]

> Date: Sat, 10 Oct 2020 15:50:07 +0300
> From: Eli Zaretskii <eliz@gnu.org>
> Cc: monnier@iro.umontreal.ca, emacs-devel@gnu.org
> 
> If Gregory's change doesn't make things worse than they were before
> Emacs 27.1, then I think we should install it.  In the emacs-27
> branch, please.

Btw, to make sure the change is not for the worse, those same
experiments should be repeated with enable-recursive-minibuffers set
non-nil.

Thanks.

Re: New multi-command facility displays in the wrong echo area.

[Gregory Heytings via Emacs development discussions.]

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


> When just the isearch is active, f10 does indeed work.  When, 
> additionally, C-x b is active on another frame, it throws the error 
> "Command attempted to use minibuffer while in minibuffer".  This is 
> surely correct.  However, the isearch highlighting doesn't get removed 
> in this error case.  That is incorrect.
>

It's not removed because isearch is not aborted.  You can continue your 
isearch or abort it with C-g.  That's a difference indeed: in earlier 
Emacsen isearch would have aborted in this case.  Which one is better is 
not clear to me.

>> Yet another similar use case is when you type "C-x 8 RET" during 
>> Isearch: that reads the character's name/codepoint from the minibuffer.
>
> This goes wrong.  With C-x b active on frame F1, move to F2, start an 
> isearch, C-x 8 RET, use TAB completion to select a character and RET. 
> This displays
>
>    Switch to buffer (default xdisp.c):  [Failing I-search: su�]
>
> on F2.  On terminating the isearch and completing the C-x b action in 
> F2's minibufer, the buffer switch has worked in frame F1.
>

It doesn't go wrong, it has moved the minibuffer from frame F1 to frame 
F2.

Re: New multi-command facility displays in the wrong echo area.

[Stefan Monnier]

>> (when (and (not noninteractive)
>>             (window-live-p (active-minibuffer-window))
>>             (eq (window-frame) (window-frame (active-minibuffer-window)))
>
> Thanks!  I've just tried this out, and it appears to work well.
>
> In particular, in the scenario I outlined, on a TTY, the echo area for
> frame F2 is used when F2 is the current frame, even if there is a
> minibuffer active in F1.

Indeed.  It looks like I misremembered!
This looks like a plain bug fix that should be on `emacs-27`.
Thanks,


        Stefan

Re: New multi-command facility displays in the wrong echo area.

[Alan Mackenzie]

Hello, Gregory.

On Sat, Oct 10, 2020 at 13:03:49 +0000, Gregory Heytings wrote:

> > When just the isearch is active, f10 does indeed work.  When, 
> > additionally, C-x b is active on another frame, it throws the error 
> > "Command attempted to use minibuffer while in minibuffer".  This is 
> > surely correct.  However, the isearch highlighting doesn't get removed 
> > in this error case.  That is incorrect.

> It's not removed because isearch is not aborted.  You can continue your 
> isearch or abort it with C-g.  That's a difference indeed: in earlier 
> Emacsen isearch would have aborted in this case.  Which one is better is 
> not clear to me.

Sorry, yes, you're sort of right, here.  But in this scenario, typing
C-b or C-a moves the cursor without terminating the isearch.  That is
definitely incorrect.

> >> Yet another similar use case is when you type "C-x 8 RET" during 
> >> Isearch: that reads the character's name/codepoint from the minibuffer.

> > This goes wrong.  With C-x b active on frame F1, move to F2, start an 
> > isearch, C-x 8 RET, use TAB completion to select a character and RET. 
> > This displays

> >    Switch to buffer (default xdisp.c):  [Failing I-search: su�]

> > on F2.  On terminating the isearch and completing the C-x b action in 
> > F2's minibufer, the buffer switch has worked in frame F1.


> It doesn't go wrong, it has moved the minibuffer from frame F1 to frame 
> F2.

The minibuffer's contents, the C-x b, is acting on F1.  It is surely
wrong to have moved the minibuffer to F2.

-- 
Alan Mackenzie (Nuremberg, Germany).

RE: New multi-command facility displays in the wrong echo area.

[Drew Adams]

> It is quite unusual to leave an active minibuffer
> and switch to another frame to start an Isearch.

It's not unusual at all, for me.  I often have an
open minibuffer while I move to other buffers and
perform various actions before returning to the
minibuffer and finishing with it.  And most often
those buffers are, yes, in windows on other frames.

This includes using minibuffer keys that let me
explore elsewhere, and may themselves open
recursive minibuffers, using Isearch in any
buffer, including but not limited to, the
minibuffer itself (which for me is in its own
frame) and *Completions* (which for me is also in
its own frame).

My use (and Icicles use generally) may not be
"typical", but (1) it's very useful to be able to
do this, and (2) it's always been possible to do
it, before now (since Day One).

I don't yet use Emacs 27, but this sounds like a
very limiting regression, and one that isn't
compensated by any gain.

Re: New multi-command facility displays in the wrong echo area.

[Gregory Heytings via Emacs development discussions.]

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


Hi Alan,

>>>> Yet another similar use case is when you type "C-x 8 RET" during 
>>>> Isearch: that reads the character's name/codepoint from the 
>>>> minibuffer.
>>>
>>> This goes wrong.  With C-x b active on frame F1, move to F2, start an 
>>> isearch, C-x 8 RET, use TAB completion to select a character and RET. 
>>> This displays
>>>
>>>    Switch to buffer (default xdisp.c):  [Failing I-search: su�]
>>>
>>> on F2.  On terminating the isearch and completing the C-x b action in 
>>> F2's minibufer, the buffer switch has worked in frame F1.
>>
>> It doesn't go wrong, it has moved the minibuffer from frame F1 to frame 
>> F2.
>
> The minibuffer's contents, the C-x b, is acting on F1.  It is surely 
> wrong to have moved the minibuffer to F2.
>

It can perhaps be argued that it is wrong, but it's a different problem, 
and this behavior exists since Emacs 24.

FWIW, I don't think it is wrong: the minibuffer has indeed moved to F2, 
but when you press RET after choosing the buffer you want, the buffer 
switch happens in F1.  And on a TTY, Emacs even goes back to F1.

Re: New multi-command facility displays in the wrong echo area.

[Gregory Heytings via Emacs development discussions.]

>> If Gregory's change doesn't make things worse than they were before 
>> Emacs 27.1, then I think we should install it.  In the emacs-27 branch, 
>> please.
>
> Btw, to make sure the change is not for the worse, those same 
> experiments should be repeated with enable-recursive-minibuffers set 
> non-nil.
>

Repeating the same experiments with (setq enable-recursive-minibuffers t):

>
> Does that work if you set tty-menu-open-use-tmm non-nil, then press f10 
> while the I-search: prompt is active?  This is one case where Isearch 
> reads from the minibuffer.
>

This works (the active minibuffer is moved to the current frame), with 
earlier and current Emacs versions, with or without the bugfix.

>
> Another, perhaps more important, use case is when you type "M-s e" 
> during Isearch: that enters the minibuffer to let you edit the search 
> string.
>

This works (the active minibuffer is moved to the current frame), with 
earlier and current Emacs versions, with or without the bugfix.

>
> Yet another similar use case is when you type "C-x 8 RET" during 
> Isearch: that reads the character's name/codepoint from the minibuffer.
>

This still works (the active minibuffer is moved to the current frame), 
with earlier and current Emacs versions, with or without the bugfix.

RE: New multi-command facility displays in the wrong echo area.

[Gregory Heytings via Emacs development discussions.]

>
> I don't yet use Emacs 27, but this sounds like a very limiting 
> regression, and one that isn't compensated by any gain.
>

Don't worry, it is now fixed.

The gain is explained in NEWS.27: When the minibuffer is active, echo-area 
messages are displayed at the end of the minibuffer instead of hiding the 
minibuffer by the echo area display.

For example, if you do C-x C-f, you see "Find file: ...".  If you now 
switch to another window and do C-s foo, you will see: "Find file: ... 
[I-search: foo]".

With earlier Emacsen, or with Emacs 27 and (setq set-message-function 
nil), you see instead: "I-search: foo" (that is, the "Find file: ..." is 
hidden).

RE: New multi-command facility displays in the wrong echo area.

[Drew Adams]

> The gain is explained in NEWS.27: When the minibuffer is active, echo-area
> messages are displayed at the end of the minibuffer instead of hiding the
> minibuffer by the echo area display.

Yes, I know.  That's a misfeature, IMO - a regression
for users and libraries - but it was done on purpose.

It should have continued to be possible for `message'
to temporarily write to the echo area (yes, hiding
the minibuffer temporarily), instead of being co-opted
by the `minibuffer-message' behavior.

Instead of having both behaviors possible, and thus
usable for different purposes, they are collapsed
into only the `minibuffer-message' behavior (write
at the end of the minibuffer, instead of to the echo
area).

Re: New multi-command facility displays in the wrong echo area.

[Eli Zaretskii]

> Date: Sat, 10 Oct 2020 20:30:07 +0000
> From: Gregory Heytings <ghe@sdf.org>
> cc: acm@muc.de, monnier@iro.umontreal.ca, emacs-devel@gnu.org
> 
> > Does that work if you set tty-menu-open-use-tmm non-nil, then press f10 
> > while the I-search: prompt is active?  This is one case where Isearch 
> > reads from the minibuffer.
> >
> 
> This works (the active minibuffer is moved to the current frame), with 
> earlier and current Emacs versions, with or without the bugfix.
> 
> >
> > Another, perhaps more important, use case is when you type "M-s e" 
> > during Isearch: that enters the minibuffer to let you edit the search 
> > string.
> >
> 
> This works (the active minibuffer is moved to the current frame), with 
> earlier and current Emacs versions, with or without the bugfix.
> 
> >
> > Yet another similar use case is when you type "C-x 8 RET" during 
> > Isearch: that reads the character's name/codepoint from the minibuffer.
> >
> 
> This still works (the active minibuffer is moved to the current frame), 
> with earlier and current Emacs versions, with or without the bugfix.

Thanks.  So I think your change is a definite improvement, and I
therefore installed it on the emacs-27 branch.

Re: New multi-command facility displays in the wrong echo area.

[Gregory Heytings via Emacs development discussions.]

>
> Thanks.  So I think your change is a definite improvement, and I 
> therefore installed it on the emacs-27 branch.
>

Thank you.  Alas, it's not the only bug of this new feature.  A recipe:

emacs -Q
(progn
   (set-frame-width nil 80)
   (setq max-mini-window-height 1)
   (setq default-directory (concat "/" (make-string 67 ?a)))
   (call-interactively 'find-file))
press C-x o
press C-s

At this point you see no indication that I-search has been started.  (If 
you look close enough, the only thing you can see is a curly arrow in the 
right fringe of the miniwindow.)  Likewise, if you press C-x C-s, you see 
no indication that changes have been saved (or not).  And so forth.

I suggest the following fourth condition in set-minibuffer-message:

(< (buffer-size (window-buffer (active-minibuffer-window))) (/ (frame-width (window-frame (active-minibuffer-window))) 2))

Of course it's a heuristic (it could still fail when the face used in the 
miniwindow is different, and larger than, the default face), but it should 
catch 99.99% of the remaining error cases.

It is amazing that such a feature got accepted, was included in an 
official Emacs release, and became Emacs' default behavior, without even 
trying the two obvious cases to test: what happens when there is not 
enough free space in the minibuffer? and what happens when the active 
minibuffer is not on the same frame?

It is even more amazing that, at the same time, my proposed solution to 
display completion candidates in the minibuffer is rejected on the grounds 
that it could cause "potential problems", when so far no one has managed 
to show a case in which it would create an actual problem.

Re: New multi-command facility displays in the wrong echo area.

[Alan Mackenzie]

Hello, Gregory.

On Mon, Oct 12, 2020 at 09:12:05 +0000, Gregory Heytings wrote:

> > Thanks.  So I think your change is a definite improvement, and I 
> > therefore installed it on the emacs-27 branch.

> Thank you.  Alas, it's not the only bug of this new feature.  A recipe:

> emacs -Q
> (progn
>    (set-frame-width nil 80)
>    (setq max-mini-window-height 1)
>    (setq default-directory (concat "/" (make-string 67 ?a)))
>    (call-interactively 'find-file))
> press C-x o
> press C-s

> At this point you see no indication that I-search has been started.  (If 
> you look close enough, the only thing you can see is a curly arrow in the 
> right fringe of the miniwindow.)  Likewise, if you press C-x C-s, you see 
> no indication that changes have been saved (or not).  And so forth.

Well, whoever sees/doesn't see this did set max-mini-window-height to 1.
Surely this is a case of you ask for it, you get it.

> I suggest the following fourth condition in set-minibuffer-message:

> (< (buffer-size (window-buffer (active-minibuffer-window))) (/ (frame-width (window-frame (active-minibuffer-window))) 2))

> Of course it's a heuristic (it could still fail when the face used in the 
> miniwindow is different, and larger than, the default face), but it should 
> catch 99.99% of the remaining error cases.

Perhaps there's a less heuristic way of dealing with it.  I haven't
looked into it closely.

> It is amazing that such a feature got accepted, was included in an 
> official Emacs release, and became Emacs' default behavior, without even 
> trying the two obvious cases to test: what happens when there is not 
> enough free space in the minibuffer? and what happens when the active 
> minibuffer is not on the same frame?

Bugs are always obvious after somebody's pointed them out.  Well done
for finding them!

> It is even more amazing that, at the same time, my proposed solution to 
> display completion candidates in the minibuffer is rejected on the grounds 
> that it could cause "potential problems", when so far no one has managed 
> to show a case in which it would create an actual problem.

Emacs is ~45 years old.  Some of the maintainers have been on the job
for more than half of that time.  They've developed a feel for what fits
in harmoniously and what could easily jar and cause problems in the
future.  Given the complexity of Emacs, we can't really afford to wait
until potential problems become real problems - there might just be too
many of these to cope with.

For what it's worth, others (including me) have had effective bug fixes
rejected on various grounds.  For better or for worse, it's just part of
Emacs development.

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: New multi-command facility displays in the wrong echo area.

[Gregory Heytings via Emacs development discussions.]

Hi Alan,

>>> Thanks.  So I think your change is a definite improvement, and I 
>>> therefore installed it on the emacs-27 branch.
>>
>> Thank you.  Alas, it's not the only bug of this new feature.  A recipe:
>>
>> emacs -Q
>> (progn
>>    (set-frame-width nil 80)
>>    (setq max-mini-window-height 1)
>>    (setq default-directory (concat "/" (make-string 67 ?a)))
>>    (call-interactively 'find-file))
>> press C-x o
>> press C-s
>>
>> At this point you see no indication that I-search has been started. 
>> (If you look close enough, the only thing you can see is a curly arrow 
>> in the right fringe of the miniwindow.)  Likewise, if you press C-x 
>> C-s, you see no indication that changes have been saved (or not).  And 
>> so forth.
>
> Well, whoever sees/doesn't see this did set max-mini-window-height to 1. 
> Surely this is a case of you ask for it, you get it.
>

With earlier Emacsen that setting would not have had such effect, the 
contents of the minibuffer would have been overwritten by the echo area in 
all cases.  Setting max-mini-window-height to 1 is perfectly valid, and by 
the way the same thing could happen with max-mini-window-height set to 2 
and a longer input, and so forth.  This also could happen for those who 
use independent miniwindows, which have a fixed size.

>> It is amazing that such a feature got accepted, was included in an 
>> official Emacs release, and became Emacs' default behavior, without 
>> even trying the two obvious cases to test: what happens when there is 
>> not enough free space in the minibuffer? and what happens when the 
>> active minibuffer is not on the same frame?
>
> Bugs are always obvious after somebody's pointed them out.  Well done 
> for finding them!
>

I don't think so, these two cases are obvious things to check.  I did not 
know about that feature before you sent your message three days ago, and 
after fixing the bug you found this bug is the second thing that 
immediately came to my mind.

Re: New multi-command facility displays in the wrong echo area.

[Eli Zaretskii]

> Date: Mon, 12 Oct 2020 09:12:05 +0000
> From: Gregory Heytings <ghe@sdf.org>
> cc: acm@muc.de, monnier@iro.umontreal.ca, emacs-devel@gnu.org
> 
> emacs -Q
> (progn
>   (set-frame-width nil 80)
>   (setq max-mini-window-height 1)
>   (setq default-directory (concat "/" (make-string 67 ?a)))
>   (call-interactively 'find-file))
> press C-x o
> press C-s
> 
> At this point you see no indication that I-search has been started. (If you look close enough, the only thing you can see is a curly arrow in the right fringe of the miniwindow.) Likewise, if you press C-x C-s, you see no indication that changes have been saved (or not). And so forth.

Right.

> I suggest the following fourth condition in set-minibuffer-message:
> 
> (< (buffer-size (window-buffer (active-minibuffer-window))) (/ (frame-width 
> (window-frame (active-minibuffer-window))) 2))

So you suggest in that case to overwrite the minibuffer prompt, like
Emacs 26 did?  I'm not sure I like this: it would bring back many
problems this feature was supposed to fix.  Can we do better than
obliterating the entire minibuffer text?

Juri, any ideas?

In any case, I think the condition could be relaxed: we only care
about how much space is left from the minibuffer text's end till the
end of the screen line, so "if minibuffer text size modulo
window-width is less than something" would be better, I think.  E.g.,
if you use 70 instead of 67 in your recipe, the problem is mostly
gone.

Also, it would be safer to use string-width instead of the number of
characters, or even window-text-pixel-size: some people do customize
the faces used in the minibuffer.

> It is amazing that such a feature got accepted, was included in an official Emacs release, and became Emacs' default behavior, without even trying the two obvious cases to test: what happens when there is not enough free space in the minibuffer? and what happens when the active minibuffer is not on the same frame?

This has some history.  You are welcome to read the discussion in
bug#38457, especially starting at

  https://debbugs.gnu.org/cgi/bugreport.cgi?bug=38457#17

You will see that many issues were discussed, the dangers were
expected, and as result the change became less invasive, which was
especially important because the release cycle was about to start.
However, it didn't sound wise to reject the changes outright because
they've fixed several important use cases that were an annoyance for a
long time.

But yes, any significant change in such basic functionality runs a
risk to break something, especially in relatively rare use cases
(max-mini-window-height set to 1, followed by "C-x o" out of the
minibuffer).  This risk is inherent part of development, and sometimes
mistakes are being made.  We try at least not to make the mistakes we
know about.

> It is even more amazing that, at the same time, my proposed solution to display completion candidates in the minibuffer is rejected on the grounds that it could cause "potential problems", when so far no one has managed to show a case in which it would create an actual problem.

Maybe because we are now wiser and don't want to repeat past mistakes?

Btw, the C-s use case is special, you can see that if you do just
this:

  C-x C-f
  C-s

Juri, would it make sense to do something special for Isearch in the
"C-x o" case as well?  Or am I wrong, and there's nothing special
with Isearch using the mini-window here?

Re: New multi-command facility displays in the wrong echo area.

[Gregory Heytings via Emacs development discussions.]

>> At this point you see no indication that I-search has been started. (If 
>> you look close enough, the only thing you can see is a curly arrow in 
>> the right fringe of the miniwindow.) Likewise, if you press C-x C-s, 
>> you see no indication that changes have been saved (or not). And so 
>> forth.
>
> Right.
>
>> I suggest the following fourth condition in set-minibuffer-message:
>>
>> (< (buffer-size (window-buffer (active-minibuffer-window))) (/ (frame-width (window-frame (active-minibuffer-window))) 2))
>
> So you suggest in that case to overwrite the minibuffer prompt, like 
> Emacs 26 did?
>

Yes, indeed.  That's clearly better than not showing anything at all. 
When there is not enough space on the right of the current minibuffer 
contents, IMO it should be overwritten.

>
> I'm not sure I like this: it would bring back many problems this feature 
> was supposed to fix.
>

So far I did not know what problems that feature was supposed to fix, so I 
could not make a judgment on this.  The NEWS item does not indicate what 
these problems were, and I had myself never encountered a situation where 
overwriting the current minibuffer contents was problematic.  It seemed to 
me so far that it was only something more aesthetically pleasing.  Now 
that I've read bug#38457, I see that this is not the case, but I'm not at 
all convinced by the proposed solution.  Something like what eldoc does 
when the minibuffer is active (temporarily displaying the info at the 
beginning of the mode-line) would have been a much better and more robust 
solution.  Otherwise, another solution would be to temporarily add a 
"zeroth" (or "minusoneth") line to the minibuffer with the message.

>
> In any case, I think the condition could be relaxed: we only care about 
> how much space is left from the minibuffer text's end till the end of 
> the screen line, so "if minibuffer text size modulo window-width is less 
> than something" would be better, I think.  E.g., if you use 70 instead 
> of 67 in your recipe, the problem is mostly gone.
>

The condition could be refined indeed, but the modulo operation you 
propose would not work with variable pitch faces.  I intentionally 
proposed something simple, which should work in (almost) all cases.  I'm 
an adept of the KISS principle.

>
> Also, it would be safer to use string-width instead of the number of 
> characters, or even window-text-pixel-size: some people do customize the 
> faces used in the minibuffer.
>

I won't comment on this.  As I already said elsewhere, it's IMO awful to 
expect any code to do something like this.

>> It is amazing that such a feature got accepted, was included in an 
>> official Emacs release, and became Emacs' default behavior, without 
>> even trying the two obvious cases to test: what happens when there is 
>> not enough free space in the minibuffer? and what happens when the 
>> active minibuffer is not on the same frame?
>
> This has some history.  You are welcome to read the discussion in 
> bug#38457, especially starting at
>
>  https://debbugs.gnu.org/cgi/bugreport.cgi?bug=38457#17
>
> You will see that many issues were discussed, the dangers were expected, 
> and as result the change became less invasive, which was especially 
> important because the release cycle was about to start. However, it 
> didn't sound wise to reject the changes outright because they've fixed 
> several important use cases that were an annoyance for a long time.
>

See above.  I've now read that bug thread, and I'm not at all convinced 
that the chosen solution was TRT, quite the contrary.

>
> But yes, any significant change in such basic functionality runs a risk 
> to break something, especially in relatively rare use cases 
> (max-mini-window-height set to 1, followed by "C-x o" out of the 
> minibuffer).
>

As I said to Alan, this recipe is just a recipe, it exhibits a more 
general problem.  The same problem would happen with 
max-mini-window-height set to 2 and a longer text, with a miniwindow only 
frame, with a small enough Emacs frame, and so forth.

>
> This risk is inherent part of development, and sometimes mistakes are 
> being made.  We try at least not to make the mistakes we know about.
>

Well... no: the bug#38457 thread contains a message (#317) by Dmitry Gutov 
which points to a problem that is similar to the one I "discovered". 
BTW, he also suggests to use eldoc-minibuffer-message instead of the 
current solution.

>> It is even more amazing that, at the same time, my proposed solution to 
>> display completion candidates in the minibuffer is rejected on the 
>> grounds that it could cause "potential problems", when so far no one 
>> has managed to show a case in which it would create an actual problem.
>
> Maybe because we are now wiser and don't want to repeat past mistakes?
>

It seems to me that being wiser would mean taking the time to evaluate a 
proposed solution, instead of rejecting it outright based on a gut 
feeling.

Re: New multi-command facility displays in the wrong echo area.

[Eli Zaretskii]

> Date: Mon, 12 Oct 2020 15:41:35 +0000
> From: Gregory Heytings <ghe@sdf.org>
> cc: Juri Linkov <juri@linkov.net>, acm@muc.de, monnier@iro.umontreal.ca,
>         emacs-devel@gnu.org
> 
> > In any case, I think the condition could be relaxed: we only care about 
> > how much space is left from the minibuffer text's end till the end of 
> > the screen line, so "if minibuffer text size modulo window-width is less 
> > than something" would be better, I think.  E.g., if you use 70 instead 
> > of 67 in your recipe, the problem is mostly gone.
> 
> The condition could be refined indeed, but the modulo operation you 
> propose would not work with variable pitch faces.

It will, if the calculation is done in pixels.  The APIs you mentioned
can return pixels instead of columns, or there are alternatives which
do.

> I intentionally proposed something simple, which should work in
> (almost) all cases.  I'm an adept of the KISS principle.

Me too; "the solution should as simple as possible, but not simpler."

> > Also, it would be safer to use string-width instead of the number of 
> > characters, or even window-text-pixel-size: some people do customize the 
> > faces used in the minibuffer.
> 
> I won't comment on this.  As I already said elsewhere, it's IMO awful to 
> expect any code to do something like this.

That function was written because it's really needed and useful.  We
use it under the hood, and I see no reason not to use it in this case,
which is exactly one of the cases for which the function was
implemented.

> See above.  I've now read that bug thread, and I'm not at all convinced 
> that the chosen solution was TRT, quite the contrary.

We can discuss other solutions, of course.  However, significant
changes will have to wait for Emacs 28.

> It seems to me that being wiser would mean taking the time to evaluate a 
> proposed solution, instead of rejecting it outright based on a gut 
> feeling.

Please give me the credit of having done so.  I've given you no reason
to believe otherwise; disagreement doesn't imply incompetence or
sloppiness on my part.  It is simply unfair and even rude to suggest
that.

Re: New multi-command facility displays in the wrong echo area.

[Gregory Heytings via Emacs development discussions.]

>>> In any case, I think the condition could be relaxed: we only care 
>>> about how much space is left from the minibuffer text's end till the 
>>> end of the screen line, so "if minibuffer text size modulo 
>>> window-width is less than something" would be better, I think.  E.g., 
>>> if you use 70 instead of 67 in your recipe, the problem is mostly 
>>> gone.
>>
>> The condition could be refined indeed, but the modulo operation you 
>> propose would not work with variable pitch faces.
>
> It will, if the calculation is done in pixels.  The APIs you mentioned 
> can return pixels instead of columns, or there are alternatives which 
> do.
>

Indeed, this would also work:

(< (mod (car (window-text-pixel-size (active-minibuffer-window))) (window-text-width (active-minibuffer-window) t))
    (/ (car (window-text-pixel-size (active-minibuffer-window))) 2))

But going in that direction means that one should also take the current 
window height into account: if the miniwindow is tall enough, the above 
condition could be nil even though there would be enough room to display 
the message.

>> See above.  I've now read that bug thread, and I'm not at all convinced 
>> that the chosen solution was TRT, quite the contrary.
>
> We can discuss other solutions, of course.  However, significant changes 
> will have to wait for Emacs 28.
>

Ouch.  So this last-minute change will last for several years?

>> It seems to me that being wiser would mean taking the time to evaluate 
>> a proposed solution, instead of rejecting it outright based on a gut 
>> feeling.
>
> Please give me the credit of having done so.  I've given you no reason 
> to believe otherwise; disagreement doesn't imply incompetence or 
> sloppiness on my part.  It is simply unfair and even rude to suggest 
> that.
>

I do not suggest anything like that.  But I'm a doubting Thomas, and I 
can't give you this credit until I see a recipe that would convincingly 
demonstrate a potential problem that my proposed solution would create. 
Especially given I explained that this solution is only _at the moment_ 
the best solution, for earlier versions and the current version of Emacs, 
until a better solution is implemented.

RE: New multi-command facility displays in the wrong echo area.

[Drew Adams]

> So you suggest in that case to overwrite the minibuffer
> prompt, like Emacs 26 did?

I do.

> I'm not sure I like this: it would bring back many
> problems this feature was supposed to fix.  Can we do
> better than obliterating the entire minibuffer text?

Here's the problem, IMO:

The minibuffer and echo area share the same space.

For simple interactions with a user, there's no
problem: either input and output are ordered in
an expected way - no surprises.

For complex interactions, which can include delayed
echoes or echoes from other processes etc., `message'
overwriting minibuffer input (and prompt) can be
disconcerting, and it can even mean that a user might
miss seeing a prompt, and thus become confused by the
ensuing dialog.  And as a result, a user could even
end up mistakenly deleting data or worse.

But complex interactions also allow the use of a
minibuffer as almost a regular buffer - but one that
also gives you access to sets of completions etc.

They let you interrupt your current minibuffer
"dialog" to do something else - examine something
relevant in another buffer, make some changes to
something - whatever.  This is an important _feature_,
not a bug.

Minibuffer interaction is extremely flexible,
precisely because it's more or less a normal buffer
in more or less a normal window.

The changes made for Emacs 27, AFAICT, break this.
They prevent `message' from using the echo area
whenever the minibuffer is active.  In effect, they
turn `message' into `minibuffer-message' when the
minibuffer is active.

There was a reason why we had both `message' and
`minibuffer-message'.  They're both useful when the
minibuffer is active.  Yes.

And the usefulness of `message' in this context is
precisely the same as the problem that you've sought
to cure: by using the echo area it _interrupts_ the
minibuffer dialog temporarily.  And yes, that can
mean hiding input and prompt.

If you really feel that the problem you sought to
fix is so serious, a proper fix would do this: in
some way, _physically separate_ the minibuffer and
the echo area, so they are _both_ visible at the
same time.  Problems solved; end of story.  (But
that needs to be designed and implemented well.)

I object strongly to the "fix" that was made.
And I don't think it should have been made with
discussion only in a bug thread, not here.  And
I said so at the time.

Nothing in that thread really addressed the real
problem, IMO: echo area and minibuffer sharing
the same space.  That elephant in the room was
ignored.

Instead, the "fix" doubled down on that problem,
in effect removing the rich possibilities of
interaction (see complex interactions, above),
and imposing ONLY the simple interaction: initiate
minibuffer and prevent any use of the echo area
until the minibuffer is exited.

Same thing, BTW, with the change of `y-or-n-p' to
using the minibuffer.  That obviates using it
during minibuffer input to just read a character
(without using a recursive minibuffer etc.).

These are, IMO, misguided "fixes" based on a too
simple understanding of the minibuffer.

Users used to be free, while the minibuffer was
active, to do all sorts of things anywhere in
Emacs.  Now you've gone down the road of confining
the minibuffer to a simple, linear, modal (in
effect) ask-and-read behavior.  That's not emacsy,
IMO, and it breaks lots of my uses of the
minibuffer.

If `message' and the echo area are _sometimes_ a
problem for _some_ minibuffer interactions then
find a proper solution by, in some way, separating
the echo area and minibuffer - NOT in time, and
not modally, but in space.

> In any case, I think the condition could be relaxed: we only care
> about how much space is left from the minibuffer text's end till the
> end of the screen line, so "if minibuffer text size modulo
> window-width is less than something" would be better, I think.  E.g.,
> if you use 70 instead of 67 in your recipe, the problem is mostly
> gone.
>
> Also, it would be safer to use string-width instead of the number of
> characters, or even window-text-pixel-size: some people do customize
> the faces used in the minibuffer.

There should be no fiddling with minibuffer size,
no guesses or dependencies on particular line
length, etc.

`minibuffer-message', appending text to the
minibuffer input is definitely not something that
should be overworked.  It's for simple echoes of
info directly relevant to the particular minibuffer
interactions in progress.

> > It is amazing that such a feature got accepted, was included in an official
> Emacs release, and became Emacs' default behavior, without even trying the
> two obvious cases to test: what happens when there is not enough free space
> in the minibuffer? and what happens when the active minibuffer is not on the
> same frame?
> 
> This has some history.  You are welcome to read the discussion in
> bug#38457, especially starting at
> 
> https://urldefense.com/v3/__https://debbugs.gnu.org/cgi/bugreport.cgi?bug=384
> 57*17__;Iw!!GqivPVa7Brio!KMf2iSSkE7JvnGnijw3sBBDFxR7wBlsojqiXwTMqPArBC1Nm-
> LDnhZG-lghgzrvY$
> 
> You will see that many issues were discussed, the dangers were
> expected, and as result the change became less invasive, which was
> especially important because the release cycle was about to start.
> However, it didn't sound wise to reject the changes outright because
> they've fixed several important use cases that were an annoyance for a
> long time.

I don't agree that they've fixed several important
use cases.  Anything they've "fixed" has been with
us from Day One - and has long been recognized as
somewhat problematic.  There was no urgency to toss
this "fix" onto Emacs.

> But yes, any significant change in such basic functionality runs a
> risk to break something, especially in relatively rare use cases
> (max-mini-window-height set to 1, followed by "C-x o" out of the
> minibuffer).  This risk is inherent part of development, and sometimes
> mistakes are being made.  We try at least not to make the mistakes we
> know about.

I pointed to mistakes being made in that bug thread.
That was ignored.  There was entirely too much haste
to "fix" the problems reported - which were nothing
new.

> > It is even more amazing that, at the same time, my proposed solution to
> display completion candidates in the minibuffer is rejected on the grounds
> that it could cause "potential problems", when so far no one has managed to
> show a case in which it would create an actual problem.
> 
> Maybe because we are now wiser and don't want to repeat past mistakes?
> 
> Btw, the C-s use case is special, you can see that if you do just
> this: C-x C-f C-s

I don't see anything special about that.  Without
changing to another buffer, `C-s' just searches
your minibuffer input.  It should do exactly that.

And with changing to another buffer/window, `C-s'
should just search that space instead.  Nothing
special here.  Same behavior as a non-minibuffer
buffer.

The minibuffer is a general text-editing buffer,
in addition to being a question-answering
text-input area.

Re: New multi-command facility displays in the wrong echo area.

[Eli Zaretskii]

> Date: Mon, 12 Oct 2020 16:31:27 +0000
> From: Gregory Heytings <ghe@sdf.org>
> cc: juri@linkov.net, acm@muc.de, monnier@iro.umontreal.ca, emacs-devel@gnu.org
> 
> Indeed, this would also work:
> 
> (< (mod (car (window-text-pixel-size (active-minibuffer-window))) (window-text-width (active-minibuffer-window) t))
>     (/ (car (window-text-pixel-size (active-minibuffer-window))) 2))
> 
> But going in that direction means that one should also take the current 
> window height into account: if the miniwindow is tall enough, the above 
> condition could be nil even though there would be enough room to display 
> the message.

You mean, if the message to be displayed in the minibuffer uses large
fonts or includes tall images?  In that case, we will simply display
the single line with partially-visible text/image (assuming
max-mini-window-height doesn't allow to resize to see all of it), and
I don't see what can be done about that.

It is highly unusual for messages to use such faces or images, and if
some features do that, users of those features should be told to not
limit the mini-window height to a size that's too small.

> > We can discuss other solutions, of course.  However, significant changes 
> > will have to wait for Emacs 28.
> 
> Ouch.  So this last-minute change will last for several years?

Unless we can come up with a change that is either simple or safe.  Or
if we decide that the current situation is so unacceptable that we are
willing to take higher risks of releasing a less stable Emacs 27.2.

> > Please give me the credit of having done so.  I've given you no reason 
> > to believe otherwise; disagreement doesn't imply incompetence or 
> > sloppiness on my part.  It is simply unfair and even rude to suggest 
> > that.
> 
> I do not suggest anything like that.  But I'm a doubting Thomas, and I 
> can't give you this credit until I see a recipe that would convincingly 
> demonstrate a potential problem that my proposed solution would create. 

I cannot help you with your doubts more than I already did.  If you
still have those doubts, I'd appreciate if you keep them to yourself,
because having them written here is an insult I don't think I deserve.

Re: New multi-command facility displays in the wrong echo area.

[Eli Zaretskii]

> Date: Mon, 12 Oct 2020 10:12:39 -0700 (PDT)
> From: Drew Adams <drew.adams@oracle.com>
> Cc: acm@muc.de, monnier@iro.umontreal.ca, emacs-devel@gnu.org
> 
> > So you suggest in that case to overwrite the minibuffer
> > prompt, like Emacs 26 did?
> 
> I do.

Drew, please don't go there.  These "rearguard wars" are pointless:
you've already argued all those arguments in the past, and were unable
to convince.  There's no need to reiterate your opinions; we know all
too well that you are unhappy about this change in behavior, and will
never agree with it.

But we aren't going back to what Emacs 26 did.  We might decide to
change the current behavior to improve it, but there's no chance we
are going to remove it.  So please don't start that argument again.
You can always customize your Emacs to behave like Emacs 26 did.

I'm sorry, I cannot afford reading the rest of your message, as it
simply repeats what you have already said in the past, several times.
Life is too short.

Just let go, will you?  TIA.

Re: New multi-command facility displays in the wrong echo area.

[Juri Linkov]

> Btw, the C-s use case is special, you can see that if you do just
> this:
>
>   C-x C-f
>   C-s
>
> Juri, would it make sense to do something special for Isearch in the
> "C-x o" case as well?  Or am I wrong, and there's nothing special
> with Isearch using the mini-window here?

Actually, this case is not special to Isearch.

AFAIU, the problem is following: typing more characters at the end of
the minibuffer enlarges the minibuffer window when the minibuffer grows
longer than the frame's width.  The question is why the minibuffer window
is not enlarged when an overlay is added at the end of the minibuffer?
Is it possible to do this for an added overlay?  If this is impossible
to do automatically, then maybe the minibuffer window could be enlarged
in set-minibuffer-message?

Re: New multi-command facility displays in the wrong echo area.

[Gregory Heytings via Emacs development discussions.]

>>> We can discuss other solutions, of course.  However, significant 
>>> changes will have to wait for Emacs 28.
>>
>> Ouch.  So this last-minute change will last for several years?
>
> Unless we can come up with a change that is either simple or safe.  Or 
> if we decide that the current situation is so unacceptable that we are 
> willing to take higher risks of releasing a less stable Emacs 27.2.
>

I cannot make such a judgment.  But I think options should at least be 
explored.  Would doing something like what eldoc-minibuffer-message does 
possibly be a good solution?  It seems to me that this is safer than the 
current situation, as it does not fiddle with the minibuffer contents. 
If so, what do you (and others) think of the following:

(defvar minibuffer-message-mode-line-string nil)
(setq minibuffer-message-clear-timeout 3)
(defun clear-minibuffer-message ()
   (when (not noninteractive)
     (when (timerp minibuffer-message-timer)
       (cancel-timer minibuffer-message-timer)
       (setq minibuffer-message-timer nil))
     (setq minibuffer-message-mode-line-string nil)))
(defface minibuffer-message-face
   `((t (:background ,(face-attribute 'default :background)
         :foreground ,(face-attribute 'default :foreground)))) "")
(defun set-minibuffer-message (message)
   (when (and (not noninteractive)
              (window-live-p (active-minibuffer-window))
              (eq (window-frame) (window-frame (active-minibuffer-window))))
     (progn
       (when (numberp minibuffer-message-clear-timeout)
         (setq minibuffer-message-timer
               (run-with-timer minibuffer-message-clear-timeout nil
                               #'clear-minibuffer-message)))
       (with-current-buffer
           (window-buffer
            (or (window-in-direction 'above (minibuffer-window))
                (minibuffer-selected-window)
                (get-largest-window)))
         (clear-minibuffer-message)
         (when (and mode-line-format
                    (not (and (listp mode-line-format)
                              (assq 'minibuffer-message-mode-line-string
                                    mode-line-format))))
           (setq mode-line-format
                 (list "" '(minibuffer-message-mode-line-string
                            (" " (:propertize minibuffer-message-mode-line-string
                                              face minibuffer-message-face) " "))
                       mode-line-format)))
         (setq minibuffer-message-mode-line-string message)
         (force-mode-line-update))
       t)))

>
> I cannot help you with your doubts more than I already did.  If you 
> still have those doubts, I'd appreciate if you keep them to yourself, 
> because having them written here is an insult I don't think I deserve.
>

Where do you see an insult in what I wrote?  I'm simply asking for a piece 
of code instead of abstract arguments.  Anyway, as you said to Drew, life 
is too short, so I will simply continue to use my code for myself, and I 
hope that others will find it useful too.  And if the situation has not 
improved in a few months, I'll ring the bell again.

Re: New multi-command facility displays in the wrong echo area.

[Eli Zaretskii]

> From: Juri Linkov <juri@linkov.net>
> Cc: Gregory Heytings <ghe@sdf.org>,  acm@muc.de,  monnier@iro.umontreal.ca,
>   emacs-devel@gnu.org
> Date: Mon, 12 Oct 2020 22:46:29 +0300
> 
> AFAIU, the problem is following: typing more characters at the end of
> the minibuffer enlarges the minibuffer window when the minibuffer grows
> longer than the frame's width.  The question is why the minibuffer window
> is not enlarged when an overlay is added at the end of the minibuffer?

It isn't related to the overlay, it is related to the fact that
max-mini-window-height is set to 1.

Re: New multi-command facility displays in the wrong echo area.

[Eli Zaretskii]

> Date: Mon, 12 Oct 2020 21:06:12 +0000
> From: Gregory Heytings <ghe@sdf.org>
> cc: acm@muc.de, emacs-devel@gnu.org, monnier@iro.umontreal.ca, juri@linkov.net
> 
> > Unless we can come up with a change that is either simple or safe.  Or 
> > if we decide that the current situation is so unacceptable that we are 
> > willing to take higher risks of releasing a less stable Emacs 27.2.
> >
> 
> I cannot make such a judgment.  But I think options should at least be 
> explored.

That goes without saying.

> Would doing something like what eldoc-minibuffer-message does 
> possibly be a good solution?  It seems to me that this is safer than the 
> current situation, as it does not fiddle with the minibuffer contents. 
> If so, what do you (and others) think of the following:

I personally feel that moving echo-area messages to the mode line is
too drastic a change to make it by default, and certainly in a minor
release.  But let's hear wjat others think, and what other ideas will
be brought up.

> (defvar minibuffer-message-mode-line-string nil)
> (setq minibuffer-message-clear-timeout 3)

This seem to make the message clear automatically after a 3-sec
timeout?  If so, this is also a change in behavior wrt what 'message'
does: the current behavior is to clear the message only when an input
event comes in, the timeout is optional and off by default.

> > I cannot help you with your doubts more than I already did.  If you 
> > still have those doubts, I'd appreciate if you keep them to yourself, 
> > because having them written here is an insult I don't think I deserve.
> >
> 
> Where do you see an insult in what I wrote?

That you publicly accuse me of not evaluating your proposal properly,
based on nothing but your tendency to doubt (and the fact that I
disagreed with your opinions).

Re: New multi-command facility displays in the wrong echo area.

[Gregory Heytings via Emacs development discussions.]

Hi Eli,

Thanks for your comments.

>> (defvar minibuffer-message-mode-line-string nil)
>> (setq minibuffer-message-clear-timeout 3)
>
> This seem to make the message clear automatically after a 3-sec timeout? 
> If so, this is also a change in behavior wrt what 'message' does: the 
> current behavior is to clear the message only when an input event comes 
> in, the timeout is optional and off by default.
>

Indeed, sorry, I forgot to remove that line (which I used to test the 
function) before sending my mail.  It can of course be removed.

Here is a slightly improved version of the code, which removes the 
(minibuffer-message-mode-line-string ...) from mode-line-format when 
clearing the minibuffer message.

(defvar minibuffer-message-mode-line-string nil)
(defvar minibuffer-message-buffer nil)
(defun clear-minibuffer-message ()
   (when (not noninteractive)
     (when (timerp minibuffer-message-timer)
       (cancel-timer minibuffer-message-timer)
       (setq minibuffer-message-timer nil))
     (setq minibuffer-message-mode-line-string nil)
     (if (bufferp minibuffer-message-buffer)
         (with-current-buffer minibuffer-message-buffer
           (let ((mls (and (listp mode-line-format)
                           (assq 'minibuffer-message-mode-line-string
                                 mode-line-format))))
             (if mls (setq mode-line-format (remq mls mode-line-format))))))))
(defface minibuffer-message-face
   `((t (:background ,(face-attribute 'default :background)
         :foreground ,(face-attribute 'default :foreground)))) "")
(defun set-minibuffer-message (message)
   (when (and (not noninteractive)
              (window-live-p (active-minibuffer-window))
              (eq (window-frame) (window-frame (active-minibuffer-window))))
     (progn
       (when (numberp minibuffer-message-clear-timeout)
         (setq minibuffer-message-timer
               (run-with-timer minibuffer-message-clear-timeout nil
                               #'clear-minibuffer-message)))
       (with-current-buffer
           (window-buffer
            (or (window-in-direction 'above (minibuffer-window))
                (minibuffer-selected-window)
                (get-largest-window)))
         (clear-minibuffer-message)
         (when (and mode-line-format
                    (not (and (listp mode-line-format)
                              (assq 'minibuffer-message-mode-line-string
                                    mode-line-format))))
           (setq minibuffer-message-buffer (current-buffer))
           (setq mode-line-format
                 (list "" '(minibuffer-message-mode-line-string
                            (" " (:propertize minibuffer-message-mode-line-string
                                              face minibuffer-message-face) " "))
                       mode-line-format)))
         (setq minibuffer-message-mode-line-string message)
         (force-mode-line-update))
       t)))

Re: New multi-command facility displays in the wrong echo area.

[Gregory Heytings via Emacs development discussions.]

Hi Eli,

>
> Here is a slightly improved version of the code, which removes the 
> (minibuffer-message-mode-line-string ...) from mode-line-format when 
> clearing the minibuffer message.
>

Please ignore the code I sent you two hours ago, and replace it with the 
following one:

(defvar minibuffer-message-mode-line-string nil)
(defvar minibuffer-message-mode-line-buffer nil)
(defun clear-minibuffer-message ()
   (when (not noninteractive)
     (when (timerp minibuffer-message-timer)
       (cancel-timer minibuffer-message-timer)
       (setq minibuffer-message-timer nil))
     (setq minibuffer-message-mode-line-string nil)
     (when (bufferp minibuffer-message-mode-line-buffer)
       (with-current-buffer minibuffer-message-mode-line-buffer
         (let ((mls (and (listp mode-line-format)
                         (assq 'minibuffer-message-mode-line-string
                               mode-line-format))))
           (if mls (setq mode-line-format (cadr (remq mls mode-line-format))))))
       (setq minibuffer-message-mode-line-buffer nil))))
(defface minibuffer-message-face
   `((t (:background ,(face-attribute 'default :background)
         :foreground ,(face-attribute 'default :foreground)))) "")
(defun set-minibuffer-message (message)
   (when (and (not noninteractive)
              (window-live-p (active-minibuffer-window))
              (eq (window-frame) (window-frame (active-minibuffer-window))))
     (progn
       (when (numberp minibuffer-message-clear-timeout)
         (setq minibuffer-message-timer
               (run-with-timer minibuffer-message-clear-timeout nil
                               #'clear-minibuffer-message)))
       (with-current-buffer
           (window-buffer
            (or (window-in-direction 'above (minibuffer-window))
                (minibuffer-selected-window)
                (get-largest-window)))
         (clear-minibuffer-message)
         (when (and mode-line-format
                    (not (and (listp mode-line-format)
                              (assq 'minibuffer-message-mode-line-string
                                    mode-line-format))))
           (setq minibuffer-message-mode-line-buffer (current-buffer))
           (setq mode-line-format
                 (list "" '(minibuffer-message-mode-line-string
                            (" " (:propertize minibuffer-message-mode-line-string
                                              face minibuffer-message-face) " "))
                       mode-line-format)))
         (setq minibuffer-message-mode-line-string (substring-no-properties message))
         (force-mode-line-update))
       t)))

Re: New multi-command facility displays in the wrong echo area.

[Gregory Heytings via Emacs development discussions.]

Hi Eli,

>> Thanks.  So I think your change is a definite improvement, and I 
>> therefore installed it on the emacs-27 branch.
>
> Thank you.
>

I just realized (thanks to Stefan's last email on this list) that my patch 
introduces a regression for those who (like him) use miniwindow-only 
frames.

To correct that regression, the third condition in set-minibuffer-message:

(eq (window-frame) (window-frame (active-minibuffer-window))

should be:

(or (eq (window-frame) (window-frame (active-minibuffer-window)))
     (eq (frame-parameter (window-frame (active-minibuffer-window)) 'minibuffer) 'only)))

It means: display the message at the end of the active minibuffer if it is 
either on the same frame as the current window, or if it is in a 
miniwindow-only frame.

Gregory

RE: New multi-command facility displays in the wrong echo area.

[Gregory Heytings via Emacs development discussions.]

Hi Drew,

>> I just realized (thanks to Stefan's last email on this list) that my 
>> patch introduces a regression for those who (like him) use 
>> miniwindow-only frames.
>>
>> To correct that regression, ...
>>
>> display the message at the end of the active minibuffer if it is either 
>> on the same frame as the current window, or if it is in a 
>> miniwindow-only frame.
>
> That takes care of that regression, but it doesn't take care of the 
> problem for minibuffer-only frames that it aims to solve otherwise.
>
> This is another reason why echo display in the mode-line is a 
> half-measure.  I'm in the same boat as Stefan on this: I use a 
> standalone minibuffer frame.  And I don't want any `message' output 
> shown in the minibuffer.
>

I gave you a (rough) draft that shows how this can be done yesterday.  I 
copy it here again:

(progn
   (select-frame (make-frame '((minibuffer . nil) (name . "Drew's Echo Area"))))
   (set-frame-height nil 1)
   (set-frame-parameter nil 'tool-bar-lines nil)
   (set-frame-parameter nil 'menu-bar-lines nil)
   (switch-to-buffer " *Drew's Echo Area*")
   (setq-local mode-line-format nil)
   (setq cursor-in-non-selected-windows nil))

(defun set-minibuffer-message (message)
   (with-current-buffer (get-buffer " *Drew's Echo Area*")
     (setq-local inhibit-read-only t)
     (erase-buffer)
     (insert message))
   t)

It's only a rough draft, but it seems to work quite well already.

Re: New multi-command facility displays in the wrong echo area.

[Stefan Monnier]

> (or (eq (window-frame) (window-frame (active-minibuffer-window)))
>     (eq (frame-parameter (window-frame (active-minibuffer-window)) 'minibuffer) 'only)))

I think it would be cleaner (i.e. better express the intent) if it was
written something like

    (eq (mini-window-of (selected-frame))
        (active-minibuffer-window))

which may require writing `mini-window-of` first (and choosing a better
name for it along the way).


        Stefan

Re: New multi-command facility displays in the wrong echo area.

[Eli Zaretskii]

> Date: Wed, 14 Oct 2020 20:44:15 +0000
> From: Gregory Heytings <ghe@sdf.org>
> cc: acm@muc.de, monnier@iro.umontreal.ca, emacs-devel@gnu.org
> 
> I just realized (thanks to Stefan's last email on this list) that my patch 
> introduces a regression for those who (like him) use miniwindow-only 
> frames.
> 
> To correct that regression, the third condition in set-minibuffer-message:
> 
> (eq (window-frame) (window-frame (active-minibuffer-window))
> 
> should be:
> 
> (or (eq (window-frame) (window-frame (active-minibuffer-window)))
>      (eq (frame-parameter (window-frame (active-minibuffer-window)) 'minibuffer) 'only)))
> 
> It means: display the message at the end of the active minibuffer if it is 
> either on the same frame as the current window, or if it is in a 
> miniwindow-only frame.

Thanks, I fixed this with a similar change.

Re: New multi-command facility displays in the wrong echo area.

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: Eli Zaretskii <eliz@gnu.org>,  acm@muc.de,  emacs-devel@gnu.org
> Date: Wed, 14 Oct 2020 18:51:09 -0400
> 
> > (or (eq (window-frame) (window-frame (active-minibuffer-window)))
> >     (eq (frame-parameter (window-frame (active-minibuffer-window)) 'minibuffer) 'only)))
> 
> I think it would be cleaner (i.e. better express the intent) if it was
> written something like
> 
>     (eq (mini-window-of (selected-frame))
>         (active-minibuffer-window))
> 
> which may require writing `mini-window-of` first (and choosing a better
> name for it along the way).

Yes, I've used let* to avoid calling active-minibuffer-window (and
other functions) more than once.