bug#19064: 25.0.50; `message' overwrites `y-or-n-p' prompt, so user misses it

bug#19064: 25.0.50; `message' overwrites `y-or-n-p' prompt, so user misses it

[Drew Adams]

I don't have a simple recipe, but I doubt that one is needed.  If it
really is then perhaps I will come up with one.

I have some code that calls `y-or-n-p'.  Immediately after it prompts,
`Man-bgproc-sentinel' writes a message to the echo area:

(message "%s man page formatted" (Man-page-from-arguments Man-arguments))

The user thus sees only a message such as "ps man page formatted".
S?he never sees the `y-or-n' prompt.

(Yes, of course as soon as the user tries to hit a key for some reason,
s?he sees the `y-or-n-p' repeat prompt.)

Seems like this is an Emacs bug.  Seems like whenever `y-or-n-p' (or
just `read-key') is waiting for a key, `message' should do nothing.
Either it should echo its message after the key is read or (maybe
better) it should do nothing at all.  As it stands now, this seems like
a basic UI problem, not just a minor annoyance.

FWIW, the context is that I am jumping to a `man' bookmark with code
that can activate the region recorded in the bookmark (not a vanilla
`man' bookmark), and if the region has been relocated (because the
target text has changed) then the user is prompted for whether s?he
wants to save the relocated region limits back to the bookmark.  This
prompting is done by `y-or-n-p'.  But `Man-bgproc-sentinel' then comes
along and overwrites the prompt.

In GNU Emacs 25.0.50.1 (i686-pc-mingw32)
 of 2014-10-20 on LEG570
Bzr revision: 118168 rgm@gnu.org-20141020195941-icp42t8ttcnud09g
Windowing system distributor `Microsoft Corp.', version 6.1.7601
Configured using:
 `configure --enable-checking=yes,glyphs CPPFLAGS=-DGLYPH_DEBUG=1'

bug#19064: 25.0.50; `message' overwrites `y-or-n-p' prompt, so user misses it

[Lars Ingebrigtsen]

Drew Adams <drew.adams@oracle.com> writes:

> I don't have a simple recipe, but I doubt that one is needed.  If it
> really is then perhaps I will come up with one.

It would be helpful to have a recipe.

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

bug#19064: 25.0.50; `message' overwrites `y-or-n-p' prompt, so user misses it

[Drew Adams]

> It would be helpful to have a recipe.

Sorry, but recent Emacs 25 snapshots I have just crash all
the time.  I cannot use Emacs 25 for much of anything, I'm
afraid.

But I think the bug description here should be sufficient.
In particular, does this not seem appropriate to consider?

  Seems like whenever `y-or-n-p' (or just `read-key') is waiting
  for a key, `message' should do nothing.  Either it should echo
  its message after the key is read or (maybe better) it should
  do nothing at all.  As it stands now, this seems like a basic
  UI problem, not just a minor annoyance.

bug#19064: 25.0.50; `message' overwrites `y-or-n-p' prompt, so user misses it

[Michael Heerdegen]

Drew Adams <drew.adams@oracle.com> writes:

>   Seems like whenever `y-or-n-p' (or just `read-key') is waiting
>   for a key, `message' should do nothing.  Either it should echo
>   its message after the key is read or (maybe better) it should
>   do nothing at all.  As it stands now, this seems like a basic
>   UI problem, not just a minor annoyance.

I tried this here with emacs 25:

(progn
  (man "X")
  (y-or-n-p "-->"))

This stills behave as described: the prompt disappears and doesn't come
back from alone.

OTOH, a simple call to message done from within a timer doesn't behave
like this.  So this seems to be special to process sentinels, thus it's
probably a rare situation that this happens - a bit annoying
nonetheless.


Michael.

bug#19064: 25.0.50; `message' overwrites `y-or-n-p' prompt, so user misses it

[Lars Ingebrigtsen]

Michael Heerdegen <michael_heerdegen@web.de> writes:

> I tried this here with emacs 25:
>
> (progn
>   (man "X")
>   (y-or-n-p "-->"))
>
> This stills behave as described: the prompt disappears and doesn't come
> back from alone.

Yup; I get the same behaviour.  That is indeed annoying, and should be
fixed.

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

bug#17272: bug#19064: 25.0.50; `message' overwrites `y-or-n-p' prompt, so user misses it

[Lars Ingebrigtsen]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> Michael Heerdegen <michael_heerdegen@web.de> writes:
>
>> I tried this here with emacs 25:
>>
>> (progn
>>   (man "X")
>>   (y-or-n-p "-->"))
>>
>> This stills behave as described: the prompt disappears and doesn't come
>> back from alone.
>
> Yup; I get the same behaviour.  That is indeed annoying, and should be
> fixed.

The issue is, I think, a general one:  If some async code issues a
`message', then that will hide the `y-or-n' prompt (or probably any
prompt?).  I don't think it's that difficult to check for this
situation (`read-char' etc sets a flag that `message' checks?  There's
probably a mechanism in place for detecting this situation somewhere
already), but what should Emacs do?

I guess...  one possibility would be to open the echo area further and
show the message below the prompt.  (Or above.)

It is a general problem that I've been hit by a large number of times.
If it's `y-or-n', then you can get out of it by hitting something other
than y or n, but in other prompts you're basically helpless and have to
`C-g' out of it.

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

bug#19064: 25.0.50; `message' overwrites `y-or-n-p' prompt, so user misses it

[Michael Heerdegen]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> >> (progn
> >>   (man "X")
> >>   (y-or-n-p "-->"))
> >>
> >> the prompt disappears and doesn't come back from alone.

> but what should Emacs do?
>
> I guess...  one possibility would be to open the echo area further and
> show the message below the prompt.  (Or above.)

Yeah.  Or alternatively, y-or-n-p could check for this situation and
restore the prompt after a certain delay (2 or 3 seconds or so).

Regards,

Michael.

bug#17272: bug#19064: 25.0.50; `message' overwrites `y-or-n-p' prompt, so user misses it

[Lars Ingebrigtsen]

Michael Heerdegen <michael_heerdegen@web.de> writes:

> Yeah.  Or alternatively, y-or-n-p could check for this situation and
> restore the prompt after a certain delay (2 or 3 seconds or so).

Yeah, that would feel quite natural, I think.

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

bug#19064: bug#17272: bug#19064: 25.0.50; `message' overwrites `y-or-n-p' prompt, so user misses it

[Juri Linkov]

> It is a general problem that I've been hit by a large number of times.
> If it's `y-or-n', then you can get out of it by hitting something other
> than y or n, but in other prompts you're basically helpless and have to
> `C-g' out of it.

Message "Package cl is deprecated" that overwrites `y-or-n-p' prompt
issued by desktop.el could be fixed by this patch (requires another
patch from bug#38076):

diff --git a/lisp/subr.el b/lisp/subr.el
index 03cf3da278..0a8a505b70 100644
--- a/lisp/subr.el
+++ b/lisp/subr.el
@@ -4517,7 +4551,9 @@ do-after-load-evaluation
 	      (byte-compile-warn "%s" msg))
 	  (run-with-timer 0 nil
 			  (lambda (msg)
-			    (message "%s" msg))
+                            (if (minibufferp)
+                                (minibuffer-message "%s" msg)
+                              (message "%s" msg)))
                           msg)))))
 
   ;; Finally, run any other hook.

bug#17272: bug#19064: 25.0.50; `message' overwrites `y-or-n-p' prompt, so user misses it

[Lars Ingebrigtsen]

Juri Linkov <juri@linkov.net> writes:

> Message "Package cl is deprecated" that overwrites `y-or-n-p' prompt
> issued by desktop.el could be fixed by this patch (requires another
> patch from bug#38076):

[...]

> -			    (message "%s" msg))
> +                            (if (minibufferp)
> +                                (minibuffer-message "%s" msg)
> +                              (message "%s" msg)))

Wouldn't it make more sense to just have `message' behave like
`minibuffer-message' if '(minibufferp)'?  Otherwise all async code will
have to have this code snippet.

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

bug#19064: bug#17272: bug#19064: 25.0.50; `message' overwrites `y-or-n-p' prompt, so user misses it

[Drew Adams]

> > -			    (message "%s" msg))
> > +                            (if (minibufferp)
> > +                                (minibuffer-message "%s" msg)
> > +                              (message "%s" msg)))
> 
> Wouldn't it make more sense to just have `message' behave like
> `minibuffer-message' if '(minibufferp)'?  Otherwise all async code will
> have to have this code snippet.

FWIW, I disagree very much with the patch - and
with Lars's suggestion.

Both `message' and `minibuffer-message' are useful
when the minibuffer is active.  They behave very
differently, and each behavior is useful.

`message' interrupts your minibuffer dialog
temporarily (and how & how much can be controlled).
And it logs to `*Messages*' (and that can be
controlled).  Use it when it's appropriate to do
those things (particularly the interruption).

`minibuffer-message' uses the same real estate,
at the same time, as your minibuffer input.

It is definitely NOT the case that it is always
most useful for a message while the minibuffer
is active to be delivered by just appending it
to your input, and not interrupting the dialog.
___

The problem described by the bug report needs to
be solved some other way.  It has nothing to do,
necessarily, with `minibuffer-message' versus
`message'.

bug#19064: bug#17272: bug#19064: 25.0.50; `message' overwrites `y-or-n-p' prompt, so user misses it

[Juri Linkov]

>> -			    (message "%s" msg))
>> +                            (if (minibufferp)
>> +                                (minibuffer-message "%s" msg)
>> +                              (message "%s" msg)))
>
> Wouldn't it make more sense to just have `message' behave like
> `minibuffer-message' if '(minibufferp)'?  Otherwise all async code will
> have to have this code snippet.

I agree, this would make code more manageable.

But a question: after reversing the dependency should it be
customizable to get back an old behavior for Drew?

bug#17272: bug#19064: bug#17272: bug#19064: 25.0.50; `message' overwrites `y-or-n-p' prompt, so user misses it

[Lars Ingebrigtsen]

Juri Linkov <juri@linkov.net> writes:

> But a question: after reversing the dependency should it be
> customizable to get back an old behavior for Drew?

I didn't quite understand what Drew wanted (to have the prompt be
overwritten?), but if so, a user option would be trivial to add,
wouldn't it?  Like `display-messages-in-minibuffer' or something?

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

bug#17272: bug#19064: bug#17272: bug#19064: 25.0.50; `message' overwrites `y-or-n-p' prompt, so user misses it

[Drew Adams]

> > But a question: after reversing the dependency should it be
> > customizable to get back an old behavior for Drew?
> 
> I didn't quite understand what Drew wanted (to have the prompt be
> overwritten?), but if so, a user option would be trivial to add,
> wouldn't it?  Like `display-messages-in-minibuffer' or something?

I'm sorry, but I can't follow this.  I don't know
what's been changed, or why.  (There are even two
bugs that are being handled here, apparently.)

What I've said is that I object to an automatic
attempt to determine, when the minibuffer is
active, whether to realize the effect of `message'
or the effect of `minibuffer-message'.

The minibuffer can be active - or not - during
any number of other activities.  The minibuffer
is for user input, but that space is also (as
the echo area) for `message' output.

And such output - messages to the user - can,
and should be able to, be delivered while a user
is using the minibuffer for input.  Nothing wrong
with that, in general.

`message' is often, and can always be, associated
with an _interruption_: `sit-for' or `sleep-for'.
This is part of a normal UI dialog/interaction -
one kind of such interaction.

This applies also when you're using the minibuffer.
It can make sense to interrupt inputting briefly,
to deliver a message.

`message', unlike `minibuffer-message', not only
interrupts input (switching to the echo area).
By doing so it also takes over that complete space.

Yes, that hides your input temporarily - but that's
the point.  The complete space is available for a
message.  It's saying, "Forget about your inputting
for a moment, and read this important announcement."

