GNU bug report logs -
#17272
24.4.50; obsolete messages hides warning on startup
Previous Next
Reported by: Robert Marshall <robert <at> capuchin.co.uk>
Date: Tue, 15 Apr 2014 20:43:01 UTC
Severity: wishlist
Tags: confirmed, fixed
Merged with 446,
19064
Found in versions 24.4.50, 25.0.50
Fixed in version 27.0.50
Done: Juri Linkov <juri <at> linkov.net>
Bug is archived. No further changes may be made.
To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 17272 in the body.
You can then email your comments to 17272 AT debbugs.gnu.org in the normal way.
Toggle the display of automated, internal messages from the tracker.
Report forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#17272; Package
emacs.
(Tue, 15 Apr 2014 20:43:01 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
Robert Marshall <robert <at> capuchin.co.uk>:
New bug report received and forwarded. Copy sent to
bug-gnu-emacs <at> gnu.org.
(Tue, 15 Apr 2014 20:43:02 GMT)
Full text and
rfc822 format available.
Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
If you start emacs with the following loaded file (emacs -Q -l .emacs.test)
;;; .emacs.test
(require 'longlines)
(desktop-save-mode 1)
(desktop-read "/home/robert") ;; $HOME....
When it starts you see the message
Package longlines is obsolete!
But - if the .emacs.desktop is locked the message:
Warning: desktop file appears to be in use by PID 6464.
Using it may cause conflicts. Use it anyway? (y or n)
is hiding 'behind' the obsolete message and you don't see it until you
press a key - the emacs startup appears to have stopped but there's no
visual clue as to what it is waiting for.
In GNU Emacs 24.4.50.4 (i686-pc-linux-gnu, GTK+ Version 3.8.6)
of 2014-04-09 on poulenc
Repository revision: 116959 dancol <at> dancol.org-20140409081641-wcask11smm10bk3f
Windowing system distributor `The X.Org Foundation', version 11.0.11405000
System Description: Ubuntu 13.10
Configured features:
XPM JPEG TIFF GIF PNG RSVG IMAGEMAGICK SOUND GPM DBUS GCONF GSETTINGS
NOTIFY LIBSELINUX GNUTLS LIBXML2 FREETYPE M17N_FLT LIBOTF XFT ZLIB
Important settings:
value of $LANG: en_GB.UTF-8
locale-coding-system: utf-8-unix
Robert
--
Robert Marshall
Merged 17272 19064.
Request was from
Stefan Kangas <stefan <at> marxist.se>
to
control <at> debbugs.gnu.org.
(Sat, 21 Sep 2019 09:46:01 GMT)
Full text and
rfc822 format available.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#17272; Package
emacs.
(Mon, 07 Oct 2019 17:42:02 GMT)
Full text and
rfc822 format available.
Message #10 received at 17272 <at> debbugs.gnu.org (full text, mbox):
Lars Ingebrigtsen <larsi <at> gnus.org> writes:
> Michael Heerdegen <michael_heerdegen <at> 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
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#17272; Package
emacs.
(Tue, 08 Oct 2019 09:16:02 GMT)
Full text and
rfc822 format available.
Message #13 received at 17272 <at> debbugs.gnu.org (full text, mbox):
Lars Ingebrigtsen <larsi <at> 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.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#17272; Package
emacs.
(Tue, 08 Oct 2019 15:45:02 GMT)
Full text and
rfc822 format available.
Message #16 received at 17272 <at> debbugs.gnu.org (full text, mbox):
Michael Heerdegen <michael_heerdegen <at> 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
Forcibly Merged 446 17272 19064.
Request was from
Lars Ingebrigtsen <larsi <at> gnus.org>
to
control <at> debbugs.gnu.org.
(Sun, 13 Oct 2019 18:35:02 GMT)
Full text and
rfc822 format available.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#17272; Package
emacs.
(Tue, 05 Nov 2019 23:12:01 GMT)
Full text and
rfc822 format available.
Message #21 received at 17272 <at> debbugs.gnu.org (full text, mbox):
> 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.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#17272; Package
emacs.
(Wed, 06 Nov 2019 22:32:02 GMT)
Full text and
rfc822 format available.
Message #24 received at 17272 <at> debbugs.gnu.org (full text, mbox):
> If you start emacs with the following loaded file (emacs -Q -l .emacs.test)
>
> ;;; .emacs.test
> (require 'longlines)
> (desktop-save-mode 1)
> (desktop-read "/home/robert") ;; $HOME....
>
> When it starts you see the message
>
> Package longlines is obsolete!
>
> But - if the .emacs.desktop is locked the message:
>
> Warning: desktop file appears to be in use by PID 6464.
> Using it may cause conflicts. Use it anyway? (y or n)
>
> is hiding 'behind' the obsolete message and you don't see it until you
> press a key - the emacs startup appears to have stopped but there's no
> visual clue as to what it is waiting for.
Here is the patch that fixes this (required changes from bug#38076):
diff --git a/lisp/subr.el b/lisp/subr.el
index 03cf3da278..33464d6032 100644
--- a/lisp/subr.el
+++ b/lisp/subr.el
@@ -4517,7 +4556,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.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#17272; Package
emacs.
(Fri, 08 Nov 2019 20:59:02 GMT)
Full text and
rfc822 format available.
Message #27 received at 17272 <at> debbugs.gnu.org (full text, mbox):
Juri Linkov <juri <at> 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
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#17272; Package
emacs.
(Fri, 08 Nov 2019 21:20:01 GMT)
Full text and
rfc822 format available.
Message #30 received at 17272 <at> debbugs.gnu.org (full text, mbox):
> > - (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'.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#17272; Package
emacs.
(Sat, 09 Nov 2019 23:07:02 GMT)
Full text and
rfc822 format available.
Message #33 received at 17272 <at> debbugs.gnu.org (full text, mbox):
> If you start emacs with the following loaded file (emacs -Q -l .emacs.test)
>
> ;;; .emacs.test
> (require 'longlines)
> (desktop-save-mode 1)
> (desktop-read "/home/robert") ;; $HOME....
>
> When it starts you see the message
>
> Package longlines is obsolete!
>
> But - if the .emacs.desktop is locked the message:
>
> Warning: desktop file appears to be in use by PID 6464.
> Using it may cause conflicts. Use it anyway? (y or n)
>
> is hiding 'behind' the obsolete message and you don't see it until you
> press a key - the emacs startup appears to have stopped but there's no
> visual clue as to what it is waiting for.
This is fixed now.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#17272; Package
emacs.
(Sat, 09 Nov 2019 23:08:02 GMT)
Full text and
rfc822 format available.
Message #36 received at 17272 <at> debbugs.gnu.org (full text, mbox):
>> - (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?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#17272; Package
emacs.
(Tue, 12 Nov 2019 02:14:02 GMT)
Full text and
rfc822 format available.
Message #39 received at 17272 <at> debbugs.gnu.org (full text, mbox):
Juri Linkov <juri <at> 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
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#17272; Package
emacs.
(Tue, 12 Nov 2019 15:36:01 GMT)
Full text and
rfc822 format available.
Message #42 received at 17272 <at> debbugs.gnu.org (full text, mbox):
> > 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.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#17272; Package
emacs.
(Tue, 12 Nov 2019 22:21:01 GMT)
Full text and
rfc822 format available.
Message #45 received at 17272 <at> debbugs.gnu.org (full text, mbox):
> `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'.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#17272; Package
emacs.
(Tue, 12 Nov 2019 23:25:01 GMT)
Full text and
rfc822 format available.
Message #48 received at 17272 <at> debbugs.gnu.org (full text, mbox):
> > `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.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#17272; Package
emacs.
(Wed, 13 Nov 2019 21:31:02 GMT)
Full text and
rfc822 format available.
Message #51 received at 17272 <at> debbugs.gnu.org (full text, mbox):
Drew Adams <drew.adams <at> 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.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#17272; Package
emacs.
(Wed, 13 Nov 2019 21:54:02 GMT)
Full text and
rfc822 format available.
Message #54 received at 17272 <at> debbugs.gnu.org (full text, mbox):
>> 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.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#17272; Package
emacs.
(Wed, 13 Nov 2019 23:26:02 GMT)
Full text and
rfc822 format available.
Message #57 received at 17272 <at> debbugs.gnu.org (full text, mbox):
> 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.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#17272; Package
emacs.
(Thu, 14 Nov 2019 15:53:01 GMT)
Full text and
rfc822 format available.
Message #60 received at 17272 <at> debbugs.gnu.org (full text, mbox):
Drew Adams <drew.adams <at> 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.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#17272; Package
emacs.
(Thu, 14 Nov 2019 16:30:02 GMT)
Full text and
rfc822 format available.
Message #63 received at 17272 <at> debbugs.gnu.org (full text, mbox):
> > [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.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#17272; Package
emacs.
(Thu, 14 Nov 2019 17:08:02 GMT)
Full text and
rfc822 format available.
Message #66 received at 17272 <at> debbugs.gnu.org (full text, mbox):
Drew Adams <drew.adams <at> 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.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#17272; Package
emacs.
(Thu, 14 Nov 2019 17:18:01 GMT)
Full text and
rfc822 format available.
Message #69 received at 17272 <at> debbugs.gnu.org (full text, mbox):
> > 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.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#17272; Package
emacs.
(Thu, 14 Nov 2019 20:30:02 GMT)
Full text and
rfc822 format available.
Message #72 received at 17272 <at> debbugs.gnu.org (full text, mbox):
Drew Adams <drew.adams <at> 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.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#17272; Package
emacs.
(Sat, 16 Nov 2019 21:09:02 GMT)
Full text and
rfc822 format available.
Message #75 received at 17272 <at> debbugs.gnu.org (full text, mbox):
>> 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)
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#17272; Package
emacs.
(Sat, 16 Nov 2019 22:38:02 GMT)
Full text and
rfc822 format available.
Message #78 received at 17272 <at> debbugs.gnu.org (full text, mbox):
Juri Linkov <juri <at> 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.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#17272; Package
emacs.
(Sun, 17 Nov 2019 01:43:02 GMT)
Full text and
rfc822 format available.
Message #81 received at 17272 <at> debbugs.gnu.org (full text, mbox):
> > >>> 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?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#17272; Package
emacs.
(Sun, 17 Nov 2019 05:53:01 GMT)
Full text and
rfc822 format available.
Message #84 received at 17272 <at> debbugs.gnu.org (full text, mbox):
Juri Linkov <juri <at> 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
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#17272; Package
emacs.
(Sun, 17 Nov 2019 05:54:01 GMT)
Full text and
rfc822 format available.
Message #87 received at 17272 <at> debbugs.gnu.org (full text, mbox):
Juri Linkov <juri <at> 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
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#17272; Package
emacs.
(Sun, 17 Nov 2019 22:12:02 GMT)
Full text and
rfc822 format available.
Message #90 received at 17272 <at> debbugs.gnu.org (full text, mbox):
> 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.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#17272; Package
emacs.
(Sun, 17 Nov 2019 22:12:02 GMT)
Full text and
rfc822 format available.
Message #93 received at 17272 <at> debbugs.gnu.org (full text, mbox):
>> 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.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#17272; Package
emacs.
(Sun, 17 Nov 2019 23:55:02 GMT)
Full text and
rfc822 format available.
Message #96 received at 17272 <at> debbugs.gnu.org (full text, mbox):
> > 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.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#17272; Package
emacs.
(Mon, 18 Nov 2019 21:52:02 GMT)
Full text and
rfc822 format available.
Message #99 received at 17272 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
>>> 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:
[message-in-echo-area.patch (text/x-diff, inline)]
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);
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#17272; Package
emacs.
(Tue, 19 Nov 2019 08:14:02 GMT)
Full text and
rfc822 format available.
Message #102 received at 17272 <at> debbugs.gnu.org (full text, mbox):
Juri Linkov <juri <at> 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
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#17272; Package
emacs.
(Tue, 19 Nov 2019 11:12:02 GMT)
Full text and
rfc822 format available.
Message #105 received at 17272 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
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 <at> gnus.org> wrote:
> Juri Linkov <juri <at> 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
>
>
>
>
[Message part 2 (text/html, inline)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#17272; Package
emacs.
(Tue, 19 Nov 2019 23:21:02 GMT)
Full text and
rfc822 format available.
Message #108 received at 17272 <at> debbugs.gnu.org (full text, mbox):
>> 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.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#17272; Package
emacs.
(Tue, 19 Nov 2019 23:21:03 GMT)
Full text and
rfc822 format available.
Message #111 received at 17272 <at> debbugs.gnu.org (full text, mbox):
> 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.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#17272; Package
emacs.
(Tue, 19 Nov 2019 23:39:01 GMT)
Full text and
rfc822 format available.
Message #114 received at 17272 <at> debbugs.gnu.org (full text, mbox):
On Tue, Nov 19, 2019 at 11:20 PM Juri Linkov <juri <at> 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
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#17272; Package
emacs.
(Wed, 20 Nov 2019 10:56:02 GMT)
Full text and
rfc822 format available.
Message #117 received at 17272 <at> debbugs.gnu.org (full text, mbox):
Juri Linkov <juri <at> 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
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#17272; Package
emacs.
(Wed, 20 Nov 2019 22:48:02 GMT)
Full text and
rfc822 format available.
Message #120 received at 17272 <at> debbugs.gnu.org (full text, mbox):
> 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 ();
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#17272; Package
emacs.
(Wed, 20 Nov 2019 22:48:03 GMT)
Full text and
rfc822 format available.
Message #123 received at 17272 <at> debbugs.gnu.org (full text, mbox):
>> 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.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#17272; Package
emacs.
(Wed, 20 Nov 2019 23:45:05 GMT)
Full text and
rfc822 format available.
Message #126 received at 17272 <at> debbugs.gnu.org (full text, mbox):
Juri Linkov <juri <at> 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
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#17272; Package
emacs.
(Thu, 21 Nov 2019 08:24:01 GMT)
Full text and
rfc822 format available.
Message #129 received at 17272 <at> debbugs.gnu.org (full text, mbox):
Shouldn't this one
> + (enable-recursive-minibuffers t)
be protected too?
martin
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#17272; Package
emacs.
(Thu, 21 Nov 2019 23:04:02 GMT)
Full text and
rfc822 format available.
Message #132 received at 17272 <at> debbugs.gnu.org (full text, mbox):
>> 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.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#17272; Package
emacs.
(Thu, 21 Nov 2019 23:04:03 GMT)
Full text and
rfc822 format available.
Message #135 received at 17272 <at> debbugs.gnu.org (full text, mbox):
> Shouldn't this one
>
>> + (enable-recursive-minibuffers t)
>
> be protected too?
Protected from what?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#17272; Package
emacs.
(Thu, 21 Nov 2019 23:04:20 GMT)
Full text and
rfc822 format available.
Message #138 received at 17272 <at> debbugs.gnu.org (full text, mbox):
>>> 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?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#17272; Package
emacs.
(Thu, 21 Nov 2019 23:08:01 GMT)
Full text and
rfc822 format available.
Message #141 received at 17272 <at> debbugs.gnu.org (full text, mbox):
Juri Linkov <juri <at> 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
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#17272; Package
emacs.
(Fri, 22 Nov 2019 07:49:02 GMT)
Full text and
rfc822 format available.
Message #144 received at 17272 <at> debbugs.gnu.org (full text, mbox):
> From: Juri Linkov <juri <at> linkov.net>
> Date: Thu, 21 Nov 2019 23:39:42 +0200
> Cc: Michael Heerdegen <michael_heerdegen <at> web.de>, 17272 <at> debbugs.gnu.org,
> Lars Ingebrigtsen <larsi <at> gnus.org>, 19064 <at> 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.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#17272; Package
emacs.
(Fri, 22 Nov 2019 08:10:02 GMT)
Full text and
rfc822 format available.
Message #147 received at 17272 <at> debbugs.gnu.org (full text, mbox):
>> 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
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#17272; Package
emacs.
(Fri, 22 Nov 2019 17:39:01 GMT)
Full text and
rfc822 format available.
Message #150 received at 17272 <at> debbugs.gnu.org (full text, mbox):
> > 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.
+1.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#17272; Package
emacs.
(Sat, 23 Nov 2019 19:06:02 GMT)
Full text and
rfc822 format available.
Message #153 received at 17272 <at> debbugs.gnu.org (full text, mbox):
>>> 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?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#17272; Package
emacs.
(Sat, 23 Nov 2019 19:06:05 GMT)
Full text and
rfc822 format available.
Message #156 received at 17272 <at> debbugs.gnu.org (full text, mbox):
> 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?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#17272; Package
emacs.
(Sat, 23 Nov 2019 19:16:02 GMT)
Full text and
rfc822 format available.
Message #159 received at 17272 <at> debbugs.gnu.org (full text, mbox):
> From: Juri Linkov <juri <at> linkov.net>
> Cc: joaotavora <at> gmail.com, michael_heerdegen <at> web.de, 17272 <at> debbugs.gnu.org,
> larsi <at> gnus.org, 19064 <at> 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.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#17272; Package
emacs.
(Sat, 23 Nov 2019 19:17:01 GMT)
Full text and
rfc822 format available.
Message #162 received at 17272 <at> debbugs.gnu.org (full text, mbox):
> From: Juri Linkov <juri <at> linkov.net>
> Date: Sat, 23 Nov 2019 20:56:13 +0200
> Cc: Michael Heerdegen <michael_heerdegen <at> web.de>,
> Lars Ingebrigtsen <larsi <at> gnus.org>, 19064 <at> debbugs.gnu.org,
> 17272 <at> debbugs.gnu.org,
> João Távora <joaotavora <at> gmail.com>
>
> > + specbind (Qenable_recursive_minibuffers, Qt);
> >
> > then?
>
> It seems this is like unwind-protect?
No, it's like let-binding.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#17272; Package
emacs.
(Sat, 23 Nov 2019 22:25:02 GMT)
Full text and
rfc822 format available.
Message #165 received at 17272 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
>>> 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):
[message-in-echo-area.patch (text/x-diff, inline)]
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);
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#17272; Package
emacs.
(Tue, 26 Nov 2019 23:21:02 GMT)
Full text and
rfc822 format available.
Message #168 received at 17272 <at> debbugs.gnu.org (full text, mbox):
>> > 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.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#17272; Package
emacs.
(Tue, 26 Nov 2019 23:46:02 GMT)
Full text and
rfc822 format available.
Message #171 received at 17272 <at> debbugs.gnu.org (full text, mbox):
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.
Added tag(s) fixed.
Request was from
Juri Linkov <juri <at> linkov.net>
to
control <at> debbugs.gnu.org.
(Tue, 26 Nov 2019 23:46:03 GMT)
Full text and
rfc822 format available.
bug marked as fixed in version 27.0.50, send any further explanations to
17272 <at> debbugs.gnu.org and Robert Marshall <robert <at> capuchin.co.uk>
Request was from
Juri Linkov <juri <at> linkov.net>
to
control <at> debbugs.gnu.org.
(Tue, 26 Nov 2019 23:46:03 GMT)
Full text and
rfc822 format available.
bug marked as fixed in version 27.0.50, send any further explanations to
19064 <at> debbugs.gnu.org and Drew Adams <drew.adams <at> oracle.com>
Request was from
Juri Linkov <juri <at> linkov.net>
to
control <at> debbugs.gnu.org.
(Tue, 26 Nov 2019 23:46:03 GMT)
Full text and
rfc822 format available.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#17272; Package
emacs.
(Wed, 27 Nov 2019 00:49:02 GMT)
Full text and
rfc822 format available.
Message #180 received at 17272 <at> debbugs.gnu.org (full text, mbox):
> 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.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#17272; Package
emacs.
(Wed, 27 Nov 2019 11:56:01 GMT)
Full text and
rfc822 format available.
Message #183 received at 17272 <at> debbugs.gnu.org (full text, mbox):
Juri Linkov <juri <at> 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
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#17272; Package
emacs.
(Thu, 28 Nov 2019 23:44:02 GMT)
Full text and
rfc822 format available.
Message #186 received at 17272 <at> debbugs.gnu.org (full text, mbox):
>> 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 archived.
Request was from
Debbugs Internal Request <help-debbugs <at> gnu.org>
to
internal_control <at> debbugs.gnu.org.
(Fri, 27 Dec 2019 12:24:04 GMT)
Full text and
rfc822 format available.
This bug report was last modified 4 years and 324 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.