(`message' also logs messages, which can be very
important.)

`minibuffer-message' is limited to appending to
your minibuffer input.  Much less space available.
And no interruption, no real separation from your
input (apart from the brackets).

Minibuffer input can be long and complex, even
using multiple lines.  `message' allows complete
separation of the input space from the output
space.  But yes, it separates in time, not space.
Is that bad? good?  It depends.

Consider also recursive minibuffers.  Imagine,
in fact, that the minibuffer is _always_ active.
You can continue to use Emacs normally in this
scenario.  `message' needs to work normally, as
does `minibuffer-message', regardless of whether
the minibuffer is active.

In sum, BOTH `message' and `minibuffer-message'
have their uses when the minibuffer is active.
They are _different_.  Neither is good or bad.

It is absolutely wrong - misguided - to suppose
that when the minibuffer is active all messages
should be delivered using `minibuffer-message'.

It's up to the functions that _use_ these two
output functions to DTRT.

Consider an asynchronous process trying to
deliver progress or result messages.  Should it
use the echo area?

If so, maybe `message' with a hard interruption
(`sleep-for') is appropriate.  Or maybe it's
appropriate to pop up a buffer to show the
messages.  Or maybe it's appropriate to use
`message' if the minibuffer is active or
`minibuffer-message' if not.  It all depends.

There are lots of UI and reporting possibilities.
It's up to the functions that are trying to tell
the user something to decide and do what's
appropriate.  It's not up to the minibuffer
("Am I active?") to decide.

No simple rule/condition (e.g. minibuffer is
active) can reasonably determine which output
effect should be used in a particular situation.

This BUG is about a particular scenario where
the functions that use output functions interact
badly during minibuffer input.

That's a PARTICULAR scenario.  A proper fix for
the bug is to find a solution specific to that
scenario - to coordinate or otherwise referee
among the participants that vie for the user's
attention.  Not taking account of the particular
scenario is wrong (and perhaps a cop-out).

Determine the real, problematic scenario, and
provide a remedy for that.  Don't try to elevate
this to some  general, abstract, blanket,
one-size-fits-all, hard-coded rule to finesse
messages during minibuffer input.

Analyze the real, specific problem in the
reported scenario, and provide a solution for
that.  Don't overreach.  Don't paint everything
the same color just because there's a scenario
where the color scheme is problematic.

That's my point.  Please do _not_ impose
`minibuffer-message' as a replacement for
`message' when the minibuffer is active.

Don't stop _callers_ from determining the
appropriate behavior.  If a caller uses
`message' then respect that.  If the caller
does something stupid then fix the caller.

I said (perhaps in this thread) that I have a
function, `icicle-msg-maybe-in-minibuffer',
that does this - something similar to what I
guess you have in mind imposing in some
systematic way:

  (icicle-msg-maybe-in-minibuffer FORMAT-STRING
                                  &rest ARGS)

  Display FORMAT-STRING as a message.
  If called with the minibuffer inactive, use 'message'.
  Otherwise:
   If 'icicle-minibuffer-message-ok-p', then use
      'minibuffer-message'.
   Else do nothing (no message display).

But the point is that that's just another output
function, available for use by callers.  I don't
just impose that systematically.

For some callers, using that instead of `message',
or instead of `minibuffer-message', makes sense.
For others it makes sense to just use `message'
or `minibuffer-message'.

(And you'll notice that I even provide a global
variable, `icicle-minibuffer-message-ok-p', that
can be bound to override substituting
`minibuffer-message' for `message'.)

I don't object to ever using `minibuffer-message'
in place of `message'.  I object to doing that
systematically.  I object to doing that behind
the backs of callers - let the callers decide.

Can odd or unpleasant behavior sometimes result,
due to caller behavior conflicts?  Of course.
That's rare, IME, but it can happen.  When it
does. it needs to be fixed - for that particular
scenario.

And in particular, if there's something very
important that a caller is doing - some very
important message communication, then probably
something other than `message' and other than
`minibuffer-message' is appropriate - e.g., a
popup, maybe even a modal, dialog.

Dunno whether this long reply makes clear
"what Drew wanted".  I hope it helps.
And I hope you'll reconsider the simplistic
"solution" that I think you've planned.

If I'm mistaken wrt the planned solution,
apologies.  At least I hope I've made clear my
objection to what I've thought the plan is.
Thanks for listening.

bug#19064: bug#17272: bug#19064: 25.0.50; `message' overwrites `y-or-n-p' prompt, so user misses it

[Juri Linkov]

> `message', unlike `minibuffer-message', not only
> interrupts input (switching to the echo area).
> By doing so it also takes over that complete space.
>
> Yes, that hides your input temporarily - but that's
> the point.

No, `message' hides your input not temporarily,
but permanently.  That's the problem.

And `minibuffer-message' fixes it both ways:
when the minibuffer is active, it displays the
message at the end of the minibuffer for 2 seconds.
When the minibuffer is not active, it displays
the message in the echo area for 2 seconds
(the timeout is configurable).

> (`message' also logs messages, which can be very
> important.)

`minibuffer-message' logs messages as well.

> Don't stop _callers_ from determining the
> appropriate behavior.  If a caller uses
> `message' then respect that.  If the caller
> does something stupid then fix the caller.

Callers will be able to determine the
appropriate behavior using new variable
like `display-messages-in-minibuffer'.

bug#17272: bug#19064: bug#17272: bug#19064: 25.0.50; `message' overwrites `y-or-n-p' prompt, so user misses it

[Drew Adams]

> > `message', unlike `minibuffer-message', not only
> > interrupts input (switching to the echo area).
> > By doing so it also takes over that complete space.
> >
> > Yes, that hides your input temporarily - but that's
> > the point.
> 
> No, `message' hides your input not temporarily,
> but permanently.  That's the problem.

How so, _permanently_?  That's not what I see,
ever.

Permanent hiding means your input is lost,
destroyed/irretrievable - impossible to show
again.

I've never seen `message' - or any other use of
the echo area, destroy minibuffer input.  Input
is in the minibuffer, not in the echo area.
Completely separate - by design. 

Maybe there's some particular scenario where
something that _looks_ like "permanent hiding"
seems to happen.  If so, then it's that scenario
that needs fixing.

I see zillions of uses of `message' when the
minibuffer is active, and input is never hidden
permanently.  And I don't see how it could be.

I notice the Subject line of this bug says that
`message' overwrites a prompt.  If that happens
then (1) that prompt must be in the echo area,
not the minibuffer, and (2) presumably we're not
talking about input in the minibuffer anyway.

A minibuffer prompt is not in the echo area,
so it cannot be overwritten by `message'.

Sounds like you're doing something unusual,
which doesn't really involve prompting in the
minibuffer for minibuffer input.

What's more, `y-or-n-p' doesn't use (hasn't used)
the minibuffer.  It prompts in the echo area,
and it uses `read-key', which doesn't use the
minibuffer.  That's a main feature of `y-or-n-p'
and of `read-key' - no use of the minibuffer.

So you must really be doing something unusual,
if not unkosher.  Sounds like you've painted
yourself into a corner and are now painting up
the walls.  Maybe you've dreamed up some kind
of "solution" in search of a problem, or you've
created a problem out of thin air, which then
calls for a crazy "solution".

> And `minibuffer-message' fixes it both ways:
> when the minibuffer is active, it displays the
> message at the end of the minibuffer for 2 seconds.

Display at the end of the minibuffer input is
NOT a fix.  It can't be.  I already listed
specific advantages of `message', one of which
is to interrupt your input and use the entire
echo area to display a message.

`minibuffer-message' has its own specific
advantages, and thus specific use cases.  It
does not replace `message' and its advantages.

> When the minibuffer is not active, it displays
> the message in the echo area for 2 seconds
> (the timeout is configurable).

That too is BAD.  Code should be able to control
the interruption in the standard ways: `sit-for'
and `sleep-for'.  Those allow much more control
than just a time limit for ephemeral display.

> > Don't stop _callers_ from determining the
> > appropriate behavior.  If a caller uses
> > `message' then respect that.  If the caller
> > does something stupid then fix the caller.
> 
> Callers will be able to determine the
> appropriate behavior using new variable
> like `display-messages-in-minibuffer'.

I haven't seen the code or doc.  But based on
what you say above, about your "configurable"
time limit, that doesn't sound promising, at all.

Beyond this - there's no substitute, whatever
you might cook up, for _also_ letting `message'
do what it's always done.  This is about backward
compatibility, of course, but it's about much more
than that.

If you want to add some different behavior, you're
free to add it.  But don't subtract the existing,
and very longstanding, behavior.  Add your favorite
new behavior as an _addition_, letting users opt
in to choose it, if they want.

Hopefully, any damage you're doing with this you're
doing only in Lisp, so at least I (and others) will
be able to undo it - at least by redefining things
as they were.  But it really should not come to that.
Sounds like a sad state of affairs - not happy to
see things proceed like this.

I expect a lot of damage from this, at least to my
use of Emacs and my code.  Hope I'm wrong and it's
easy to undo it.  The right thing would be for you
not to oblige anyone to do anything to retrieve the
previous (since Day One), sane behavior.  _Opt-in_,
not just willy-nilly, destruction (or progress, as
you might see it).

If you push forward with this, and if it's not
opt-in, please document explicitly how to retrieve
the previous behavior, i.e., how to opt out.

bug#17272: bug#19064: bug#17272: bug#19064: 25.0.50; `message' overwrites `y-or-n-p' prompt, so user misses it

[Michael Heerdegen]

Drew Adams <drew.adams@oracle.com> writes:

> I'm sorry, but I can't follow this.  I don't know
> what's been changed, or why.  (There are even two
> bugs that are being handled here, apparently.)

I understand your question as if you want to know whether there has some
general magic been implemented to decide where to show messages.

AFAIU the issues fixed were all special cases were a message hided some
y-or-n-p prompt so that the user may have missed the prompt, or may have
wondered what to do to get it back.

> What I've said is that I object to an automatic
> attempt to determine, when the minibuffer is
> active, whether to realize the effect of `message'
> or the effect of `minibuffer-message'.

AFAICT only the behavior for these special situations have been made a
bit more user friendly, and all other calls of message or mb-message are
uneffected (is that correct, Juri?) so that third party stuff should not
be affected.  `y-or-n-p' has been reimplemented to use
read-from-minibuffer instead of read-key, however (Juri please correct
me if I'm wrong).


Michael.

bug#19064: bug#17272: bug#19064: 25.0.50; `message' overwrites `y-or-n-p' prompt, so user misses it

[Juri Linkov]

>> I'm sorry, but I can't follow this.  I don't know
>> what's been changed, or why.  (There are even two
>> bugs that are being handled here, apparently.)
>
> I understand your question as if you want to know whether there has some
> general magic been implemented to decide where to show messages.
>
> AFAIU the issues fixed were all special cases were a message hided some
> y-or-n-p prompt so that the user may have missed the prompt, or may have
> wondered what to do to get it back.
>
>> What I've said is that I object to an automatic
>> attempt to determine, when the minibuffer is
>> active, whether to realize the effect of `message'
>> or the effect of `minibuffer-message'.
>
> AFAICT only the behavior for these special situations have been made a
> bit more user friendly, and all other calls of message or mb-message are
> uneffected (is that correct, Juri?) so that third party stuff should not
> be affected.  `y-or-n-p' has been reimplemented to use
> read-from-minibuffer instead of read-key, however (Juri please correct
> me if I'm wrong).

Yes, this is correct.

bug#17272: bug#19064: bug#17272: bug#19064: 25.0.50; `message' overwrites `y-or-n-p' prompt, so user misses it

[Drew Adams]

> AFAIU the issues fixed were all special cases were a message hided some
> y-or-n-p prompt so that the user may have missed the prompt, or may
> have wondered what to do to get it back.

I see.  So the problem is that `y-or-n-p' uses the
echo area for prompting, and `message' writes to
the echo area.  Yes, that's indeed a problem.
Sorry for not understanding that that's what we're
trying to solve.

[I still don't understand why it's said that your
minibuffer input gets permanently hidden, in that
scenario.  I suppose that if the result of your
`y-or-n-p' answer causes Emacs to quit or to kill
stuff then that could happen, but I wouldn't think
it would happen generally.  Your input is in the
minibuffer; the prompt from `y-or-n-p' is in the
echo area.]

> > What I've said is that I object to an automatic
> > attempt to determine, when the minibuffer is
> > active, whether to realize the effect of `message'
> > or the effect of `minibuffer-message'.
> 
> AFAICT only the behavior for these special situations have been made a
> bit more user friendly, and all other calls of message or mb-message
> are uneffected (is that correct, Juri?) so that third party stuff should
> not be affected.

I see.  I hope that's right.  I got the impression
that a change was being made to detect whether the
minibuffer is active, and, when so, make `message'
calls behave instead like `minibuffer-message'.
That would not be good.

Can someone please confirm that that's not the case?

> `y-or-n-p' has been reimplemented to use
> read-from-minibuffer instead of read-key, however.

I see.  That sounds like a big change, just to fix
the "special situations" you described.  And it
sounds bad, to me.

`y-or-n-p' is not the only situation where we prompt
in the echo area and read a key.

If we're really going to make big changes, wouldn't
it be better to do something different, to address
all such read-key situations - aren't they all
potentially problematic (special situations)?

Why would we want to switch such situations to read
from the minibuffer (activating it, prompting in it,
etc.)?

Reading a key (which is what this is about, IIUC)
isn't specific to any particular _input location_
(e.g. the minibuffer).

It can be relevant to the place where that action
gets initiated (to maybe pick up relevant keymaps).
But it shouldn't be associated with any particular
expected-input location.

To read a key, the prompt basically _tells_ the
the user to hit a key.  It's not looking to read
any input into a buffer - minibuffer or otherwise.

Why not instead just put the prompt in a temporary
(unselected) popup window or undecorated frame?

IMO there should be no need to give `y-or-n-p',
or any other function that reads a key,
interaction with the  minibuffer.  Just because
we need to prompt, and be sure the user sees the
prompt, that doesn't imply that we should use the
minibuffer.

No need and no reason to do that, is there?
Using the minibuffer to read a key introduces
unnecessary complexity and confusion for users.
We present an input buffer for no reason - no
text gets edited and input there.

The minibuffer is a heavy-weight UI, allowing
lots of possible interactions.  I have a hard
time believing that, just to solve the problem
you described, we would end up going down this
route.

(A key can be read anytime - whether or not
the minibuffer's active.  And it certainly
shouldn't require a recursive minibuffer if
key-reading is initiated while the minibuffer
is active for something else.)

Using the minibuffer for _output_, as does
`minibuffer-message', is generally worse, not
better, than using the echo area for output
(`message') and reserving the minibuffer for
input only.

bug#19064: bug#17272: bug#19064: 25.0.50; `message' overwrites `y-or-n-p' prompt, so user misses it

[Michael Heerdegen]

Drew Adams <drew.adams@oracle.com> writes:

> [I still don't understand why it's said that your
> minibuffer input gets permanently hidden, in that
> scenario.  I suppose that if the result of your
> `y-or-n-p' answer causes Emacs to quit or to kill
> stuff then that could happen, but I wouldn't think
> it would happen generally.  Your input is in the
> minibuffer; the prompt from `y-or-n-p' is in the
> echo area.]

You misunderstood the word "permanently": We didn't mean you can't get
the y-or-n-p prompt back but that the prompt doesn't come back from
alone without user interaction, no matter how long you wait.

> > AFAICT only the behavior for these special situations have been made a
> > bit more user friendly, and all other calls of message or mb-message
> > are uneffected (is that correct, Juri?) so that third party stuff should
> > not be affected.
>
> I see.  I hope that's right.  I got the impression
> that a change was being made to detect whether the
> minibuffer is active, and, when so, make `message'
> calls behave instead like `minibuffer-message'.
> That would not be good.
>
> Can someone please confirm that that's not the case?

I think Juri did that.


Regards,

Michael.

bug#17272: bug#19064: bug#17272: bug#19064: 25.0.50; `message' overwrites `y-or-n-p' prompt, so user misses it

[Drew Adams]

> > [I still don't understand why it's said that your
> > minibuffer input gets permanently hidden, in that
> > scenario.  I suppose that if the result of your
> > `y-or-n-p' answer causes Emacs to quit or to kill
> > stuff then that could happen, but I wouldn't think
> > it would happen generally.  Your input is in the
> > minibuffer; the prompt from `y-or-n-p' is in the
> > echo area.]
> 
> You misunderstood the word "permanently": We didn't mean you can't get
> the y-or-n-p prompt back but that the prompt doesn't come back from
> alone without user interaction, no matter how long you wait.

The statement made wasn't about the prompt.  It was
about minibuffer input.

My reply was that input is in the minibuffer,
and both `message' and `y-or-n-p' write to the
echo area (or at least they both did), so I
can't imagine how minibuffer input is lost or
"permanently hidden".

> > > AFAICT only the behavior for these special
> > > situations have been made a bit more user
> > > friendly, and all other calls of message or
> > > mb-message are uneffected (is that correct,
> > > Juri?) so that third party stuff should
> > > not be affected.
> >
> > I see.  I hope that's right.  I got the impression
> > that a change was being made to detect whether the
> > minibuffer is active, and, when so, make `message'
> > calls behave instead like `minibuffer-message'.
> > That would not be good.
> >
> > Can someone please confirm that that's not the case?
> 
> I think Juri did that.

I didn't think so - not explicitly.  He confirmed
your "AFAICT only the behavior..." description, but
also your statement that "`y-or-n-p' has been
reimplemented to use read-from-minibuffer instead of
read-key" statement. (Or perhaps just one of those?)

There are mentions in this thread (and others?) of
`minibuffer-message' being used in place of `message'
when the minibuffer is active.  So it's still not
clear to me that such a change is not being made.

And I disagreed that `y-or-n-p' should read from
the minibuffer instead of reading a key.  I guessed
that the problem that that tries to solve should
still exist for all uses of `read-key' that issue
a prompt (which is probably all uses of it).  No?

A general statement that "third party stuff should
not be affected" is great, as far as it goes.  But
I guess I'll just have to wait till Emacs 27 to see
the devil in the details.

bug#17272: bug#19064: bug#17272: bug#19064: 25.0.50; `message' overwrites `y-or-n-p' prompt, so user misses it

[Michael Heerdegen]

Drew Adams <drew.adams@oracle.com> writes:

> My reply was that input is in the minibuffer,
> and both `message' and `y-or-n-p' write to the
> echo area (or at least they both did), so I
> can't imagine how minibuffer input is lost or
> "permanently hidden".

Ah, ok.  I think the posters just confused minibuffer and echo area for
the case of y-or-n-p then (at least did I).

> > > Can someone please confirm that that's not the case?
> >
> > I think Juri did that.
>
> I didn't think so - not explicitly.  He confirmed
> your "AFAICT only the behavior..." description, but
> also your statement that "`y-or-n-p' has been
> reimplemented to use read-from-minibuffer instead of
> read-key" statement. (Or perhaps just one of those?)
>
> There are mentions in this thread (and others?) of
> `minibuffer-message' being used in place of `message'
> when the minibuffer is active.

Yes - in the reported situations, not generally...maybe someone could
send Drew an accumulated diff of all changes or so?

> And I disagreed that `y-or-n-p' should read from
> the minibuffer instead of reading a key.

I guess this can be debated - I don't have an opinion so far.


Michael.

bug#19064: bug#17272: bug#19064: 25.0.50; `message' overwrites `y-or-n-p' prompt, so user misses it

[Drew Adams]

> > My reply was that input is in the minibuffer,
> > and both `message' and `y-or-n-p' write to the
> > echo area (or at least they both did), so I
> > can't imagine how minibuffer input is lost or
> > "permanently hidden".
> 
> Ah, ok.  I think the posters just confused minibuffer and echo area for
> the case of y-or-n-p then (at least did I).

That's easy to do.  But the statement wasn't just
about the minibuffer when echo area was meant, or
vice versa.  The claim was that _user input_ (not
a prompt) became permanently hidden.

bug#19064: bug#17272: bug#19064: 25.0.50; `message' overwrites `y-or-n-p' prompt, so user misses it

[Michael Heerdegen]

Drew Adams <drew.adams@oracle.com> writes:

> > Ah, ok.  I think the posters just confused minibuffer and echo area for
> > the case of y-or-n-p then (at least did I).
>
> That's easy to do.  But the statement wasn't just
> about the minibuffer when echo area was meant, or
> vice versa.  The claim was that _user input_ (not
> a prompt) became permanently hidden.

I don't know if that was also a mistake or really meant like that.

Michael.

bug#19064: bug#17272: bug#19064: 25.0.50; `message' overwrites `y-or-n-p' prompt, so user misses it

[Juri Linkov]

>> That's easy to do.  But the statement wasn't just
>> about the minibuffer when echo area was meant, or
>> vice versa.  The claim was that _user input_ (not
>> a prompt) became permanently hidden.
>
> I don't know if that was also a mistake or really meant like that.

This is not a mistake.  Permanently hidden user input
is a serious problem and security threat.

Today I started compilation, then in a Dired buffer
requested files deletion that displayed the prompt:

  Delete D [54 files] (y or n)

But before I had a chance to answer the prompt, compilation finished
and obscured the prompt with this message permanently:

  Compilation finished

So I forgot about what was in the prompt :-(

Since Drew doesn't want to improve safety to cover all such cases,
we need to address these issues one by one, so here is the next patch:

diff --git a/lisp/progmodes/compile.el b/lisp/progmodes/compile.el
index 5a3386f227..101e294557 100644
--- a/lisp/progmodes/compile.el
+++ b/lisp/progmodes/compile.el
@@ -2265,7 +2265,8 @@ compilation-handle-exit
                  (msg (format "%s %s" mode-name
                               (replace-regexp-in-string "\n?$" ""
                                                         (car status)))))
-             (message "%s" msg)
+             (with-current-buffer (window-buffer (old-selected-window))
+               (minibuffer-message "%s" msg))
              (propertize out-string
                          'help-echo msg
                          'face (if (> exit-status 0)

bug#19064: bug#17272: bug#19064: 25.0.50; `message' overwrites `y-or-n-p' prompt, so user misses it

[Michael Heerdegen]

Juri Linkov <juri@linkov.net> writes:

> >> That's easy to do.  But the statement wasn't just
> >> about the minibuffer when echo area was meant, or
> >> vice versa.  The claim was that _user input_ (not
> >> a prompt) became permanently hidden.
> >
> > I don't know if that was also a mistake or really meant like that.
>
> This is not a mistake.  Permanently hidden user input
> is a serious problem and security threat.
>
> Today I started compilation, then in a Dired buffer
> requested files deletion that displayed the prompt:
>
>   Delete D [54 files] (y or n)
>
> But before I had a chance to answer the prompt, compilation finished
> and obscured the prompt with this message permanently:
>
>   Compilation finished
>
> So I forgot about what was in the prompt :-(
>
> Since Drew doesn't want to improve safety to cover all such cases,
> we need to address these issues one by one [...]

That's nearly impossible to do, and once you are done, new cases will
likely be introduced in the future.  Drew, how would you address this
class of problems?


Michael.

bug#19064: bug#17272: bug#19064: bug#17272: bug#19064: 25.0.50; `message' overwrites `y-or-n-p' prompt, so user misses it

[Drew Adams]

> > >>> I think the posters just confused minibuffer
> > >>> and echo area for the case of y-or-n-p then
> > >>> (at least did I).
> > >>
> > >> That's easy to do.  But the statement wasn't just
> > >> about the minibuffer when echo area was meant, or
> > >> vice versa.  The claim was that _user input_ (not
> > >> a prompt) became permanently hidden.
> > >
> > > I don't know if that was also a mistake or really
> > > meant like that.
> >
> > This is not a mistake.

So you're saying it wasn't a mistake for you to say
that _user input_ (not a prompt) is permanently
hidden?

In that case, what's the scenario where user input
is permanently hidden?

My claim was that I don't see how it can happen that
your input in the minibuffer becomes permanently
hidden.  Michael guessed that you maybe meant that a
prompt, not user input, becomes hidden.  But it seems
that's not the case, so please provide a recipe for
the permanent hiding of your input.

> > Permanently hidden user input is a serious
> > problem and security threat.

I'd agree with that, of course - it can be.

> > Today I started compilation, then in a Dired buffer
> > requested files deletion that displayed the prompt:
> >
> >   Delete D [54 files] (y or n)
> >
> > But before I had a chance to answer the prompt,
> > compilation finished and obscured the prompt 

See, now we're back to talking about the _prompt_,
_not user input_ being obscured, right?

The prompt is sent to the echo area.  At least I
think it is.  I thought it was also logged in
`*Messages*', but I don't see it there.  Perhaps
that happens only when the writing to the echo
area uses an explicit call to `message'?

In any case, I don't think it's in the minibuffer.

If you have input in the minibuffer then it should
still be there, after that prompting.  I'm guessing
that `y-or-n-p' is being used.  That function calls
`read-key', which calls `read-key-sequence-vector',
a C function.  Apparently the prompt doesn't get
logged in `*Messages*' - I don't know why.

> > with this message permanently: Compilation finished

Yes, a subsequent message to the echo area can
wipe out a message (in this case a prompt) that
was there.

I'd hope that both messages (the `y-or-n-p' prompt
and the "Compilation finished" message) would be in
`*Messages*', at least.  Doesn't seem good, to me,
that that doesn't seem to be the case.

Not that it would be enough, to solve the problem
described, just to log both messages in `*Messages*'.
But at least that would mean that the prompt would
not be permanently lost.  It would anyway be lost
from the echo area, however - yes.

> > So I forgot about what was in the prompt :-(

I agree that this is an unfortunate scenario.  I
don't want it to happen any more than you do.

But what exactly is the recipe? How was it that
you "requested files deletion that displayed the
prompt" that you show?

I'm using Emacs 26.3.  `dired-do-flagged-delete'
shows `Delete D [54 files] (yes or no)'.  It sounds
like you've maybe set `dired-deletion-confirmer' to
`y-or-n-p'?  (It's default value is `yes-or-no-p'.)

If you had seen `(yes or no)' then you would be
using the minibuffer.  And if you had started to
type, say, `ye' for `yes', then your minibuffer
input would have been obscured only temporarily by
the compilation message.

And the prompt would not have been lost from the
echo area by replacement by a subsequent message
from the compilation process, because `yes-or-no-p'
prompts in the minibuffer, not in the echo area.

If you're using `y-or-n-p' then the problem has
nothing at all to do with the minibuffer, AFAIK.

Unlike `yes-or-no-p', which uses the minibuffer,
`y-or-n-p' prompts using the echo area.  And in
that case the compilation message wipes out the
`y-or-n-p' prompt.

I would think that the first step toward a fix
would be to make sure that the `y-or-n-p' prompt
at least gets logged in `*Messages*'.  (I thought
it would be - I'm surprised.)

But of course that doesn't solve the real problem.

The problem, IIUC, is that messages to the echo
area can wipe out earlier messages there.  And
`y-or-n-p', which uses the echo area for its
"prompt", is (unfortunately, IMO) being used in
your case for an important operation that destroys
data (deletes files).  The default is `yes-or-no-p'
for `dired-deletion-confirmer' for a good reason.

So what's the solution, for multiple writes to the
echo area, including perhaps by async processes?

Using the echo area for a "prompt" is, IMO, not a
great idea.  It's OK for some operations, but not
for something delicate/critical.  Users and code
should not depend on a `y-or-n-p' interaction for
something important.

It's not just about writing a prompt to the echo
area.  The `y-or-n-p' - or any other `read-key'
interaction, is hardly atomic, i.e., modal.

`yes-or-no-p' and other minibuffer interactions
aren't atomic either, but they really don't have
the problem you raised.

(And that's why I responded as I did.  I thought
you were talking about a use of the minibuffer
and losing minibuffer input.)

I made a suggestion in this thread, to present
the `read-key' prompt, e.g. in the case where
you use `y-or-n-p', not in the echo area (danger),
but in a pop-up window:

  To read a key, the prompt basically _tells_ the
  the user to hit a key.  It's not looking to read
  any input into a buffer - minibuffer or otherwise.

  Why not instead just put the prompt in a temporary
  (unselected) popup window or undecorated frame?

And it's possible to use a modal dialog that
keeps the prompt visible until you end/dismiss
the dialog.

One possibility is to add the prompt to the
window that pops up to list the files to be
deleted.

IIUC, the general problem you present is this:

1. You are prompted in the echo area.
2. An async process writes a message to the
   echo area, wiping out the prompt from #1.

That's to be avoided, first of all, IMO.  That
would be the first "fix" - don't do that.

Maybe dialogs should never prompt in the echo area.
Maybe they should instead open a window for the
needed interaction, including the prompt.  Maybe
they should be modal in some cases.

So what about use of the minibuffer as such a
window for a dialog?  For most uses it's fine.
If it had been used in this case, e.g., if the
default value of `dired-deletion-confirmer'
(`yes-or-no-p') were used, then I don't think
you would have had your problem.

Yes, your minibuffer interaction would have
been interrupted by the echo area, to show the
compilation message.  But the prompt and your
partial input would have been restored after
a brief delay, when the minibuffer was again
shown in place of the echo area.

I said "for most uses it's fine."  That does
not mean that the minibuffer is always the
ideal way to realize a prompt-and-read-reply
dialog.  For something critical a modal dialog
could be appropriate.

What about the compilation-finished message?
Maybe that shouldn't just plop down in the echo
area.  IOW, maybe there's some responsibility
here for async operations that report status,
to use another method - something that won't
interfere with the echo area.

There are no doubt other ways to try to deal
with your problem.  But I disagree with either
of the following approaches.  (It's still not
clear to me whether you're trying to do either
of these, but that's been my impression at some
points of this discussion.)

1. Make `y-or-n-p' use the minibuffer.
2. Make `message' turn into `minibuffer-message'
   whenever the minibuffer is active.

I've spoken to both of those.  I don't want to
bore you by repeating a lot, but if you want to
talk more about those then I will.

Summary about them (my opinion):

1. The minibuffer is generally not the place to
read a single character or a key.  It's a buffer
for editing and entering multi-char input.

`y-or-n-p' and other functions that use `read-key'
and similar have good use cases, based on their
advantages, i.e., on their specific behavior.

They do not involve entering text and sending it
by hitting RET.  They're not associated with any
particular window or buffer, with respect to the
user input.  The input action is to just hit a key.

That's their advantage - and their disadvantage.

And yes, they prompt in the echo area (AFAIK),
which is not so great.  We could consider letting
them, alternatively, prompt somewhere else, such
as in a popup.

2. During a minibuffer interaction (i.e., when
the minibuffer is active) all kinds of things
can go on.  That includes recursive minibuffers,
popping up and selecting other windows, using
the echo area for temporal messages - anything
at all, really.

In particular, `message' can be useful when the
minibuffer is active.  So can `minibuffer-message'.
Both are useful; neither replaces the other. 

> > Since Drew doesn't want to improve safety
> > to cover all such cases,

Right; that's a fair thing to say, Juri.  Drew
doesn't want safety.  Drew wants you to lose
your data.

Sheesh.  Where do you get off saying such things?

I spoke only to #1 and #2 above.  Please do not
make `y-or-n-p' read from the minibuffer, and
please do not, when the minibuffer is active,
force `message' to do what `minibuffer-message'
does.  I don't know if either is something you're
trying to do, but both of those would be super
misguided, IMO.  And unnecessary.

> > we need to address these issues one by one [...]
> 
> That's nearly impossible to do, and once you are done,
> new cases will likely be introduced in the future.
> Drew, how would you address this class of problems?

See above.  Hope it helps.  I don't claim to have
all the answers, and I might not understand the
problem well.  But I'm pretty sure that #1 and #2
above are not good.

* Don't use `y-or-n-p' for something important.

* Async operations should maybe not report simply
  by writing to the echo area, since: (1) it shares
  real estate with the minibuffer, and writing to
  it can interrupt a user interaction there; and 
  (2) it can overwrite other messages to the echo
  area (including from other async operations).

* Maybe some important interactions should be modal,
  i.e., more or less blocking you from doing other
  things till the modal interaction is done; and
  maybe blocking reception of some async report
  messages.  (They shouldn't block `C-g', though.)

I'm not the one changing anything.  If you leave
the default value of `dired-deletion-confirmer' as
`yes-or-no-p' then I don't think you'll have the
problem you reported and are trying to fix.  I'm
not saying that there isn't a general potential
problem, but I don't think it's where you said it is.

I'm not the one changing anything.  But those
who are should maybe come up with suggestions -
for general discussion.

Why would this kind of thing be done in a bug
thread (several bug threads?) but at the same
time try to handle a general problem in a
general way?  Why wouldn't it instead be brought
up at emacs-devel, where lots of informed people
can speak to it?

Emacs 27 isn't released yet.  I have a recent
snapshot now, but it doesn't show lots of things
that have apparently been changed recently.  It's
frustrating to get a new Emacs release and find
that lots of stuff that's always worked is broken
because someone implemented what they thought was
an improvement.  Such things should generally be
added as new, optional features, not just replace
longstanding behavior.

IMHO, the minibuffer ain't broke, and likewise
`message' and the echo area.  Can there be bad
use cases, problems that we can identify?  Sure.
But let's not throw out the baby with the bath
water.  Before changing something like `y-or-n-p'
or `message' (again, I'm not sure that's what
you're doing - not clear to me), why not bring
it up for general discussion?

bug#17272: bug#19064: bug#17272: bug#19064: 25.0.50; `message' overwrites `y-or-n-p' prompt, so user misses it

[Juri Linkov]

> So you're saying it wasn't a mistake for you to say
> that _user input_ (not a prompt) is permanently
> hidden?

The minibuffer is composed of both the prompt and user input.
Both the prompt and user input are hidden permanently
by the message covering the whole minibuffer.

> If you had seen `(yes or no)' then you would be
> using the minibuffer.  And if you had started to
> type, say, `ye' for `yes', then your minibuffer
> input would have been obscured only temporarily by
> the compilation message.

Not temporarily, but permanently.

> Using the echo area for a "prompt" is, IMO, not a
> great idea.

I agree, this is why using the minibuffer is better.

bug#19064: bug#17272: bug#19064: bug#17272: bug#19064: 25.0.50; `message' overwrites `y-or-n-p' prompt, so user misses it

[Drew Adams]

> > So you're saying it wasn't a mistake for you to say
> > that _user input_ (not a prompt) is permanently
> > hidden?
> 
> The minibuffer is composed of both the prompt and user input.
> Both the prompt and user input are hidden permanently
> by the message covering the whole minibuffer.

It was about `y-or-n-p', which, I repeat, does NOT
use the minibuffer.  It prompts in the echo area,
and it calls `read-key', which does not read textual
input from anywhere - certainly not the minibuffer.

You are doubling down, but you haven't yet provided
any recipe that shows that user input gets hidden
permanently.  The only thing you've shown is that
an echo-area prompt can be overwritten, and so be
lost, by subsequent echo-area output (such as from
`message').  And that's just what the original bug
reports reported in the first place!

Still, you repeat that user input is permanently
hidden.  Please show how.

> > If you had seen `(yes or no)' then you would be
> > using the minibuffer.  And if you had started to
> > type, say, `ye' for `yes', then your minibuffer
> > input would have been obscured only temporarily by
> > the compilation message.
> 
> Not temporarily, but permanently.

Not when I follow your recipe.  And not even if I
redefine `dired-deletion-confirmer' as `y-or-n-p'.

I guess you've indirectly confirmed that you did
redefine `dired-deletion-confirmer' as `y-or-n-p'?
Otherwise, how is it that you saw `(y or n)' and
not `(yes or no)'?

But if you did that then the `y-or-n-p' prompt
would be sent to the echo area; it would not be
used in the minibuffer.  The minibuffer wouldn't
be involved in your recipe at all.

On the other hand, you now seem to be indirectly
saying that you did see `(yes or no)'.  Is that
it?  Just what is your recipe?  Please start from,
say, `emacs -Q' with, say, Emacs 26.3.

Writing to the echo area does not affect minibuffer
input.  And it does not exit the minibuffer.  It
obscures minibuffer input _temporarily_, until you
hit a key, for example.

AFAIK, this is just a fact.  I know of no possibility
that allows writing to the echo area to lose your
minibuffer input or hide it permanently.

For a write to the echo area to do that, the echo
area would need to permanently hide the minibuffer.
I don't see that happening.

So no, I disagree with a claim that minibuffer
input is permanently hidden.  Until you can show
a recipe to reproduce that.

> > Using the echo area for a "prompt" is, IMO, not a
> > great idea.
> 
> I agree, this is why using the minibuffer is better.

Yes.  But only when it makes sense to use the
minibuffer. That's generally not the case for
reading a single char or a key sequence.  We have
`read-char' and `read-key' for a reason.

The minibuffer is not the best UI for every
interaction.  (And that's coming from someone who
uses the minibuffer for more than most people do.)

Is your plan to make `read-key' and such use the
minibuffer?  I _really_ hope not.  And I hope you
won't do that to `y-or-n-p'.

As I acknowledged - and as I reported originally
in bug #19064, there _is_ a problem with prompting
in the echo area, which is what `y-or-n-p' does
(likewise, other functions that call things like
`read-key').

I mentioned some possible remedies for that
in my previous mail (and before that).  And I
mentioned a different remedy in my original
report for #19064.

And the remedy I suggested in the #19064 report
was apparently the same one given by the OP of
#17272.  We both suggested, independently, that
`message' be made to hold off, if some dialog is
in progress that uses the echo area for a prompt
and that reads a char/key.

And Michael suggested another approach, also
reasonable.

Just what the right fix is for those two merged
bugs can be discussed.  But neither involves the
minibuffer.

And neither should be "fixed" by making it involve
the minibuffer.  And AFAICT, any discussion of the
minibuffer in the context of these two bugs is just
a distraction or obfuscation.

The problem is this: losing an echo-area prompt by
`y-or-n-p' because of a subsequent write to the
echo area, in particular by `message'.

The problem reported by these two bugs has nothing
whatsoever to do with the minibuffer, AFAIK.

Why you introduced the minibuffer into this, I don't
know.  If there's another bug, which involves the
minibuffer (e.g., input loss or permanent hiding
in some way), then maybe file a bug report for that?
This bug - these 2 merged bugs, are not about the
minibuffer.  Or if you really think they are, please
explain how.

bug#17272: bug#19064: bug#17272: bug#19064: 25.0.50; `message' overwrites `y-or-n-p' prompt, so user misses it

[Lars Ingebrigtsen]

Juri Linkov <juri@linkov.net> writes:

> But before I had a chance to answer the prompt, compilation finished
> and obscured the prompt with this message permanently:
>
>   Compilation finished
>
> So I forgot about what was in the prompt :-(

Yeah, it's a problem all over the place.

> Since Drew doesn't want to improve safety to cover all such cases,
> we need to address these issues one by one, so here is the next patch:

Drew doesn't have very powers.  I say go ahead and make the change in
`message' (with a variable that can be used to force `message' to not
behave like `minibuffer-message').

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

bug#19064: bug#17272: bug#19064: 25.0.50; `message' overwrites `y-or-n-p' prompt, so user misses it

[Lars Ingebrigtsen]

Juri Linkov <juri@linkov.net> writes:

> But before I had a chance to answer the prompt, compilation finished
> and obscured the prompt with this message permanently:
>
>   Compilation finished
>
> So I forgot about what was in the prompt :-(

Yeah, it's a problem all over the place.

> Since Drew doesn't want to improve safety to cover all such cases,
> we need to address these issues one by one, so here is the next patch:

Drew doesn't have veto powers.  I say go ahead and make the change in
`message' (with a variable that can be used to force `message' to not
behave like `minibuffer-message').

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

bug#17272: bug#19064: bug#17272: bug#19064: 25.0.50; `message' overwrites `y-or-n-p' prompt, so user misses it

[Juri Linkov]

>> But before I had a chance to answer the prompt, compilation finished
>> and obscured the prompt with this message permanently:
>>
>>   Compilation finished
>>
>> So I forgot about what was in the prompt :-(
>
> Yeah, it's a problem all over the place.
>
>> Since Drew doesn't want to improve safety to cover all such cases,
>> we need to address these issues one by one, so here is the next patch:
>
> Drew doesn't have veto powers.  I say go ahead and make the change in
> `message' (with a variable that can be used to force `message' to not
> behave like `minibuffer-message').

Yes, I believe a new variable would make Drew happy.

bug#17272: bug#19064: bug#17272: bug#19064: 25.0.50; `message' overwrites `y-or-n-p' prompt, so user misses it

[Juri Linkov]

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

>>> But before I had a chance to answer the prompt, compilation finished
>>> and obscured the prompt with this message permanently:
>>>
>>>   Compilation finished
>>>
>>> So I forgot about what was in the prompt :-(
>>
>> Yeah, it's a problem all over the place.
>>
>>> Since Drew doesn't want to improve safety to cover all such cases,
>>> we need to address these issues one by one, so here is the next patch:
>>
>> Drew doesn't have veto powers.  I say go ahead and make the change in
>> `message' (with a variable that can be used to force `message' to not
>> behave like `minibuffer-message').
>
> Yes, I believe a new variable would make Drew happy.

The variable name is ‘message-in-echo-area’.  After a little testing,
it seems to handle all such cases well:


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: message-in-echo-area.patch --]
[-- Type: text/x-diff, Size: 3725 bytes --]

diff --git a/lisp/minibuffer.el b/lisp/minibuffer.el
index 6e72eb73f9..7e74fa1ffb 100644
--- a/lisp/minibuffer.el
+++ b/lisp/minibuffer.el
@@ -712,16 +712,16 @@ minibuffer-message
       (progn
         (if args
             (apply #'message message args)
-          (message "%s" message))
+          (message-in-echo-area "%s" message))
         (prog1 (sit-for (or minibuffer-message-timeout 1000000))
-          (message nil)))
+          (message-in-echo-area nil)))
     ;; Record message in the *Messages* buffer
     (let ((inhibit-message t))
       (if args
           (apply #'message message args)
-        (message "%s" message)))
+        (message-in-echo-area "%s" message)))
     ;; Clear out any old echo-area message to make way for our new thing.
-    (message nil)
+    (message-in-echo-area nil)
     (setq message (if (and (null args)
                            (string-match-p "\\` *\\[.+\\]\\'" message))
                       ;; Make sure we can put-text-property.
diff --git a/src/editfns.c b/src/editfns.c
index 8fc866d391..a1e3fb1fa5 100644
--- a/src/editfns.c
+++ b/src/editfns.c
@@ -2877,6 +2877,49 @@ Fmessage
 
 usage: (message FORMAT-STRING &rest ARGS)  */)
   (ptrdiff_t nargs, Lisp_Object *args)
+{
+  if (NILP (Vmessage_in_echo_area)
+      && !(NILP (args[0]) || (STRINGP (args[0]) && SBYTES (args[0]) == 0))
+      && WINDOW_LIVE_P (Fold_selected_window ())
+      && BUFFERP (Fwindow_buffer (Fold_selected_window ()))
+      && !NILP (Fminibufferp (Fwindow_buffer (Fold_selected_window ()))))
+    {
+      ptrdiff_t count = SPECPDL_INDEX ();
+
+      /* Avoid possible recursion.  */
+      specbind (Qmessage_in_echo_area, Qt);
+
+      record_unwind_current_buffer ();
+      Fset_buffer (Fwindow_buffer (Fold_selected_window ()));
+
+      return unbind_to (count, CALLN (Fapply, intern ("minibuffer-message"),
+                                      Flist (nargs, args)));
+    }
+  else
+    return Fmessage_in_echo_area (nargs, args);
+}
+
+DEFUN ("message-in-echo-area", Fmessage_in_echo_area, Smessage_in_echo_area, 1, MANY, 0,
+       doc: /* Display a message at the bottom of the screen.
+The message also goes into the `*Messages*' buffer, if `message-log-max'
+is non-nil.  (In keyboard macros, that's all it does.)
+Return the message.
+
+In batch mode, the message is printed to the standard error stream,
+followed by a newline.
+
+The first argument is a format control string, and the rest are data
+to be formatted under control of the string.  Percent sign (%), grave
+accent (\\=`) and apostrophe (\\=') are special in the format; see
+`format-message' for details.  To display STRING without special
+treatment, use (message-in-echo-area "%s" STRING).
+
+If the first argument is nil or the empty string, the function clears
+any existing message; this lets the minibuffer contents show.  See
+also `current-message'.
+
+usage: (message-in-echo-area FORMAT-STRING &rest ARGS)  */)
+  (ptrdiff_t nargs, Lisp_Object *args)
 {
   if (NILP (args[0])
       || (STRINGP (args[0])
@@ -4520,6 +4563,11 @@ syms_of_editfns (void)
 it to be non-nil.  */);
   binary_as_unsigned = false;
 
+  DEFVAR_LISP ("message-in-echo-area", Vmessage_in_echo_area,
+	       doc: /* Non-nil means overwrite the minibuffer with a message in the echo area.  */);
+  Vmessage_in_echo_area = Qnil;
+  DEFSYM (Qmessage_in_echo_area, "message-in-echo-area");
+
   defsubr (&Spropertize);
   defsubr (&Schar_equal);
   defsubr (&Sgoto_char);
@@ -4594,6 +4642,7 @@ syms_of_editfns (void)
   defsubr (&Semacs_pid);
   defsubr (&Ssystem_name);
   defsubr (&Smessage);
+  defsubr (&Smessage_in_echo_area);
   defsubr (&Smessage_box);
   defsubr (&Smessage_or_box);
   defsubr (&Scurrent_message);

bug#17272: bug#19064: bug#17272: bug#19064: 25.0.50; `message' overwrites `y-or-n-p' prompt, so user misses it

[Lars Ingebrigtsen]

Juri Linkov <juri@linkov.net> writes:

> The variable name is ‘message-in-echo-area’.  After a little testing,
> it seems to handle all such cases well:

I have not tested the patch, but it looks good to me.  Tiny comment:

>  usage: (message FORMAT-STRING &rest ARGS)  */)
>    (ptrdiff_t nargs, Lisp_Object *args)
> +{
> +  if (NILP (Vmessage_in_echo_area)

The doc string of `message' (and documentation) should mention this
variable, and this should also be mentioned in NEWS.

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

bug#19064: bug#17272: bug#19064: bug#17272: bug#19064: 25.0.50; `message' overwrites `y-or-n-p' prompt, so user misses it

[João Távora]

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

Hello everyone,

I can't confirm 100% if this is the right bug to report this to, but the
recent changes by Juri, which make yes-or-no-p use the minibuffer for
reading,  break fido-mode's icomplete-magic-kill command (apologies if
that's not the exact name).

That command prompts the user for confirmation before attempting a file
deletion or buffer kill. This is done inside the minibuffer.

I haven't followed the whole discussion so I don't know if you're aware of
this problem. Either way, is there an alternative for modes such as
fido-mode?

Thanks,
João

On Tue, Nov 19, 2019, 08:14 Lars Ingebrigtsen <larsi@gnus.org> wrote:

> Juri Linkov <juri@linkov.net> writes:
>
> > The variable name is ‘message-in-echo-area’.  After a little testing,
> > it seems to handle all such cases well:
>
> I have not tested the patch, but it looks good to me.  Tiny comment:
>
> >  usage: (message FORMAT-STRING &rest ARGS)  */)
> >    (ptrdiff_t nargs, Lisp_Object *args)
> > +{
> > +  if (NILP (Vmessage_in_echo_area)
>
> The doc string of `message' (and documentation) should mention this
> variable, and this should also be mentioned in NEWS.
>
> --
> (domestic pets only, the antidote for overdose, milk.)
>    bloggy blog: http://lars.ingebrigtsen.no
>
>
>
>

[-- Attachment #2: Type: text/html, Size: 2015 bytes --]

bug#17272: bug#19064: bug#17272: bug#19064: bug#17272: bug#19064: 25.0.50; `message' overwrites `y-or-n-p' prompt, so user misses it

[Juri Linkov]

> I can't confirm 100% if this is the right bug to report this to, but
> the recent changes by Juri, which make yes-or-no-p use the minibuffer
> for reading, break fido-mode's icomplete-magic-kill command
> (apologies if that's not the exact name).

Please provide step-by-step recipe, it's hard to see what is wrong.
I tried everything, and don't see anything unusual.

bug#17272: bug#19064: bug#17272: bug#19064: bug#17272: bug#19064: 25.0.50; `message' overwrites `y-or-n-p' prompt, so user misses it

[João Távora]

On Tue, Nov 19, 2019 at 11:20 PM Juri Linkov <juri@linkov.net> wrote:
>
> > I can't confirm 100% if this is the right bug to report this to, but
> > the recent changes by Juri, which make yes-or-no-p use the minibuffer
> > for reading, break fido-mode's icomplete-magic-kill command
> > (apologies if that's not the exact name).
>
> Please provide step-by-step recipe, it's hard to see what is wrong.
> I tried everything, and don't see anything unusual.

Sorry Juri, I was reporting from my mobile phone.

An easy recipe:

Emacs -Q
M-x fido-mode
(defalias 'yes-or-no-p 'y-or-n-p) ;; a common custmization
C-x b
C-k ;; to kill the Messages buffer

Before your changes to `y-or-n-p` this worked well, afterwards
I get the "Attempt to use minibuffer inside minibuffer" error.

Bear in mind that fido-mode is very new. Also bear in mind
that the problem is already present when yes-or-no-p is used.

I think a good fix is for icomplete to do this (and for
you to do nothing :-) )

diff --git a/lisp/icomplete.el b/lisp/icomplete.el
index 8410ca5c3e..bf1d69a4c5 100644
--- a/lisp/icomplete.el
+++ b/lisp/icomplete.el
@@ -241,6 +241,8 @@ icomplete-fido-kill
              (category (alist-get 'category (cdr md)))
              (all (completion-all-sorted-completions))
              (thing (car all))
+             (enable-recursive-minibuffers t)
+             (icomplete-mode nil)
              (action
               (pcase category
                 (`buffer

WDYT?
João

bug#17272: bug#19064: bug#17272: bug#19064: bug#17272: bug#19064: 25.0.50; `message' overwrites `y-or-n-p' prompt, so user misses it

[Juri Linkov]

> Emacs -Q
> M-x fido-mode
> (defalias 'yes-or-no-p 'y-or-n-p) ;; a common custmization
> C-x b
> C-k ;; to kill the Messages buffer
>
> Before your changes to `y-or-n-p` this worked well, afterwards
> I get the "Attempt to use minibuffer inside minibuffer" error.
>
> Bear in mind that fido-mode is very new. Also bear in mind
> that the problem is already present when yes-or-no-p is used.
>
> I think a good fix is for icomplete to do this (and for
> you to do nothing :-) )

It's tempting to do nothing :-), but since the problem is
already present with yes-or-no-p too, it should be fixed
because it's a general problem affecting other commands too.

The nil value of enable-recursive-minibuffers by default was intended
to avoid confusion for beginners unadvisedly typing such sequences as
M-x M-x M-x M-x M-x ... to get out from which is not easy.

But for yes/no or y/n questions it should be right to
allow recursive minibuffers temporarily:

diff --git a/lisp/subr.el b/lisp/subr.el
index 20daed623f..2265965c60 100644
--- a/lisp/subr.el
+++ b/lisp/subr.el
@@ -2847,6 +2848,7 @@ y-or-n-p
      (t
       (setq prompt (funcall padded prompt))
       (let* ((empty-history '())
+             (enable-recursive-minibuffers t)
              (str (read-from-minibuffer
                    prompt nil
                    (make-composed-keymap y-or-n-p-map query-replace-map)
diff --git a/src/fns.c b/src/fns.c
index cbb6879223..3ae3192b3d 100644
--- a/src/fns.c
+++ b/src/fns.c
@@ -2805,15 +2805,18 @@ DEFUN ("yes-or-no-p", Fyes_or_no_p, Syes_or_no_p, 1, 1, 0,
   AUTO_STRING (yes_or_no, "(yes or no) ");
   prompt = CALLN (Fconcat, prompt, yes_or_no);
 
+  ptrdiff_t count = SPECPDL_INDEX ();
+  specbind (Qenable_recursive_minibuffers, Qt);
+
   while (1)
     {
       ans = Fdowncase (Fread_from_minibuffer (prompt, Qnil, Qnil, Qnil,
 					      Qyes_or_no_p_history, Qnil,
 					      Qnil));
       if (SCHARS (ans) == 3 && !strcmp (SSDATA (ans), "yes"))
-	return Qt;
+	return unbind_to (count, Qt);
       if (SCHARS (ans) == 2 && !strcmp (SSDATA (ans), "no"))
-	return Qnil;
+	return unbind_to (count, Qnil);
 
       Fding (Qnil);
       Fdiscard_input ();

bug#17272: bug#19064: bug#17272: bug#19064: bug#17272: bug#19064: 25.0.50; `message' overwrites `y-or-n-p' prompt, so user misses it

[João Távora]

Juri Linkov <juri@linkov.net> writes:

>> Emacs -Q
>> M-x fido-mode
>> (defalias 'yes-or-no-p 'y-or-n-p) ;; a common custmization
>> C-x b
>> C-k ;; to kill the Messages buffer
>>
>> Before your changes to `y-or-n-p` this worked well, afterwards
>> I get the "Attempt to use minibuffer inside minibuffer" error.
>>
>> Bear in mind that fido-mode is very new. Also bear in mind
>> that the problem is already present when yes-or-no-p is used.
>>
>> I think a good fix is for icomplete to do this (and for
>> you to do nothing :-) )
>
> It's tempting to do nothing :-), but since the problem is
> already present with yes-or-no-p too, it should be fixed
> because it's a general problem affecting other commands too.

I tend to agree, but it's a longstanding thing in Emacs, so I would be
very wary of touching it (at least until we get some more opinions).

>
> The nil value of enable-recursive-minibuffers by default was intended
> to avoid confusion for beginners unadvisedly typing such sequences as
> M-x M-x M-x M-x M-x ... to get out from which is not easy.

That may be true, but are you sure there aren't other problems being
avoided by it?

Let me give you and example: in icomplete-mode, there is a
post-command-hook that displays some overlays in the minibuffer.  Now,
if we take your patch, indeed icomplete-mode doesn't have to worry about
enable-recursive-minibuffers in the example I gave you.  This is good,
no more error message.  However, that also means that instead of an
annoying error message, you get another confusing bug where the
post-command-hook will prevail in the recursive minibuffer, which just
doesn't make sense when answering just yes-or-no.

In this particular case, I additionally protected the code against this,
but what I'm saying is that other bugs may be uncovered by your patch
that are today hidden behind the annoying-but-reasonable error message.

João

bug#17272: bug#19064: bug#17272: bug#19064: bug#17272: bug#19064: 25.0.50; `message' overwrites `y-or-n-p' prompt, so user misses it

[Juri Linkov]

>> It's tempting to do nothing :-), but since the problem is
>> already present with yes-or-no-p too, it should be fixed
>> because it's a general problem affecting other commands too.
>
> I tend to agree, but it's a longstanding thing in Emacs, so I would be
> very wary of touching it (at least until we get some more opinions).

Many other important minibuffer-reading functions already let-bind
enable-recursive-minibuffers to t:

custom-variable-prompt
find-function-read
describe-function
describe-variable
describe-symbol
read-input-method-name
read-char-by-name
read-passwd
and many other.

So yes-or-no-p could do the same because it's important for users to be
able to answer yes/no questions regardless of whether they activated the
minibuffer intentionally or by mistake.

>> The nil value of enable-recursive-minibuffers by default was intended
>> to avoid confusion for beginners unadvisedly typing such sequences as
>> M-x M-x M-x M-x M-x ... to get out from which is not easy.
>
> That may be true, but are you sure there aren't other problems being
> avoided by it?
>
> Let me give you and example: in icomplete-mode, there is a
> post-command-hook that displays some overlays in the minibuffer.  Now,
> if we take your patch, indeed icomplete-mode doesn't have to worry about
> enable-recursive-minibuffers in the example I gave you.  This is good,
> no more error message.  However, that also means that instead of an
> annoying error message, you get another confusing bug where the
> post-command-hook will prevail in the recursive minibuffer, which just
> doesn't make sense when answering just yes-or-no.
>
> In this particular case, I additionally protected the code against this,
> but what I'm saying is that other bugs may be uncovered by your patch
> that are today hidden behind the annoying-but-reasonable error message.

All experienced Emacs users have enable-recursive-minibuffers enabled,
so everything should work regardless of the value of enable-recursive-minibuffers.

bug#17272: bug#19064: bug#17272: bug#19064: bug#17272: bug#19064: 25.0.50; `message' overwrites `y-or-n-p' prompt, so user misses it

[Eli Zaretskii]

> From: Juri Linkov <juri@linkov.net>
> Date: Thu, 21 Nov 2019 23:39:42 +0200
> Cc: Michael Heerdegen <michael_heerdegen@web.de>, 17272@debbugs.gnu.org,
>  Lars Ingebrigtsen <larsi@gnus.org>, 19064@debbugs.gnu.org
> 
> All experienced Emacs users have enable-recursive-minibuffers enabled

I don't, FWIW.  So please don't build any revolutionary UI changes on
that wrong assumption.

bug#17272: bug#19064: bug#17272: bug#19064: bug#17272: bug#19064: 25.0.50; `message' overwrites `y-or-n-p' prompt, so user misses it

[Juri Linkov]

> I don't, FWIW.  So please don't build any revolutionary UI changes on
> that wrong assumption.

But do you agree that answering yes/no questions should be allowed anytime
regardless of the value of enable-recursive-minibuffers?

bug#17272: bug#19064: bug#17272: bug#19064: bug#17272: bug#19064: 25.0.50; `message' overwrites `y-or-n-p' prompt, so user misses it

[Eli Zaretskii]

> From: Juri Linkov <juri@linkov.net>
> Cc: joaotavora@gmail.com,  michael_heerdegen@web.de,  17272@debbugs.gnu.org,
>   larsi@gnus.org,  19064@debbugs.gnu.org
> Date: Sat, 23 Nov 2019 21:02:45 +0200
> 
> > I don't, FWIW.  So please don't build any revolutionary UI changes on
> > that wrong assumption.
> 
> But do you agree that answering yes/no questions should be allowed anytime
> regardless of the value of enable-recursive-minibuffers?

Yes, I think so.

bug#19064: bug#17272: bug#19064: bug#17272: bug#19064: bug#17272: bug#19064: 25.0.50; `message' overwrites `y-or-n-p' prompt, so user misses it

[Juri Linkov]

>> > I don't, FWIW.  So please don't build any revolutionary UI changes on
>> > that wrong assumption.
>> 
>> But do you agree that answering yes/no questions should be allowed anytime
>> regardless of the value of enable-recursive-minibuffers?
>
> Yes, I think so.

So I installed the patch that allows it.

bug#19064: bug#17272: bug#19064: bug#17272: bug#19064: bug#17272: bug#19064: 25.0.50; `message' overwrites `y-or-n-p' prompt, so user misses it

[Drew Adams]

> So I installed the patch that allows it.

FWIW and FTR, as the filer of bug #19064,
and as I expressed several times in this
thread, I strongly object to the changes
that have now been made.  All of what I said
has been ignored.  Unfortunate.

This is not at all a good fix for the problem
reported.  And it imposes a very bad behavior
more generally - beyond the problem cited.

`message' and `minibuffer-message', i.e.,
writing to the echo area and to the minibuffer,
both have their uses when the minibuffer is
active.

And `y-or-n-p' should continue to use `read-key',
not the minibuffer.

And `enable-recursive-minibuffers' should not
be turned on automatically by `yes-or-no-p'.
Instead, if the function calling `yes-or-no-p'
has not turned it on then an error should be
raised when `yes-or-no-p' tries to use the
minibuffer.

I'm not aware of any part of this "fix" that's
acceptable.

bug#17272: bug#19064: bug#17272: bug#19064: bug#17272: bug#19064: 25.0.50; `message' overwrites `y-or-n-p' prompt, so user misses it

[martin rudalics]

Shouldn't this one

 > +             (enable-recursive-minibuffers t)

be protected too?

martin

bug#17272: bug#19064: bug#17272: bug#19064: bug#17272: bug#19064: 25.0.50; `message' overwrites `y-or-n-p' prompt, so user misses it

[Juri Linkov]

> Shouldn't this one
>
>> +             (enable-recursive-minibuffers t)
>
> be protected too?

Protected from what?

bug#17272: bug#19064: bug#17272: bug#19064: bug#17272: bug#19064: 25.0.50; `message' overwrites `y-or-n-p' prompt, so user misses it

[martin rudalics]

 >> Shouldn't this one
 >>
 >>> +             (enable-recursive-minibuffers t)
 >>
 >> be protected too?
 >
 > Protected from what?

 From an error that would leave it enabled.  What else would be the
purpose of

+  specbind (Qenable_recursive_minibuffers, Qt);

then?

martin

bug#17272: bug#19064: bug#17272: bug#19064: bug#17272: bug#19064: 25.0.50; `message' overwrites `y-or-n-p' prompt, so user misses it

[Juri Linkov]

>>> Shouldn't this one
>>>
>>>> +             (enable-recursive-minibuffers t)
>>>
>>> be protected too?
>>
>> Protected from what?
>
> From an error that would leave it enabled.  What else would be the
> purpose of
>
> +  specbind (Qenable_recursive_minibuffers, Qt);
>
> then?

It seems this is like unwind-protect?  Does let-binding need unwind-protect too?

bug#17272: bug#19064: bug#17272: bug#19064: bug#17272: bug#19064: 25.0.50; `message' overwrites `y-or-n-p' prompt, so user misses it

[Eli Zaretskii]

> From: Juri Linkov <juri@linkov.net>
> Date: Sat, 23 Nov 2019 20:56:13 +0200
> Cc: Michael Heerdegen <michael_heerdegen@web.de>,
>  Lars Ingebrigtsen <larsi@gnus.org>, 19064@debbugs.gnu.org,
>  17272@debbugs.gnu.org,
>  João Távora <joaotavora@gmail.com>
> 
> > +  specbind (Qenable_recursive_minibuffers, Qt);
> >
> > then?
> 
> It seems this is like unwind-protect?

No, it's like let-binding.

bug#17272: bug#19064: bug#17272: bug#19064: 25.0.50; `message' overwrites `y-or-n-p' prompt, so user misses it

[Juri Linkov]

>> The variable name is ‘message-in-echo-area’.  After a little testing,
>> it seems to handle all such cases well:
>
> I have not tested the patch, but it looks good to me.

Actually this patch needs more testing.  I found already
two cases that might be annoying.  Better to anticipate
a possible angry reaction and fix these cases in advance.

The first case is when doing completion, the message
"Making completion list..." is displayed in the minibuffer
for 2 seconds. I don't understand why this message is needed at all,
but at least this patch restores its previous behavior
that displays that message in the echo area and doesn't wait.

diff --git a/lisp/minibuffer.el b/lisp/minibuffer.el
index 6e72eb73f9..b3fc3b8ab0 100644
--- a/lisp/minibuffer.el
+++ b/lisp/minibuffer.el
@@ -1838,7 +1838,7 @@ completion--done
 (defun minibuffer-completion-help (&optional start end)
   "Display a list of possible completions of the current minibuffer contents."
   (interactive)
-  (message "Making completion list...")
+  (message-in-echo-area "Making completion list...")
   (let* ((start (or start (minibuffer-prompt-end)))
          (end (or end (point-max)))
          (string (buffer-substring start end))
@@ -1849,7 +1849,7 @@ minibuffer-completion-help
                        minibuffer-completion-predicate
                        (- (point) start)
                        md)))
-    (message nil)
+    (message-in-echo-area nil)
     (if (or (null completions)
             (and (not (consp (cdr completions)))
                  (equal (car completions) string)))

Another case when using isearch in minibuffer, the failed search
message is displayed at the end of the minibuffer instead of
in the search prompt in the echo area.  This patch restores
the previous behavior:

diff --git a/lisp/isearch.el b/lisp/isearch.el
index 4f3342782d..1705b050b5 100644
--- a/lisp/isearch.el
+++ b/lisp/isearch.el
@@ -2011,7 +2011,7 @@ isearch-message-properties
 (defun isearch--momentary-message (string)
   "Print STRING at the end of the isearch prompt for 1 second."
   (let ((message-log-max nil))
-    (message "%s%s%s"
+    (message-in-echo-area "%s%s%s"
              (isearch-message-prefix nil isearch-nonincremental)
              isearch-message
              (apply #'propertize (format " [%s]" string)
@@ -3168,7 +3170,7 @@ isearch-message
 	     (isearch-message-prefix ellipsis isearch-nonincremental)
 	     m
 	     (isearch-message-suffix c-q-hack)))
-    (if c-q-hack m (let ((message-log-max nil)) (message "%s" m)))))
+    (if c-q-hack m (let ((message-log-max nil)) (message-in-echo-area "%s" m)))))
 
 (defun isearch--describe-regexp-mode (regexp-function &optional space-before)
   "Make a string for describing REGEXP-FUNCTION.

bug#17272: bug#19064: bug#17272: bug#19064: 25.0.50; `message' overwrites `y-or-n-p' prompt, so user misses it

[Lars Ingebrigtsen]

Juri Linkov <juri@linkov.net> writes:

> The first case is when doing completion, the message
> "Making completion list..." is displayed in the minibuffer
> for 2 seconds. I don't understand why this message is needed at all,
> but at least this patch restores its previous behavior
> that displays that message in the echo area and doesn't wait.

Perhaps some completion functions can take a lot of time, so we message
preemptively?  We do a lot of the "just in case" messaging in Emacs,
unfortunately.

(There's a wishlist bug report in the bug tracker to add something like

  (with-delayed-message (0.5 "This sure is taking long...")
    (here-is-some-code))

that would only do the message if the body of the form takes longer than
the timeout.)

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

bug#17272: bug#19064: bug#17272: bug#19064: 25.0.50; `message' overwrites `y-or-n-p' prompt, so user misses it

[Juri Linkov]

>> The first case is when doing completion, the message
>> "Making completion list..." is displayed in the minibuffer
>> for 2 seconds. I don't understand why this message is needed at all,
>> but at least this patch restores its previous behavior
>> that displays that message in the echo area and doesn't wait.
>
> Perhaps some completion functions can take a lot of time, so we message
> preemptively?  We do a lot of the "just in case" messaging in Emacs,
> unfortunately.
>
> (There's a wishlist bug report in the bug tracker to add something like
>
>   (with-delayed-message (0.5 "This sure is taking long...")
>     (here-is-some-code))
>
> that would only do the message if the body of the form takes longer than
> the timeout.)

I see, it's in bug#22922 and bug#19776.

bug#17272: bug#19064: bug#17272: bug#19064: 25.0.50; `message' overwrites `y-or-n-p' prompt, so user misses it

[Juri Linkov]

>>> The first case is when doing completion, the message
>>> "Making completion list..." is displayed in the minibuffer
>>> for 2 seconds. I don't understand why this message is needed at all,
>>> but at least this patch restores its previous behavior
>>> that displays that message in the echo area and doesn't wait.
>>
>> Perhaps some completion functions can take a lot of time, so we message
>> preemptively?  We do a lot of the "just in case" messaging in Emacs,
>> unfortunately.
>>
>> (There's a wishlist bug report in the bug tracker to add something like
>>
>>   (with-delayed-message (0.5 "This sure is taking long...")
>>     (here-is-some-code))
>>
>> that would only do the message if the body of the form takes longer than
>> the timeout.)
>
> I see, it's in bug#22922 and bug#19776.

But should the function itself report its own progress
using progress-reporter-update?

bug#19064: bug#17272: bug#19064: bug#17272: bug#19064: 25.0.50; `message' overwrites `y-or-n-p' prompt, so user misses it

[Lars Ingebrigtsen]

Juri Linkov <juri@linkov.net> writes:

> But should the function itself report its own progress
> using progress-reporter-update?

No, I think that's too complicated.  It doesn't know how long it's going
to take, so it can't report a percentage done or anything.

But it could do "...done" at the end if it has decided to show the
initial string.

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

bug#17272: bug#19064: bug#17272: bug#19064: 25.0.50; `message' overwrites `y-or-n-p' prompt, so user misses it

[Juri Linkov]

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

>>> The variable name is ‘message-in-echo-area’.  After a little testing,
>>> it seems to handle all such cases well:
>>
>> I have not tested the patch, but it looks good to me.
>
> Actually this patch needs more testing.  I found already
> two cases that might be annoying.  Better to anticipate
> a possible angry reaction and fix these cases in advance.

After more testing, at least all noticed problems are fixed
with this patch (it also reverts previous commits that
added minibuffer-message and that is not needed anymore):


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: message-in-echo-area.patch --]
[-- Type: text/x-diff, Size: 7455 bytes --]

diff --git a/lisp/autorevert.el b/lisp/autorevert.el
index 079750a3f6..9275513c8d 100644
--- a/lisp/autorevert.el
+++ b/lisp/autorevert.el
@@ -815,8 +815,7 @@ auto-revert-handler
     (when revert
       (when (and auto-revert-verbose
                  (not (eq revert 'fast)))
-        (with-current-buffer (window-buffer (old-selected-window))
-          (minibuffer-message "Reverting buffer `%s'." (buffer-name))))
+        (message "Reverting buffer `%s'." (buffer-name)))
       ;; If point (or a window point) is at the end of the buffer, we
       ;; want to keep it at the end after reverting.  This allows one
       ;; to tail a file.
diff --git a/lisp/isearch.el b/lisp/isearch.el
index 4f3342782d..1705b050b5 100644
--- a/lisp/isearch.el
+++ b/lisp/isearch.el
@@ -2011,7 +2011,7 @@ isearch-message-properties
 (defun isearch--momentary-message (string)
   "Print STRING at the end of the isearch prompt for 1 second."
   (let ((message-log-max nil))
-    (message "%s%s%s"
+    (message-in-echo-area "%s%s%s"
              (isearch-message-prefix nil isearch-nonincremental)
              isearch-message
              (apply #'propertize (format " [%s]" string)
@@ -3168,7 +3170,7 @@ isearch-message
 	     (isearch-message-prefix ellipsis isearch-nonincremental)
 	     m
 	     (isearch-message-suffix c-q-hack)))
-    (if c-q-hack m (let ((message-log-max nil)) (message "%s" m)))))
+    (if c-q-hack m (let ((message-log-max nil)) (message-in-echo-area "%s" m)))))
 
 (defun isearch--describe-regexp-mode (regexp-function &optional space-before)
   "Make a string for describing REGEXP-FUNCTION.
diff --git a/lisp/man.el b/lisp/man.el
index ce01fdc805..beec2e616f 100644
--- a/lisp/man.el
+++ b/lisp/man.el
@@ -1474,7 +1474,7 @@ Man-bgproc-sentinel
           (kill-buffer Man-buffer)))
 
       (when message
-        (minibuffer-message "%s" message)))))
+        (message "%s" message)))))
 
 (defun Man-page-from-arguments (args)
   ;; Skip arguments and only print the page name.
diff --git a/lisp/minibuffer.el b/lisp/minibuffer.el
index ee3d0095a9..7c87a18273 100644
--- a/lisp/minibuffer.el
+++ b/lisp/minibuffer.el
@@ -712,16 +712,16 @@ minibuffer-message
       (progn
         (if args
             (apply #'message message args)
-          (message "%s" message))
+          (message-in-echo-area "%s" message))
         (prog1 (sit-for (or minibuffer-message-timeout 1000000))
-          (message nil)))
+          (message-in-echo-area nil)))
     ;; Record message in the *Messages* buffer
     (let ((inhibit-message t))
       (if args
           (apply #'message message args)
-        (message "%s" message)))
+        (message-in-echo-area "%s" message)))
     ;; Clear out any old echo-area message to make way for our new thing.
-    (message nil)
+    (message-in-echo-area nil)
     (setq message (if (and (null args)
                            (string-match-p "\\` *\\[.+\\]\\'" message))
                       ;; Make sure we can put-text-property.
@@ -1838,7 +1838,7 @@ completion--done
 (defun minibuffer-completion-help (&optional start end)
   "Display a list of possible completions of the current minibuffer contents."
   (interactive)
-  (message "Making completion list...")
+  (message-in-echo-area "Making completion list...")
   (let* ((start (or start (minibuffer-prompt-end)))
          (end (or end (point-max)))
          (string (buffer-substring start end))
@@ -1849,7 +1849,7 @@ minibuffer-completion-help
                        minibuffer-completion-predicate
                        (- (point) start)
                        md)))
-    (message nil)
+    (message-in-echo-area nil)
     (if (or (null completions)
             (and (not (consp (cdr completions)))
                  (equal (car completions) string)))
diff --git a/lisp/subr.el b/lisp/subr.el
index 20daed623f..fae06399ef 100644
--- a/lisp/subr.el
+++ b/lisp/subr.el
@@ -4620,9 +4620,10 @@ do-after-load-evaluation
 					  byte-compile-current-file
 					  byte-compile-root-dir)))
 	      (byte-compile-warn "%s" msg))
-	  (run-with-idle-timer 0 nil
+	  (run-with-timer 0 nil
 			  (lambda (msg)
-			    (minibuffer-message "%s" msg))
+			    (discard-input)
+			    (message "%s" msg))
 			  msg)))))
 
   ;; Finally, run any other hook.
diff --git a/src/editfns.c b/src/editfns.c
index 8fc866d391..650dc6d4ca 100644
--- a/src/editfns.c
+++ b/src/editfns.c
@@ -2875,8 +2875,57 @@ accent (\\=`) and apostrophe (\\=') are special in the format; see
 any existing message; this lets the minibuffer contents show.  See
 also `current-message'.
 
+When the variable `message-in-echo-area' is non-nil, use the function
+`message-in-echo-area' to display the message in the echo area.
+Otherwise, when the minibuffer is active, use `minibuffer-message'
+to temporarily display the message at the end of the minibuffer.
+
 usage: (message FORMAT-STRING &rest ARGS)  */)
   (ptrdiff_t nargs, Lisp_Object *args)
+{
+  if (NILP (Vmessage_in_echo_area)
+      && !inhibit_message
+      && !(NILP (args[0]) || (STRINGP (args[0]) && SBYTES (args[0]) == 0))
+      && WINDOW_LIVE_P (Fold_selected_window ())
+      && BUFFERP (Fwindow_buffer (Fold_selected_window ()))
+      && !NILP (Fminibufferp (Fwindow_buffer (Fold_selected_window ()))))
+    {
+      ptrdiff_t count = SPECPDL_INDEX ();
+
+      /* Avoid possible recursion.  */
+      specbind (Qmessage_in_echo_area, Qt);
+
+      record_unwind_current_buffer ();
+      Fset_buffer (Fwindow_buffer (Fold_selected_window ()));
+
+      return unbind_to (count, CALLN (Fapply, intern ("minibuffer-message"),
+                                      Flist (nargs, args)));
+    }
+  else
+    return Fmessage_in_echo_area (nargs, args);
+}
+
+DEFUN ("message-in-echo-area", Fmessage_in_echo_area, Smessage_in_echo_area, 1, MANY, 0,
+       doc: /* Display a message at the bottom of the screen.
+The message also goes into the `*Messages*' buffer, if `message-log-max'
+is non-nil.  (In keyboard macros, that's all it does.)
+Return the message.
+
+In batch mode, the message is printed to the standard error stream,
+followed by a newline.
+
+The first argument is a format control string, and the rest are data
+to be formatted under control of the string.  Percent sign (%), grave
+accent (\\=`) and apostrophe (\\=') are special in the format; see
+`format-message' for details.  To display STRING without special
+treatment, use (message-in-echo-area "%s" STRING).
+
+If the first argument is nil or the empty string, the function clears
+any existing message; this lets the minibuffer contents show.  See
+also `current-message'.
+
+usage: (message-in-echo-area FORMAT-STRING &rest ARGS)  */)
+  (ptrdiff_t nargs, Lisp_Object *args)
 {
   if (NILP (args[0])
       || (STRINGP (args[0])
@@ -4520,6 +4569,11 @@ syms_of_editfns (void)
 it to be non-nil.  */);
   binary_as_unsigned = false;
 
+  DEFVAR_LISP ("message-in-echo-area", Vmessage_in_echo_area,
+	       doc: /* Non-nil means overwrite the minibuffer with a message in the echo area.  */);
+  Vmessage_in_echo_area = Qnil;
+  DEFSYM (Qmessage_in_echo_area, "message-in-echo-area");
+
   defsubr (&Spropertize);
   defsubr (&Schar_equal);
   defsubr (&Sgoto_char);
@@ -4594,6 +4648,7 @@ syms_of_editfns (void)
   defsubr (&Semacs_pid);
   defsubr (&Ssystem_name);
   defsubr (&Smessage);
+  defsubr (&Smessage_in_echo_area);
   defsubr (&Smessage_box);
   defsubr (&Smessage_or_box);
   defsubr (&Scurrent_message);

bug#17272: bug#19064: bug#17272: bug#19064: 25.0.50; `message' overwrites `y-or-n-p' prompt, so user misses it

[Juri Linkov]

tags 17272 fixed
tags 19064 fixed
close 17272 27.0.50
close 19064 27.0.50
quit

>>>> The variable name is ‘message-in-echo-area’.  After a little testing,
>>>> it seems to handle all such cases well:
>>>
>>> I have not tested the patch, but it looks good to me.
>>
>> Actually this patch needs more testing.  I found already
>> two cases that might be annoying.  Better to anticipate
>> a possible angry reaction and fix these cases in advance.
>
> After more testing, at least all noticed problems are fixed
> with this patch (it also reverts previous commits that
> added minibuffer-message and that is not needed anymore):

This patch is installed now, and the bug report is closed.

It also fixed long-standing annoyance of using query-replace in the minibuffer.
Previously the query-replace prompt completely obscured the replaced text.
Now the query-replace prompt is displayed at the end of the minibuffer,
so the replaced text is visible in the minibuffer.

The requested NEWS and Info manual changes were installed as well:

diff --git a/doc/lispref/display.texi b/doc/lispref/display.texi
index ddbae40ac9..b5990130c6 100644
--- a/doc/lispref/display.texi
+++ b/doc/lispref/display.texi
@@ -276,11 +276,13 @@ Displaying Messages
 When @code{inhibit-message} is non-@code{nil}, no message will be displayed
 in the echo area, it will only be logged to @samp{*Messages*}.
 
+If the minibuffer is active, it uses the @code{minibuffer-message}
+function to display the message temporarily at the end of the
+minibuffer (@pxref{Minibuffer Misc}).
+
 If @var{format-string} is @code{nil} or the empty string,
 @code{message} clears the echo area; if the echo area has been
-expanded automatically, this brings it back to its normal size.  If
-the minibuffer is active, this brings the minibuffer contents back
-onto the screen immediately.
+expanded automatically, this brings it back to its normal size.
 
 @example
 @group
diff --git a/etc/NEWS b/etc/NEWS
index 7a51106add..48ad1a299a 100644
--- a/etc/NEWS
+++ b/etc/NEWS
@@ -724,6 +724,10 @@ the minibuffer.  If non-nil, point will move to the end of the prompt
 *** Minibuffer now uses 'minibuffer-message' to display error messages
 at the end of the active minibuffer.
 
++++
+*** The function 'message' now displays the message at the end of the minibuffer
+when the minibuffer is active.
+
 +++
 *** 'y-or-n-p' now uses the minibuffer to read 'y' or 'n' answer.
 

bug#19064: bug#17272: bug#19064: bug#17272: bug#19064: 25.0.50; `message' overwrites `y-or-n-p' prompt, so user misses it

[Lars Ingebrigtsen]

Juri Linkov <juri@linkov.net> writes:

> This patch is installed now, and the bug report is closed.

Great!

I wonder whether read-multiple-choice should get the same treatment?  It
currently uses read-event.

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

bug#19064: bug#17272: bug#19064: bug#17272: bug#19064: 25.0.50; `message' overwrites `y-or-n-p' prompt, so user misses it

[Juri Linkov]

>> This patch is installed now, and the bug report is closed.
>
> Great!
>
> I wonder whether read-multiple-choice should get the same treatment?  It
> currently uses read-event.

There are many other functions waiting for the same treatment.
Some examples that I noticed recently: map-y-or-n-p, ask-user-about-lock.

bug#19064: 25.0.50; `message' overwrites `y-or-n-p' prompt, so user misses it

[Juri Linkov]

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

>>   Seems like whenever `y-or-n-p' (or just `read-key') is waiting
>>   for a key, `message' should do nothing.  Either it should echo
>>   its message after the key is read or (maybe better) it should
>>   do nothing at all.  As it stands now, this seems like a basic
>>   UI problem, not just a minor annoyance.
>
> I tried this here with emacs 25:
>
> (progn
>   (man "X")
>   (y-or-n-p "-->"))

Here is the patch that fixes this (required changes from bug#38076):


[-- Attachment #2: minibuffer-message-man.patch --]
[-- Type: text/x-diff, Size: 4077 bytes --]

diff --git a/lisp/man.el b/lisp/man.el
index 9d21e953d1..27a134e004 100644
--- a/lisp/man.el
+++ b/lisp/man.el
@@ -1389,7 +1389,7 @@ Man-bgproc-sentinel
   (let ((Man-buffer (if (stringp process) (get-buffer process)
 		      (process-buffer process)))
 	(delete-buff nil)
-	(err-mess nil))
+        message)
 
     (if (null (buffer-name Man-buffer)) ;; deleted buffer
 	(or (stringp process)
@@ -1402,9 +1402,9 @@ Man-bgproc-sentinel
 	    (goto-char (point-min))
 	    (cond ((or (looking-at "No \\(manual \\)*entry for")
 		       (looking-at "[^\n]*: nothing appropriate$"))
-		   (setq err-mess (buffer-substring (point)
-						    (progn
-						      (end-of-line) (point)))
+		   (setq message (buffer-substring (point)
+						   (progn
+						     (end-of-line) (point)))
 			 delete-buff t))
 
 		  ;; "-k foo", successful exit, but no output (from man-db)
@@ -1415,7 +1415,7 @@ Man-bgproc-sentinel
 			(eq (process-status process) 'exit)
 			(= (process-exit-status process) 0)
 			(= (point-min) (point-max)))
-		   (setq err-mess (format "%s: no matches" Man-arguments)
+		   (setq message (format "%s: no matches" Man-arguments)
 			 delete-buff t))
 
 		  ((or (stringp process)
@@ -1423,7 +1423,7 @@ Man-bgproc-sentinel
 				 (= (process-exit-status process) 0))))
 		   (or (zerop (length msg))
 		       (progn
-			 (setq err-mess
+			 (setq message
 			       (concat (buffer-name Man-buffer)
 				       ": process "
 				       (let ((eos (1- (length msg))))
@@ -1432,11 +1432,7 @@ Man-bgproc-sentinel
 			 (goto-char (point-max))
 			 (insert (format "\nprocess %s" msg))))
 		   ))
-	    (if delete-buff
-		(if (window-live-p (get-buffer-window Man-buffer t))
-		    (quit-restore-window
-		     (get-buffer-window Man-buffer t) 'kill)
-		  (kill-buffer Man-buffer))
+	    (unless delete-buff
 
 	      (run-hooks 'Man-cooked-hook)
 
@@ -1447,10 +1443,8 @@ Man-bgproc-sentinel
 
 	      (if (not Man-page-list)
 		  (let ((args Man-arguments))
-		    (if (window-live-p (get-buffer-window (current-buffer) t))
-			(quit-restore-window
-			 (get-buffer-window (current-buffer) t) 'kill)
-		      (kill-buffer (current-buffer)))
+                    (setq delete-buff t)
+
                     ;; Entries hyphenated due to the window's width
                     ;; won't be found in the man database, so remove
                     ;; the hyphenation -- assuming Groff hyphenates
@@ -1460,22 +1454,29 @@ Man-bgproc-sentinel
 		    (if (string-match "[-‐­]" args)
 			(let ((str (replace-match "" nil nil args)))
 			  (Man-getpage-in-background str))
-                      (message "Can't find the %s manpage"
-                               (Man-page-from-arguments args))))
+                      (setq message (format "Can't find the %s manpage"
+                                            (Man-page-from-arguments args)))))
 
 		(if Man-fontify-manpage-flag
-		    (message "%s man page formatted"
-			     (Man-page-from-arguments Man-arguments))
-		  (message "%s man page cleaned up"
-			   (Man-page-from-arguments Man-arguments)))
+		    (setq message (format "%s man page formatted"
+			                  (Man-page-from-arguments Man-arguments)))
+		  (setq message (format "%s man page cleaned up"
+			                (Man-page-from-arguments Man-arguments))))
 		(unless (and (processp process)
 			     (not (eq (process-status process) 'exit)))
 		  (setq mode-line-process nil))
-		(set-buffer-modified-p nil)))))
+		(set-buffer-modified-p nil))))))
 
-	(if err-mess
-	    (message "%s" err-mess))
-	))))
+      (when delete-buff
+        (if (window-live-p (get-buffer-window Man-buffer t))
+	    (quit-restore-window
+	     (get-buffer-window Man-buffer t) 'kill)
+	  (kill-buffer Man-buffer)))
+
+      (when message
+        (if (minibufferp)
+            (minibuffer-message "%s" message)
+          (message "%s" message))))))
 
 (defun Man-page-from-arguments (args)
   ;; Skip arguments and only print the page name.

bug#19064: 25.0.50; `message' overwrites `y-or-n-p' prompt, so user misses it

[Juri Linkov]

> (progn
>   (man "X")
>   (y-or-n-p "-->"))
>
> This stills behave as described: the prompt disappears and doesn't come
> back from alone.
>
> OTOH, a simple call to message done from within a timer doesn't behave
> like this.  So this seems to be special to process sentinels, thus it's
> probably a rare situation that this happens - a bit annoying
> nonetheless.

Now this is fixed.

There is another unrelated problem when a man page doesn't exist,
it moves point to wrong window, and never returns back to the minibuffer:

(progn
  (man "XYZ")
  (y-or-n-p "-->"))

But this problem is not new.  The same can be reproduced
in older versions with

(progn
  (man "XYZ")
  (read-string "-->"))

This is because quit-restore-window moves point to wrong window.

Maybe a new bug report should be created for this?

bug#19064: 25.0.50; `message' overwrites `y-or-n-p' prompt, so user misses it

[martin rudalics]

 > But this problem is not new.  The same can be reproduced
 > in older versions with
 >
 > (progn
 >    (man "XYZ")
 >    (read-string "-->"))
 >
 > This is because quit-restore-window moves point to wrong window.

What should 'quit-restore-window' do here in particular?

martin

bug#38164: quit-restore-window doesn't restore point in man

[Juri Linkov]

Creating a new bug report as a spin-off of bug#19064.

>> But this problem is not new.  The same can be reproduced
>> in older versions with
>>
>> (progn
>>    (man "XYZ")
>>    (read-string "-->"))
>>
>> This is because quit-restore-window moves point to wrong window.
>
> What should 'quit-restore-window' do here in particular?

quit-restore-window should move point to old-selected-window,
i.e. the minibuffer window that was selected before Man-bgproc-sentinel
kicked in.  But I don't understand why it's not doing that.

bug#38164: quit-restore-window doesn't restore point in man

[martin rudalics]

 >>> (progn
 >>>     (man "XYZ")
 >>>     (read-string "-->"))
 >>>
 >>> This is because quit-restore-window moves point to wrong window.
 >>
 >> What should 'quit-restore-window' do here in particular?
 >
 > quit-restore-window should move point to old-selected-window,
 > i.e. the minibuffer window that was selected before Man-bgproc-sentinel
 > kicked in.  But I don't understand why it's not doing that.

I'm not sure what you mean.  At the time 'man' calls 'display-buffer',
the latter simply records the window returned by 'selected-window' as
the one to reselect when the *Man XYZ* window gets deleted.  That
recorded window is not the minibuffer window here, even if I evaluate
the form via M-:.  Am I missing something?

martin

bug#38164: quit-restore-window doesn't restore point in man

[Juri Linkov]

>>>> (progn
>>>>     (man "XYZ")
>>>>     (read-string "-->"))
>>>>
>>>> This is because quit-restore-window moves point to wrong window.
>>>
>>> What should 'quit-restore-window' do here in particular?
>>
>> quit-restore-window should move point to old-selected-window,
>> i.e. the minibuffer window that was selected before Man-bgproc-sentinel
>> kicked in.  But I don't understand why it's not doing that.
>
> I'm not sure what you mean.  At the time 'man' calls 'display-buffer',
> the latter simply records the window returned by 'selected-window' as
> the one to reselect when the *Man XYZ* window gets deleted.  That
> recorded window is not the minibuffer window here, even if I evaluate
> the form via M-:.  Am I missing something?

Removing these lines from 'quit-restore-window' fixes the problem:

      ;; Select old window.
      (when (window-live-p (nth 2 quit-restore))
        (select-window (nth 2 quit-restore)))

If there lines are the whole purpose of 'quit-restore-window',
then in man.el we need to reselect the original window explicitly:

diff --git a/lisp/man.el b/lisp/man.el
index ce01fdc805..76890f74a9 100644
--- a/lisp/man.el
+++ b/lisp/man.el
@@ -1469,8 +1469,10 @@ Man-bgproc-sentinel
 
       (when delete-buff
         (if (window-live-p (get-buffer-window Man-buffer t))
-            (quit-restore-window
-             (get-buffer-window Man-buffer t) 'kill)
+            (progn
+              (quit-restore-window
+               (get-buffer-window Man-buffer t) 'kill)
+              (select-window (old-selected-window)))
           (kill-buffer Man-buffer)))
 
       (when message

bug#38164: quit-restore-window doesn't restore point in man

[martin rudalics]

 > Removing these lines from 'quit-restore-window' fixes the problem:
 >
 >        ;; Select old window.
 >        (when (window-live-p (nth 2 quit-restore))
 >          (select-window (nth 2 quit-restore)))
 >
 > If there lines are the whole purpose of 'quit-restore-window',
 > then in man.el we need to reselect the original window explicitly:
 >
 > diff --git a/lisp/man.el b/lisp/man.el
 > index ce01fdc805..76890f74a9 100644
 > --- a/lisp/man.el
 > +++ b/lisp/man.el
 > @@ -1469,8 +1469,10 @@ Man-bgproc-sentinel
 >
 >         (when delete-buff
 >           (if (window-live-p (get-buffer-window Man-buffer t))
 > -            (quit-restore-window
 > -             (get-buffer-window Man-buffer t) 'kill)
 > +            (progn
 > +              (quit-restore-window
 > +               (get-buffer-window Man-buffer t) 'kill)
 > +              (select-window (old-selected-window)))
 >             (kill-buffer Man-buffer)))
 >
 >         (when message

I'm completely lost now.  Can you tell me in a detailed fashion what
goes wrong here?  Is the window stored in (nth 2 quit-restore) the
wrong window right from the outset?  Or is it in a sense falsified by
what happens later during minibuffer interaction?

martin

bug#38164: quit-restore-window doesn't restore point in man

[Juri Linkov]

>> @@ -1469,8 +1469,10 @@ Man-bgproc-sentinel
>>
>>         (when delete-buff
>>           (if (window-live-p (get-buffer-window Man-buffer t))
>> -            (quit-restore-window
>> -             (get-buffer-window Man-buffer t) 'kill)
>> +            (progn
>> +              (quit-restore-window
>> +               (get-buffer-window Man-buffer t) 'kill)
>> +              (select-window (old-selected-window)))
>>             (kill-buffer Man-buffer)))
>
> I'm completely lost now.  Can you tell me in a detailed fashion what
> goes wrong here?  Is the window stored in (nth 2 quit-restore) the
> wrong window right from the outset?  Or is it in a sense falsified by
> what happens later during minibuffer interaction?

(progn
  (man "XYZ")
  (read-string "--> "))

'read-string' activates the minibuffer, but asynchronous Man-bgproc-sentinel
later calls 'quit-restore-window' that selects its previous window,
ignoring the fact that now the selected window was in the minibuffer.
So we need an exception for the case of active minibuffer.

bug#38164: quit-restore-window doesn't restore point in man

[martin rudalics]

 > (progn
 >    (man "XYZ")
 >    (read-string "--> "))
 >
 > 'read-string' activates the minibuffer, but asynchronous Man-bgproc-sentinel
 > later calls 'quit-restore-window' that selects its previous window,
 > ignoring the fact that now the selected window was in the minibuffer.
 > So we need an exception for the case of active minibuffer.

So what you want is probably (twice)

       (when (and (window-live-p (nth 2 quit-restore))
                  (not (eq (selected-window) (minibuffer-window))))
	(select-window (nth 2 quit-restore))))

But note that quitting the minibuffer will restore the previous window
configuration and thus undo that selection and all other changes done
by 'quit-restore-window' anyway.

martin

bug#38164: quit-restore-window doesn't restore point in man

[Juri Linkov]

>> (progn
>>    (man "XYZ")
>>    (read-string "--> "))
>>
>> 'read-string' activates the minibuffer, but asynchronous Man-bgproc-sentinel
>> later calls 'quit-restore-window' that selects its previous window,
>> ignoring the fact that now the selected window was in the minibuffer.
>> So we need an exception for the case of active minibuffer.
>
> So what you want is probably (twice)
>
>       (when (and (window-live-p (nth 2 quit-restore))
>                  (not (eq (selected-window) (minibuffer-window))))
> 	(select-window (nth 2 quit-restore))))
>
> But note that quitting the minibuffer will restore the previous window
> configuration and thus undo that selection and all other changes done
> by 'quit-restore-window' anyway.

Is it possible to not restore the previous window configuration
when quitting the minibuffer?

bug#38164: quit-restore-window doesn't restore point in man

[martin rudalics]

 > Is it possible to not restore the previous window configuration
 > when quitting the minibuffer?

No.  It's a very elaborate scheme in read_minibuf triggered by

   record_unwind_protect (restore_buffer, Fcurrent_buffer ());

   choose_minibuf_frame ();

   record_unwind_protect_void (choose_minibuf_frame);

   record_unwind_protect (restore_window_configuration,
			 Fcurrent_window_configuration (Qnil));

   /* If the minibuffer window is on a different frame, save that
      frame's configuration too.  */
   mini_frame = WINDOW_FRAME (XWINDOW (minibuf_window));
   if (!EQ (mini_frame, selected_frame))
     record_unwind_protect (restore_window_configuration,
			   Fcurrent_window_configuration (mini_frame));

so it may even save two window configurations.

martin

bug#38164: quit-restore-window doesn't restore point in man

[Juri Linkov]

>> Is it possible to not restore the previous window configuration
>> when quitting the minibuffer?
>
> No.  It's a very elaborate scheme in read_minibuf triggered by
>
>   record_unwind_protect (restore_buffer, Fcurrent_buffer ());

Why should quitting the minibuffer restore the previous window configuration?

Sometimes to get help on a previously run M-x command, typing

  M-x M-p C-h f RET

displays the function Help window about the previous command. Then clicking
on the link with the source file name in the Help buffer opens its source code.
This creates a nice window layout with the Help window and the source window.
But quitting the minibuffer destroys this nice layout, and returns some
old obsolete layout.  Why should it do this?

bug#38164: quit-restore-window doesn't restore point in man

[Eli Zaretskii]

> From: Juri Linkov <juri@linkov.net>
> Date: Mon, 18 Nov 2019 23:21:27 +0200
> Cc: 38164@debbugs.gnu.org
> 
> Sometimes to get help on a previously run M-x command, typing
> 
>   M-x M-p C-h f RET
> 
> displays the function Help window about the previous command. Then clicking
> on the link with the source file name in the Help buffer opens its source code.
> This creates a nice window layout with the Help window and the source window.
> But quitting the minibuffer destroys this nice layout, and returns some
> old obsolete layout.  Why should it do this?

Because that's what quitting help does?  If you don't want this, just
don't quit; you can simply leave the windows as they were and
continue.

bug#38164: quit-restore-window doesn't restore point in man

[martin rudalics]

 > Because that's what quitting help does?  If you don't want this, just
 > don't quit; you can simply leave the windows as they were and
 > continue.

IIUC Juri doesn't want to quit help.  He wants to leave the
minibuffer, maybe for running another command.

martin

bug#38164: quit-restore-window doesn't restore point in man

[Eli Zaretskii]

> Cc: 38164@debbugs.gnu.org
> From: martin rudalics <rudalics@gmx.at>
> Date: Tue, 19 Nov 2019 08:56:54 +0100
> 
>  > Because that's what quitting help does?  If you don't want this, just
>  > don't quit; you can simply leave the windows as they were and
>  > continue.
> 
> IIUC Juri doesn't want to quit help.  He wants to leave the
> minibuffer, maybe for running another command.

Apologies if I was confused, but Juri explicitly asked about "quitting
the minibuffer".

bug#38164: quit-restore-window doesn't restore point in man

[martin rudalics]

 >>   > Because that's what quitting help does?  If you don't want this, just
 >>   > don't quit; you can simply leave the windows as they were and
 >>   > continue.
 >>
 >> IIUC Juri doesn't want to quit help.  He wants to leave the
 >> minibuffer, maybe for running another command.
 >
 > Apologies if I was confused, but Juri explicitly asked about "quitting
 > the minibuffer".

Quitting help should never destroy a window layout these days.  If it
did, we'd have a bug.  Quitting the minibuffer, for example via C-g,
may destroy the window layout (of two frames even).  But I'll let Juri
speak for himself now.

martin

bug#38164: quit-restore-window doesn't restore point in man

[Eli Zaretskii]

> Cc: juri@linkov.net, 38164@debbugs.gnu.org
> From: martin rudalics <rudalics@gmx.at>
> Date: Tue, 19 Nov 2019 17:53:29 +0100
> 
>  >>   > Because that's what quitting help does?  If you don't want this, just
>  >>   > don't quit; you can simply leave the windows as they were and
>  >>   > continue.
>  >>
>  >> IIUC Juri doesn't want to quit help.  He wants to leave the
>  >> minibuffer, maybe for running another command.
>  >
>  > Apologies if I was confused, but Juri explicitly asked about "quitting
>  > the minibuffer".
> 
> Quitting help should never destroy a window layout these days.  If it
> did, we'd have a bug.

Sounds like there's some misunderstanding.  What I mean is this:

  emacs -Q
  C-h f find-file RET (any function will do)
  C-x o
  q

The last 'q' command deletes the window showing *Help*, and that is
what I call "quitting help".  I believe Emacs behaved like that since
time immemoriam.

bug#38164: quit-restore-window doesn't restore point in man

[martin rudalics]

 >> Quitting help should never destroy a window layout these days.  If it
 >> did, we'd have a bug.
 >
 > Sounds like there's some misunderstanding.  What I mean is this:
 >
 >    emacs -Q
 >    C-h f find-file RET (any function will do)
 >    C-x o
 >    q
 >
 > The last 'q' command deletes the window showing *Help*, and that is
 > what I call "quitting help".  I believe Emacs behaved like that since
 > time immemoriam.

Try with Emacs 22 and, for example,

emacs -Q
C-x 2
C-h f find-file RET (any function will do)
C-x o
q

Tempus fugit.

martin

bug#38164: quit-restore-window doesn't restore point in man

[Juri Linkov]

>>>   > Because that's what quitting help does?  If you don't want this, just
>>>   > don't quit; you can simply leave the windows as they were and
>>>   > continue.
>>>
>>> IIUC Juri doesn't want to quit help.  He wants to leave the
>>> minibuffer, maybe for running another command.
>>
>> Apologies if I was confused, but Juri explicitly asked about "quitting
>> the minibuffer".
>
> Quitting help should never destroy a window layout these days.  If it
> did, we'd have a bug.  Quitting the minibuffer, for example via C-g,
> may destroy the window layout (of two frames even).  But I'll let Juri
> speak for himself now.

This is the case that I meant:

 emacs -Q

 M-x info               ;; don't type RET
 C-h f RET              ;; describe function 'info'
 C-x o C-x o            ;; switch to Help window
 <tab> <return>         ;; visit info.el from help link
 C-x o C-x o            ;; switch to minibuffer
 C-g                    ;; exit minibuffer

bug#38164: quit-restore-window doesn't restore point in man

[martin rudalics]

 > This is the case that I meant:
 >
 >   emacs -Q
 >
 >   M-x info               ;; don't type RET
 >   C-h f RET              ;; describe function 'info'
 >   C-x o C-x o            ;; switch to Help window
 >   <tab> <return>         ;; visit info.el from help link
 >   C-x o C-x o            ;; switch to minibuffer
 >   C-g                    ;; exit minibuffer

And if the minibuffer appears on another frame, it will reset that
frame as well.  We could make the behavior customizable with an option
say 'exit-minibuffer-restore-window-configuration', t by default.

martin

bug#38164: quit-restore-window doesn't restore point in man

[Juri Linkov]

>>   M-x info               ;; don't type RET
>>   C-h f RET              ;; describe function 'info'
>>   C-x o C-x o            ;; switch to Help window
>>   <tab> <return>         ;; visit info.el from help link
>>   C-x o C-x o            ;; switch to minibuffer
>>   C-g                    ;; exit minibuffer
>
> And if the minibuffer appears on another frame, it will reset that
> frame as well.  We could make the behavior customizable with an option
> say 'exit-minibuffer-restore-window-configuration', t by default.

I'm not sure if I'll ever want to customize such a new variable
'exit-minibuffer-restore-window-configuration' to nil,
because sometimes it's desirable to restore a previous
window configuration, sometimes not.

But at least it could help to resolve the remaining problem in man.el,
if other solutions are not possible.

bug#38164: quit-restore-window doesn't restore point in man

[Eli Zaretskii]

> From: Juri Linkov <juri@linkov.net>
> Cc: Eli Zaretskii <eliz@gnu.org>,  38164@debbugs.gnu.org
> Date: Wed, 20 Nov 2019 01:03:01 +0200
> 
>  emacs -Q
> 
>  M-x info               ;; don't type RET
>  C-h f RET              ;; describe function 'info'
>  C-x o C-x o            ;; switch to Help window
>  <tab> <return>         ;; visit info.el from help link
>  C-x o C-x o            ;; switch to minibuffer
>  C-g                    ;; exit minibuffer

How is this different from the below?

 emacs -Q

 M-x info               ;; don't type RET
 C-h f RET              ;; describe function 'info'
 C-g

IOW, a C-g means "get me out of here all the way to top-level", so it
removes all the windows created by whatever you did in the aborted
operation.  (Of course, the buffers are still there, and if you have
tab-line-mode turned on, you can easily get them displayed ;-)

bug#38164: quit-restore-window doesn't restore point in man

[Lars Ingebrigtsen]

Juri Linkov <juri@linkov.net> writes:

> -            (quit-restore-window
> -             (get-buffer-window Man-buffer t) 'kill)
> +            (progn
> +              (quit-restore-window
> +               (get-buffer-window Man-buffer t) 'kill)
> +              (select-window (old-selected-window)))

The discussion then dealt mostly with general quit-restore-windows
issues, but I think this patch should be applied, since it fixes an
annoying problem in Man.  So I've now pushed it to Emacs 28.

Skimming the rest of this thread, there doesn't seem to be a lot of hope
for making any progress on the general issue, so I'm closing this bug
report, and perhaps a new one (or an emacs-devel) discussion would be
appropriate.

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

bug#38164: quit-restore-window doesn't restore point in man

[Basil L. Contovounesios]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> Juri Linkov <juri@linkov.net> writes:
>
>> -            (quit-restore-window
>> -             (get-buffer-window Man-buffer t) 'kill)
>> +            (progn
>> +              (quit-restore-window
>> +               (get-buffer-window Man-buffer t) 'kill)
>> +              (select-window (old-selected-window)))
>
> The discussion then dealt mostly with general quit-restore-windows
> issues, but I think this patch should be applied, since it fixes an
> annoying problem in Man.  So I've now pushed it to Emacs 28.

This gives rise to the following regression:

0. emacs -Q
1. (setq Man-notify-method 'aggressive) C-x C-e
2. M-x man RET mythical RET

This used to pop up and very quickly hide a window (but that's a
separate issue), and then the echo area displayed:

  Can't find the mythical manpage

Whereas now the phantom window remains displayed much longer, the echo
area displays:

  error in process sentinel:
  Wrong type argument: window-live-p, #<window 8>

and the *Messages* buffer also contains:

  error in process sentinel:
  Man-bgproc-sentinel: Wrong type argument: window-live-p, #<window 8>

Ideally a non-existent manpage would result only in the "can't find"
message, without any inadvertent Lisp errors or window dances.

Thanks,

-- 
Basil

bug#38164: quit-restore-window doesn't restore point in man

[Eli Zaretskii]

> From: "Basil L. Contovounesios" <contovob@tcd.ie>
> Date: Sun, 04 Apr 2021 19:13:01 +0100
> Cc: 38164@debbugs.gnu.org, Juri Linkov <juri@linkov.net>
> 
> Lars Ingebrigtsen <larsi@gnus.org> writes:
> 
> > Juri Linkov <juri@linkov.net> writes:
> >
> >> -            (quit-restore-window
> >> -             (get-buffer-window Man-buffer t) 'kill)
> >> +            (progn
> >> +              (quit-restore-window
> >> +               (get-buffer-window Man-buffer t) 'kill)
> >> +              (select-window (old-selected-window)))
> >
> > The discussion then dealt mostly with general quit-restore-windows
> > issues, but I think this patch should be applied, since it fixes an
> > annoying problem in Man.  So I've now pushed it to Emacs 28.
> 
> This gives rise to the following regression:
> 
> 0. emacs -Q
> 1. (setq Man-notify-method 'aggressive) C-x C-e
> 2. M-x man RET mythical RET
> 
> This used to pop up and very quickly hide a window (but that's a
> separate issue), and then the echo area displayed:
> 
>   Can't find the mythical manpage
> 
> Whereas now the phantom window remains displayed much longer, the echo
> area displays:
> 
>   error in process sentinel:
>   Wrong type argument: window-live-p, #<window 8>
> 
> and the *Messages* buffer also contains:
> 
>   error in process sentinel:
>   Man-bgproc-sentinel: Wrong type argument: window-live-p, #<window 8>

So we traded a minor issue for a more serious one.  (And if I try the
recipe which triggered that change, I see a perfectly expected
behavior in Emacs 24.)

I think that change should be reverted.

bug#38164: quit-restore-window doesn't restore point in man

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

> So we traded a minor issue for a more serious one.  (And if I try the
> recipe which triggered that change, I see a perfectly expected
> behavior in Emacs 24.)
>
> I think that change should be reverted.

The recipe is unclear -- I think it's really

M-x man RET man RET
select the man window
M-: (progn (man "XYZ") (read-string "-->"))

In Emacs 27, this will pop out of the read-string, which is the bug?

I'd rather fix the (setq Man-notify-method 'aggressive) regression than
bring that awkward interface bug back.

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

bug#38164: quit-restore-window doesn't restore point in man

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: "Basil L. Contovounesios" <contovob@tcd.ie>,  38164@debbugs.gnu.org,
>   juri@linkov.net
> Date: Sun, 04 Apr 2021 21:19:44 +0200
> 
> The recipe is unclear -- I think it's really
> 
> M-x man RET man RET
> select the man window
> M-: (progn (man "XYZ") (read-string "-->"))

Do you understand the practical importance of the last command?  IOW,
in which practical use case will 'man' be called like that?

> In Emacs 27, this will pop out of the read-string, which is the bug?

A very minor annoyance, I'd say.  It's easy dealt with.

> I'd rather fix the (setq Man-notify-method 'aggressive) regression than
> bring that awkward interface bug back.

If there's a practical use case there, I might agree.  Otherwise, we
will be jumping through hoops for a reason that isn't necessarily a
good one.

bug#38164: quit-restore-window doesn't restore point in man

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

>> The recipe is unclear -- I think it's really
>> 
>> M-x man RET man RET
>> select the man window
>> M-: (progn (man "XYZ") (read-string "-->"))
>
> Do you understand the practical importance of the last command?  IOW,
> in which practical use case will 'man' be called like that?

The practical issue was that you do an M-x man on something, and then
start doing something else (for instance a new M-x).  The error message
reported asynchronously will then select a random different buffer.

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

bug#38164: quit-restore-window doesn't restore point in man

[Lars Ingebrigtsen]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> I'd rather fix the (setq Man-notify-method 'aggressive) regression than
> bring that awkward interface bug back.

I've now worked around the issue with the immediate error in this
setting, but the basic issue still remains -- in some of the
Man-notify-method methods, the error ends up changing the selected
window upon an error (which shouldn't happen).

Somebody should go through all the combinations for that variable and
iron out the problems so that this never happens (and open a new bug
report for that).

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

bug#19064: 25.0.50; `message' overwrites `y-or-n-p' prompt, so user misses it

[Lars Ingebrigtsen]

Drew Adams <drew.adams@oracle.com> writes:

>> It would be helpful to have a recipe.
>
> Sorry, but recent Emacs 25 snapshots I have just crash all
> the time.  I cannot use Emacs 25 for much of anything, I'm
> afraid.
>
> But I think the bug description here should be sufficient.
> In particular, does this not seem appropriate to consider?
>
>   Seems like whenever `y-or-n-p' (or just `read-key') is waiting
>   for a key, `message' should do nothing.  Either it should echo
>   its message after the key is read or (maybe better) it should
>   do nothing at all.  As it stands now, this seems like a basic
>   UI problem, not just a minor annoyance.

Fixing a bug without a test case is much harder than if you have a test
case.

Perhaps you could make a recipe in Emacs 24?

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

bug#19064: 25.0.50; `message' overwrites `y-or-n-p' prompt, so user misses it

[Eli Zaretskii]

> Date: Sat, 26 Dec 2015 09:19:21 -0800 (PST)
> From: Drew Adams <drew.adams@oracle.com>
> Cc: 19064@debbugs.gnu.org
> 
> recent Emacs 25 snapshots I have just crash all the time.

If you want to solve this, please run Emacs under GDB and show the
backtrace when it crashes.

Thanks.