bug#34614: 26.1.92; When reading input in mini-buffer, message to each area overide the input prompt

bug#34614: 26.1.92; When reading input in mini-buffer, message to each area overide the input prompt

[Zhang Haijun]

For example, I run find-file, and then input file name in mini-buffer. During inputting, one buffer’s file has been changed externally. Emacs reverts the file and print a message to each area. Then I can’t see the prompt of find-file and chars I have inputted.


In GNU Emacs 26.1.92 (build 1, x86_64-apple-darwin17.7.0, NS appkit-1561.60 Version 10.13.6 (Build 17G5019))
 of 2019-02-14 built on jundeMac
Windowing system distributor 'Apple', version 10.3.1561
Recent messages:
For information about GNU Emacs and the GNU system, type C-h C-a.

Configured using:
 'configure --with-ns '--enable-locallisppath=/Library/Application
 Support/Emacs/${version}/site-lisp:/Library/Application
 Support/Emacs/site-lisp' --with-modules --disable-acl
 --without-makeinfo 'CC=cc ' CFLAGS=-O2
 PKG_CONFIG_PATH=/Users/jun/source/build-emacs-master/brew/lib/pkgconfig:'

Configured features:
JPEG NOTIFY GNUTLS LIBXML2 ZLIB TOOLKIT_SCROLL_BARS NS MODULES THREADS
LCMS2

Important settings:
  value of $LANG: zh_CN.UTF-8
  locale-coding-system: utf-8-unix

Major mode: Lisp Interaction

Minor modes in effect:
  tooltip-mode: t
  global-eldoc-mode: t
  eldoc-mode: t
  electric-indent-mode: t
  mouse-wheel-mode: t
  tool-bar-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  blink-cursor-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  line-number-mode: t
  transient-mark-mode: t

Load-path shadows:
None found.

Features:
(shadow sort mail-extr emacsbug message rmc puny seq byte-opt gv
bytecomp byte-compile cconv cl-loaddefs cl-lib dired dired-loaddefs
format-spec rfc822 mml easymenu mml-sec password-cache epa derived epg
epg-config gnus-util rmail rmail-loaddefs mm-decode mm-bodies mm-encode
mail-parse rfc2231 mailabbrev gmm-utils mailheader sendmail rfc2047
rfc2045 ietf-drums mm-util mail-prsvr mail-utils elec-pair time-date
china-util tooltip eldoc electric uniquify ediff-hook vc-hooks
lisp-float-type mwheel term/ns-win ns-win ucs-normalize mule-util
term/common-win tool-bar dnd fontset image regexp-opt fringe
tabulated-list replace newcomment text-mode elisp-mode lisp-mode
prog-mode register page menu-bar rfn-eshadow isearch timer select
scroll-bar mouse jit-lock font-lock syntax facemenu font-core
term/tty-colors frame cl-generic cham georgian utf-8-lang misc-lang
vietnamese tibetan thai tai-viet lao korean japanese eucjp-ms cp51932
hebrew greek romanian slovak czech european ethiopic indian cyrillic
chinese composite charscript charprop case-table epa-hook jka-cmpr-hook
help simple abbrev obarray minibuffer cl-preloaded nadvice loaddefs
button faces cus-face macroexp files text-properties overlay sha1 md5
base64 format env code-pages mule custom widget hashtable-print-readable
backquote threads kqueue cocoa ns lcms2 multi-tty make-network-process
emacs)

Memory information:
((conses 16 205135 13138)
 (symbols 48 20137 0)
 (miscs 40 373 180)
 (strings 32 28962 1883)
 (string-bytes 1 764900)
 (vectors 16 35914)
 (vector-slots 8 784151 7972)
 (floats 8 48 255)
 (intervals 56 223 0)
 (buffers 992 11))

bug#34614: 26.1.92; When reading input in mini-buffer, message to each area overide the input prompt

[Eli Zaretskii]

> From: Zhang Haijun <ccsmile2008@outlook.com>
> Date: Fri, 22 Feb 2019 12:17:57 +0000
> 
> For example, I run find-file, and then input file name in mini-buffer. During inputting, one buffer’s file has been changed externally. Emacs reverts the file and print a message to each area. Then I can’t see the prompt of find-file and chars I have inputted.

Not even if you wait for some time, or move cursor?

bug#34614: 26.1.92; When reading input in mini-buffer, message to each area overide the input prompt

[Zhang Haijun]

> 在 2019年2月22日，下午9:20，Eli Zaretskii <eliz@gnu.org> 写道：
> 
> Not even if you wait for some time
No. I waited for about 15s.

> , or move cursor?
Yes. But many keys are bound to some functions(For example up or down key are bound in ido-find-file). I have to press C-g and then run the command again.

bug#34614: 26.1.92; When reading input in mini-buffer, message to each area overide the input prompt

[martin rudalics]

 > For example, I run find-file, and then input file name in
 > mini-buffer. During inputting, one buffer’s file has been changed
 > externally. Emacs reverts the file and print a message to each
 > area. Then I can’t see the prompt of find-file and chars I have
 > inputted.

Please tell us a bit more about what you did.  IIUC you must have had
enabled 'auto-revert-mode' in that session but I can't find it in the
list of "minor modes in effect" of your report.  If you did use
'auto-revert-mode', did you have any related customizations?  If so,
which?  If you can repeat the bug, can you also repeat it when you
reset 'auto-revert-stop-on-user-input' and/or 'auto-revert-verbose'?

Also, was your formulation "print a message to each area" intentional?
Here a message is printed to the echo area of the selected frame only,
that is, to one and only one echo area.

 > I have to press C-g and then run the command again.

What does 'minibuffer-depth' return at the time you have to press C-g?
Can you enter the minibuffer window via C-x o?

Thanks, martin

bug#34614: 26.1.92; When reading input in mini-buffer, message to each area overide the input prompt

[Zhang Haijun]

> 在 2019年2月22日，下午11:07，martin rudalics <rudalics@gmx.at> 写道：
> 
> > For example, I run find-file, and then input file name in
> > mini-buffer. During inputting, one buffer’s file has been changed
> > externally. Emacs reverts the file and print a message to each
> > area. Then I can’t see the prompt of find-file and chars I have
> > inputted.
> 
> Please tell us a bit more about what you did.  IIUC you must have had
> enabled 'auto-revert-mode' in that session but I can't find it in the
> list of "minor modes in effect" of your report.  If you did use
> 'auto-revert-mode', did you have any related customizations?  If so,
> which?  If you can repeat the bug, can you also repeat it when you
> reset 'auto-revert-stop-on-user-input' and/or 'auto-revert-verbose’?

Sorry. I use wrong emacs instance to report the bug.

Steps to reproduce the bug:
1. start emacs with emacs -Q
2. M-x global-auto-revert-mode
3. Open a test file with emacs
4. M-x find-file, it will prompt and read file name
5.  modify the test file with other tool and save the file
6. emacs will revert the file and print a message like "Reverting buffer xxx”.
7. the find-file ui will not come back.


> Also, was your formulation "print a message to each area" intentional?
> Here a message is printed to the echo area of the selected frame only,
> that is, to one and only one echo area.
> 
> > I have to press C-g and then run the command again.
> 
> What does 'minibuffer-depth' return at the time you have to press C-g?
> Can you enter the minibuffer window via C-x o?

The cursor was in minibuffer then and I could input more chars in minibuffer.
I press C-g only because I didn’t remember what I have inputted(Because I couldn’t see them then.). For me running the command again is cheaper and safer than continuing the blind inputting.

bug#34614: 26.1.92; When reading input in mini-buffer, message to each area overide the input prompt

[martin rudalics]

> Steps to reproduce the bug:
> 1. start emacs with emacs -Q
> 2. M-x global-auto-revert-mode
> 3. Open a test file with emacs
> 4. M-x find-file, it will prompt and read file name
> 5.  modify the test file with other tool and save the file
> 6. emacs will revert the file and print a message like "Reverting buffer xxx”.
> 7. the find-file ui will not come back.

It comes back here with the next character I type.  I have no idea how
to fix this.  At least sitting for 'minibuffer-message-timeout' in
'auto-revert-handler' when the minibuffer depth is greater zero won't
cut it - the message gets cleared immediately and minibuffer contents
are restored.  Some 'sit-for' snafu, I suppose.

martin, trying to resend this

bug#34614: 26.1.92; When reading input in mini-buffer, message to each area overide the input prompt

[Zhang Haijun]

> 在 2019年2月23日，上午2:47，martin rudalics <rudalics@gmx.at> 写道：
> 
> > Steps to reproduce the bug:
> > 1. start emacs with emacs -Q
> > 2. M-x global-auto-revert-mode
> > 3. Open a test file with emacs
> > 4. M-x find-file, it will prompt and read file name
> > 5.  modify the test file with other tool and save the file
> > 6. emacs will revert the file and print a message like "Reverting buffer xxx”.
> > 7. the find-file ui will not come back.
> 
> It comes back here with the next character I type.

Same here. Blind typing only for next one char.

> I have no idea how
> to fix this.  At least sitting for 'minibuffer-message-timeout' in
> 'auto-revert-handler' when the minibuffer depth is greater zero won't
> cut it - the message gets cleared immediately and minibuffer contents
> are restored.  Some 'sit-for' snafu, I suppose.
> 
> martin
> 

According the doc string of minibuffer-message-timeout, the input UI will be restored after the timeout.

If I resize the frame, the input UI is restored. Maybe there just needs a redisplay after the timeout?

bug#34614: 26.1.92; When reading input in mini-buffer, message to each area overide the input prompt

[Zhang Haijun]

> 在 2019年2月23日，上午10:01，张海君 <ccsmile2008@outlook.com> 写道：
> 
> minibuffer-message-timeout

On timeout of minibuffer-message-timeout, can emacs trigger a redisplay?

bug#34614: 26.1.92; When reading input in mini-buffer, message to each area overide the input prompt

[Eli Zaretskii]

> Date: Fri, 22 Feb 2019 22:38:05 +0100
> From: martin rudalics <rudalics@gmx.at>
> 
> > Steps to reproduce the bug:
> > 1. start emacs with emacs -Q
> > 2. M-x global-auto-revert-mode
> > 3. Open a test file with emacs
> > 4. M-x find-file, it will prompt and read file name
> > 5.  modify the test file with other tool and save the file
> > 6. emacs will revert the file and print a message like "Reverting buffer xxx”.
> > 7. the find-file ui will not come back.
> 
> It comes back here with the next character I type.  I have no idea how
> to fix this.  At least sitting for 'minibuffer-message-timeout' in
> 'auto-revert-handler' when the minibuffer depth is greater zero won't
> cut it - the message gets cleared immediately and minibuffer contents
> are restored.  Some 'sit-for' snafu, I suppose.

Could we use the technique used in with-temp-message?  That macro
cannot be used directly here, I think, because reverting a buffer
might ask some questions.  But maybe we could do something similar by
hand inside revert-buffer--default?

bug#34614: 26.1.92; When reading input in mini-buffer, message to each area overide the input prompt

[martin rudalics]

 >> minibuffer-message-timeout
 >
 > On timeout of minibuffer-message-timeout, can emacs trigger a redisplay?

That's what I tried in 'auto-revert-handler':

       (when (and auto-revert-verbose
                  (not (eq revert 'fast)))
         (message "Reverting buffer `%s'." (buffer-name))
         (when (> (minibuffer-depth 0))
           (sit-for minibuffer-message-timeout)
           (message nil)))

But then the message flashes for a short moment here, Emacs redisplays
and switches back to the prompt.  So for some reason 'sit-for' doesn't
work as advertised when Emacs is waiting for input.

martin

bug#34614: 26.1.92; When reading input in mini-buffer, message to each area overide the input prompt

[martin rudalics]

 > Could we use the technique used in with-temp-message?  That macro
 > cannot be used directly here, I think, because reverting a buffer
 > might ask some questions.  But maybe we could do something similar by
 > hand inside revert-buffer--default?

Autoreverting asks no questions, it just issues an informative
message.  The buffer has been already reverted for good at that time.
Any macro we'd want here would need a timeout - and apparently that
won't work while waiting for input.  Probably I'm missing something
utterly trivial.

martin

bug#34614: 26.1.92; When reading input in mini-buffer, message to each area overide the input prompt

[Eli Zaretskii]

> From: Zhang Haijun <ccsmile2008@outlook.com>
> Date: Sat, 23 Feb 2019 02:33:23 +0000
> Cc: "34614@debbugs.gnu.org" <34614@debbugs.gnu.org>
> 
> On timeout of minibuffer-message-timeout, can emacs trigger a redisplay?

Are you sure a missing redisplay is the problem here?  In general,
Emacs should know by itself there's a need for redisplay.

bug#34614: 26.1.92; When reading input in mini-buffer, message to each area overide the input prompt

[Zhang Haijun]

> 在 2019年2月23日，下午3:53，martin rudalics <rudalics@gmx.at> 写道：
> 
> >> minibuffer-message-timeout
> >
> > On timeout of minibuffer-message-timeout, can emacs trigger a redisplay?
> 
> That's what I tried in 'auto-revert-handler':
> 
>      (when (and auto-revert-verbose
>                 (not (eq revert 'fast)))
>        (message "Reverting buffer `%s'." (buffer-name))
>        (when (> (minibuffer-depth 0))
>          (sit-for minibuffer-message-timeout)
>          (message nil)))
> 
> But then the message flashes for a short moment here, Emacs redisplays
> and switches back to the prompt.  So for some reason 'sit-for' doesn't
> work as advertised when Emacs is waiting for input.
> 
> martin

I see the variable 'minibuffer-message-timeout’ is defined in c source code. Maybe emacs processes it in c source code already, which conflicts with sit-for?

bug#34614: 26.1.92; When reading input in mini-buffer, message to each area overide the input prompt

[Eli Zaretskii]

> Date: Sat, 23 Feb 2019 08:54:13 +0100
> From: martin rudalics <rudalics@gmx.at>
> CC: 34614@debbugs.gnu.org
> 
>  > Could we use the technique used in with-temp-message?  That macro
>  > cannot be used directly here, I think, because reverting a buffer
>  > might ask some questions.  But maybe we could do something similar by
>  > hand inside revert-buffer--default?
> 
> Autoreverting asks no questions, it just issues an informative
> message.  The buffer has been already reverted for good at that time.
> Any macro we'd want here would need a timeout - and apparently that
> won't work while waiting for input.  Probably I'm missing something
> utterly trivial.

Or possibly I'm missing something.  Can you point me to the code which
issues that informative message when the buffer has been already
reverted?

bug#34614: 26.1.92; When reading input in mini-buffer, message to each area overide the input prompt

[Zhang Haijun]

> 在 2019年2月23日，下午4:01，Eli Zaretskii <eliz@gnu.org> 写道：
> 
>> From: Zhang Haijun <ccsmile2008@outlook.com>
>> Date: Sat, 23 Feb 2019 02:33:23 +0000
>> Cc: "34614@debbugs.gnu.org" <34614@debbugs.gnu.org>
>> 
>> On timeout of minibuffer-message-timeout, can emacs trigger a redisplay?
> 
> Are you sure a missing redisplay is the problem here?  In general,
> Emacs should know by itself there's a need for redisplay.

I’m not sure. But the input UI comes back after either of the following operations:
1. resize the frame
2. resize a window with mouse dragging in the frame
3. Mouse click on anywhere in the frame

It seems that it just needs a redisplay.

bug#34614: 26.1.92; When reading input in mini-buffer, message to each area overide the input prompt

[martin rudalics]

 > I see the variable 'minibuffer-message-timeout’ is defined in c
 > source code. Maybe emacs processes it in c source code already,
 > which conflicts with sit-for?

I before verified with the debugger that 'minibuffer-message-timeout'
is not processed during autoreverting.  It is processed only if
triggered from the main loop, that is, after reading a character.

martin

bug#34614: 26.1.92; When reading input in mini-buffer, message to each area overide the input prompt

[martin rudalics]

 > Or possibly I'm missing something.  Can you point me to the code which
 > issues that informative message when the buffer has been already
 > reverted?

It's this message in autorevert.el:

     (when revert
       (when (and auto-revert-verbose
                  (not (eq revert 'fast)))
         (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.

martin

bug#34614: 26.1.92; When reading input in mini-buffer, message to each area overide the input prompt

[Eli Zaretskii]

> Date: Sat, 23 Feb 2019 09:29:52 +0100
> From: martin rudalics <rudalics@gmx.at>
> CC: 34614@debbugs.gnu.org
> 
>  > Or possibly I'm missing something.  Can you point me to the code which
>  > issues that informative message when the buffer has been already
>  > reverted?
> 
> It's this message in autorevert.el:
> 
>      (when revert
>        (when (and auto-revert-verbose
>                   (not (eq revert 'fast)))
>          (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.

Thanks.  But this is _before_ actually reverting the buffer, so just
wrapping the whole thing after the above in with-temp-message could
work, no?

By "asking questions" I mean what revert-buffer does in
revert-buffer--default.  The questions are only asked in specific rare
situations, but still.

bug#34614: 26.1.92; When reading input in mini-buffer, message to each area overide the input prompt

[martin rudalics]

 > Thanks.  But this is _before_ actually reverting the buffer, so just
 > wrapping the whole thing after the above in with-temp-message could
 > work, no?

I'm afraid that reverting happens too fast to make that useful without
a timeout.  In either case what would you suggest to do in the unwind
form?  Would a 'set-window-buffer' suffice?

 > By "asking questions" I mean what revert-buffer does in
 > revert-buffer--default.  The questions are only asked in specific rare
 > situations, but still.

Autoreverting has

             (revert-buffer 'ignore-auto 'dont-ask 'preserve-modes))))

Does that mean 'revert-buffer--default' could still ask questions?

martin

bug#34614: 26.1.92; When reading input in mini-buffer, message to each area overide the input prompt

[Eli Zaretskii]

> Date: Sat, 23 Feb 2019 10:57:36 +0100
> From: martin rudalics <rudalics@gmx.at>
> CC: 34614@debbugs.gnu.org
> 
>  > Thanks.  But this is _before_ actually reverting the buffer, so just
>  > wrapping the whole thing after the above in with-temp-message could
>  > work, no?
> 
> I'm afraid that reverting happens too fast to make that useful without
> a timeout.

But we could do what with-temp-message does manually, and sit-for
before replacing the message, no?

> In either case what would you suggest to do in the unwind form?

I'm not following: what unwind form?

> Autoreverting has
> 
>              (revert-buffer 'ignore-auto 'dont-ask 'preserve-modes))))
> 
> Does that mean 'revert-buffer--default' could still ask questions?

I don't know, I didn't look closely enough.

bug#34614: 26.1.92; When reading input in mini-buffer, message to each area overide the input prompt

[martin rudalics]

 > But we could do what with-temp-message does manually, and sit-for
 > before replacing the message, no?

Here 'sit-for' doesn't sit for in that place.

 >> In either case what would you suggest to do in the unwind form?
 >
 > I'm not following: what unwind form?

The one we would have to write in the spirit of 'with-temp-message'
where we would probably redisplay the contents of the active minibuffer
instead of the message.

 >> Autoreverting has
 >>
 >>               (revert-buffer 'ignore-auto 'dont-ask 'preserve-modes))))
 >>
 >> Does that mean 'revert-buffer--default' could still ask questions?
 >
 > I don't know, I didn't look closely enough.

Any question it asks would get us into a recursive minibuffer I
presume.

martin

bug#34614: 26.1.92; When reading input in mini-buffer, message to each area overide the input prompt

[Eli Zaretskii]

> Date: Sat, 23 Feb 2019 15:02:26 +0100
> From: martin rudalics <rudalics@gmx.at>
> CC: 34614@debbugs.gnu.org
> 
>  > But we could do what with-temp-message does manually, and sit-for
>  > before replacing the message, no?
> 
> Here 'sit-for' doesn't sit for in that place.

Can you tell what event(s) stop(s) the wait?

bug#34614: 26.1.92; When reading input in mini-buffer, message to each area overide the input prompt

[martin rudalics]

 >> Here 'sit-for' doesn't sit for in that place.
 >
 > Can you tell what event(s) stop(s) the wait?

AFAICT it's pending input via

    ((input-pending-p t)
     nil)

martin

bug#34614: 26.1.92; When reading input in mini-buffer, message to each area overide the input prompt

[Eli Zaretskii]

> Date: Sun, 24 Feb 2019 09:44:10 +0100
> From: martin rudalics <rudalics@gmx.at>
> CC: 34614@debbugs.gnu.org
> 
>  >> Here 'sit-for' doesn't sit for in that place.
>  >
>  > Can you tell what event(s) stop(s) the wait?
> 
> AFAICT it's pending input via
> 
>     ((input-pending-p t)
>      nil)

Yes, but I asked what kind of input event causes that.  Since you
didn't type anything at this point, it cannot be keyboard input, so
what non-keyboard event did that?

Anyway, I cannot reproduce anything like that, your change in
autorevert-handler works just fine for me on MS-Windows.  Did you test
in "emacs -Q"?

It might also be important whether autorevert works with file
notifications or not.

bug#34614: 26.1.92; When reading input in mini-buffer, message to each area overide the input prompt

[martin rudalics]

 > Yes, but I asked what kind of input event causes that.  Since you
 > didn't type anything at this point, it cannot be keyboard input, so
 > what non-keyboard event did that?

Elementary:

(gdb) p event->kind
$8 = FILE_NOTIFY_EVENT

 > Anyway, I cannot reproduce anything like that, your change in
 > autorevert-handler works just fine for me on MS-Windows.  Did you test
 > in "emacs -Q"?

With emacs -Q and 'global-auto-revert-mode' enabled.

 > It might also be important whether autorevert works with file
 > notifications or not.

Does the above show that it does?  On Windows XP, if that matters.

martin

bug#34614: 26.1.92; When reading input in mini-buffer, message to each area overide the input prompt

[Eli Zaretskii]

> Date: Sun, 24 Feb 2019 19:31:10 +0100
> From: martin rudalics <rudalics@gmx.at>
> CC: 34614@debbugs.gnu.org
> 
>  > Yes, but I asked what kind of input event causes that.  Since you
>  > didn't type anything at this point, it cannot be keyboard input, so
>  > what non-keyboard event did that?
> 
> Elementary:
> 
> (gdb) p event->kind
> $8 = FILE_NOTIFY_EVENT

That's what I thought.  Does it help to explicitly restart sit-for for
the remainder of the time if this event comes in?

>  > Anyway, I cannot reproduce anything like that, your change in
>  > autorevert-handler works just fine for me on MS-Windows.  Did you test
>  > in "emacs -Q"?
> 
> With emacs -Q and 'global-auto-revert-mode' enabled.
> 
>  > It might also be important whether autorevert works with file
>  > notifications or not.
> 
> Does the above show that it does?  On Windows XP, if that matters.

Strange, I did the same.

bug#34614: 26.1.92; When reading input in mini-buffer, message to each area overide the input prompt

[martin rudalics]

 > That's what I thought.  Does it help to explicitly restart sit-for for
 > the remainder of the time if this event comes in?

I wouldn't know where to do that in autorevert.el.

martin

bug#34614: 26.1.92; When reading input in mini-buffer, message to each area overide the input prompt

[Juri Linkov]

> Steps to reproduce the bug:
> 1. start emacs with emacs -Q
> 2. M-x global-auto-revert-mode
> 3. Open a test file with emacs
> 4. M-x find-file, it will prompt and read file name
> 5.  modify the test file with other tool and save the file
> 6. emacs will revert the file and print a message like "Reverting buffer xxx”.
> 7. the find-file ui will not come back.

Please try the following patch:

diff --git a/lisp/autorevert.el b/lisp/autorevert.el
index 9275513c8d..bbc4e8a4e2 100644
--- a/lisp/autorevert.el
+++ b/lisp/autorevert.el
@@ -815,7 +815,7 @@ auto-revert-handler
     (when revert
       (when (and auto-revert-verbose
                  (not (eq revert 'fast)))
-        (message "Reverting buffer `%s'." (buffer-name)))
+        (minibuffer-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.

bug#34614: 26.1.92; When reading input in mini-buffer, message to each area overide the input prompt

[HaiJun Zhang]

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

在 2019年11月7日 +0800 AM6:33，Juri Linkov <juri@linkov.net>，写道：
Please try the following patch:

diff --git a/lisp/autorevert.el b/lisp/autorevert.el
index 9275513c8d..bbc4e8a4e2 100644
--- a/lisp/autorevert.el
+++ b/lisp/autorevert.el
@@ -815,7 +815,7 @@ auto-revert-handler
(when revert
(when (and auto-revert-verbose
(not (eq revert 'fast)))
- (message "Reverting buffer `%s'." (buffer-name)))
+ (minibuffer-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.

The prompt is replaced with the message from autorevert. And after about 2~3 seconds (not fixed), the prompt comes back. What controls the delay(2~3 seconds)? It is not the value of minibuffer-message-timeout, which is 0.6. Is this expected?

And it behaves differently with the following test code:

(progn (run-with-idle-timer 3 nil
       (lambda ()
         (minibuffer-message “Reverting buffer `%s’." (buffer-name))))
    (call-interactively ‘find-file))

This works well. The prompt is NOT replaced. The message is appended to the end of the prompt and disappears after 0.6 second.


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

bug#34614: 26.1.92; When reading input in mini-buffer, message to each area overide the input prompt

[Juri Linkov]

> The prompt is replaced with the message from autorevert. And after
> about 2~3 seconds (not fixed), the prompt comes back. What controls
> the delay(2~3 seconds)? It is not the value of
> minibuffer-message-timeout, which is 0.6. Is this expected?

The problem is that when auto-revert-handler calls minibuffer-message,
the current buffer is not the minibuffer, because functions that call
auto-revert-handler (auto-revert-notify-handler, auto-revert--end-lockout,
or auto-revert-buffers) change the current buffer using with-current-buffer.

When the current buffer is not the minibuffer then minibuffer-message
just calls (message "%s" message) and then does
(sit-for (or minibuffer-message-timeout 1000000))

> And it behaves differently with the following test code:
>
> (progn (run-with-idle-timer 3 nil
>        (lambda ()
>          (minibuffer-message "Reverting buffer `%s'." (buffer-name))))
>     (call-interactively 'find-file))
>
> This works well. The prompt is NOT replaced. The message is appended
> to the end of the prompt and disappears after 0.6 second.

To work well like this, minibuffer-message should be called outside
of with-current-buffer code block.  Yesterday I fixed Man-bgproc-sentinel
in bug#19064 to call minibuffer-message outside of with-current-buffer.

But auto-revert functions require complete rewrite.  I don't see
how this could be fixed with a simple change.

bug#34614: 26.1.92; When reading input in mini-buffer, message to each area overide the input prompt

[HaiJun Zhang]

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

I got it. Thanks for your explaination.

It is strange that minibuffer-message-timeout is defined in C.
But the timeout is processed in lisp (in the function minibuffer-message).

在 2019年11月8日 +0800 AM6:58，Juri Linkov <juri@linkov.net>，写道：
The prompt is replaced with the message from autorevert. And after
about 2~3 seconds (not fixed), the prompt comes back. What controls
the delay(2~3 seconds)? It is not the value of
minibuffer-message-timeout, which is 0.6. Is this expected?

The problem is that when auto-revert-handler calls minibuffer-message,
the current buffer is not the minibuffer, because functions that call
auto-revert-handler (auto-revert-notify-handler, auto-revert--end-lockout,
or auto-revert-buffers) change the current buffer using with-current-buffer.

When the current buffer is not the minibuffer then minibuffer-message
just calls (message "%s" message) and then does
(sit-for (or minibuffer-message-timeout 1000000))

And it behaves differently with the following test code:

(progn (run-with-idle-timer 3 nil
(lambda ()
(minibuffer-message "Reverting buffer `%s'." (buffer-name))))
(call-interactively 'find-file))

This works well. The prompt is NOT replaced. The message is appended
to the end of the prompt and disappears after 0.6 second.

To work well like this, minibuffer-message should be called outside
of with-current-buffer code block. Yesterday I fixed Man-bgproc-sentinel
in bug#19064 to call minibuffer-message outside of with-current-buffer.

But auto-revert functions require complete rewrite. I don't see
how this could be fixed with a simple change.

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

bug#34614: 26.1.92; When reading input in mini-buffer, message to each area overide the input prompt

[Juri Linkov]

> I got it. Thanks for your explaination.
>
> It is strange that minibuffer-message-timeout is defined in C.
> But the timeout is processed in lisp (in the function minibuffer-message).
>
> 在 2019年11月8日 +0800 AM6:58，Juri Linkov <juri@linkov.net>，写道：
>
>         The prompt is replaced with the message from autorevert. And after
>         about 2~3 seconds (not fixed), the prompt comes back. What controls
>         the delay(2~3 seconds)? It is not the value of
>         minibuffer-message-timeout, which is 0.6. Is this expected?
>
>     The problem is that when auto-revert-handler calls minibuffer-message,
>     the current buffer is not the minibuffer, because functions that call
>     auto-revert-handler (auto-revert-notify-handler, auto-revert--end-lockout,
>     or auto-revert-buffers) change the current buffer using with-current-buffer.
>    
>     When the current buffer is not the minibuffer then minibuffer-message
>     just calls (message "%s" message) and then does
>     (sit-for (or minibuffer-message-timeout 1000000))
>
>         And it behaves differently with the following test code:
>        
>         (progn (run-with-idle-timer 3 nil
>         (lambda ()
>         (minibuffer-message "Reverting buffer `%s'." (buffer-name))))
>         (call-interactively 'find-file))
>        
>         This works well. The prompt is NOT replaced. The message is appended
>         to the end of the prompt and disappears after 0.6 second.
>
>     To work well like this, minibuffer-message should be called outside
>     of with-current-buffer code block. Yesterday I fixed Man-bgproc-sentinel
>     in bug#19064 to call minibuffer-message outside of with-current-buffer.
>    
>     But auto-revert functions require complete rewrite. I don't see
>     how this could be fixed with a simple change.

Actually I found a solution with two alternatives, and both works well,
and I can't decide which is less error-prone.  This patch shows both:

diff --git a/lisp/autorevert.el b/lisp/autorevert.el
index 9275513c8d..17678010f1 100644
--- a/lisp/autorevert.el
+++ b/lisp/autorevert.el
@@ -815,7 +815,13 @@ auto-revert-handler
     (when revert
       (when (and auto-revert-verbose
                  (not (eq revert 'fast)))
-        (message "Reverting buffer `%s'." (buffer-name)))
+        ;; 1.
+        (with-selected-window (old-selected-window)
+          (minibuffer-message "Reverting buffer `%s'." (buffer-name)))
+        ;; 2.
+        ;; (with-current-buffer (window-buffer (old-selected-window))
+        ;;   (minibuffer-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.

bug#34614: 26.1.92; When reading input in mini-buffer, message to each area overide the input prompt

[HaiJun Zhang]

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

Thanks. I think it will be better if emacs can record the last buffer(Including minibuffer) selected manually by the user and provide a function like selected-buffer to return this buffer. And minibuffer-message can use this.
在 2019年11月10日 +0800 AM7:07，Juri Linkov <juri@linkov.net>，写道：
I got it. Thanks for your explaination.

It is strange that minibuffer-message-timeout is defined in C.
But the timeout is processed in lisp (in the function minibuffer-message).

在 2019年11月8日 +0800 AM6:58，Juri Linkov <juri@linkov.net>，写道：

The prompt is replaced with the message from autorevert. And after
about 2~3 seconds (not fixed), the prompt comes back. What controls
the delay(2~3 seconds)? It is not the value of
minibuffer-message-timeout, which is 0.6. Is this expected?

The problem is that when auto-revert-handler calls minibuffer-message,
the current buffer is not the minibuffer, because functions that call
auto-revert-handler (auto-revert-notify-handler, auto-revert--end-lockout,
or auto-revert-buffers) change the current buffer using with-current-buffer.

When the current buffer is not the minibuffer then minibuffer-message
just calls (message "%s" message) and then does
(sit-for (or minibuffer-message-timeout 1000000))

And it behaves differently with the following test code:

(progn (run-with-idle-timer 3 nil
(lambda ()
(minibuffer-message "Reverting buffer `%s'." (buffer-name))))
(call-interactively 'find-file))

This works well. The prompt is NOT replaced. The message is appended
to the end of the prompt and disappears after 0.6 second.

To work well like this, minibuffer-message should be called outside
of with-current-buffer code block. Yesterday I fixed Man-bgproc-sentinel
in bug#19064 to call minibuffer-message outside of with-current-buffer.

But auto-revert functions require complete rewrite. I don't see
how this could be fixed with a simple change.

Actually I found a solution with two alternatives, and both works well,
and I can't decide which is less error-prone. This patch shows both:

diff --git a/lisp/autorevert.el b/lisp/autorevert.el
index 9275513c8d..17678010f1 100644
--- a/lisp/autorevert.el
+++ b/lisp/autorevert.el
@@ -815,7 +815,13 @@ auto-revert-handler
(when revert
(when (and auto-revert-verbose
(not (eq revert 'fast)))
- (message "Reverting buffer `%s'." (buffer-name)))
+ ;; 1.
+ (with-selected-window (old-selected-window)
+ (minibuffer-message "Reverting buffer `%s'." (buffer-name)))
+ ;; 2.
+ ;; (with-current-buffer (window-buffer (old-selected-window))
+ ;; (minibuffer-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.


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

bug#34614: 26.1.92; When reading input in mini-buffer, message to each area overide the input prompt

[Juri Linkov]

tags 34614 + fixed
close 34614 27.0.50
thanks

> Thanks.  I think it will be better if emacs can record the last
> buffer(Including minibuffer) selected manually by the user and provide
> a function like selected-buffer to return this buffer.
> And minibuffer-message can use this.

old-selected-window does exactly the same - it records the last window,
and getting its buffer is easy with just window-buffer.

Since now everything is fixed, I'm closing this bug report.
Thanks for reporting it.

bug#34614: 26.1.92; When reading input in mini-buffer, message to each area overide the input prompt

[HaiJun Zhang]

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

在 2019年11月11日 +0800 AM5:23，Juri Linkov <juri@linkov.net>，写道：
tags 34614 + fixed
close 34614 27.0.50
thanks

Thanks. I think it will be better if emacs can record the last
buffer(Including minibuffer) selected manually by the user and provide
a function like selected-buffer to return this buffer.
And minibuffer-message can use this.

old-selected-window does exactly the same - it records the last window,
and getting its buffer is easy with just window-buffer.

Doesn’t set-buffer and with-current-buffer change the current buffer in the window? They are not selected manually by user.





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

bug#34614: 26.1.92; When reading input in mini-buffer, message to each area overide the input prompt

[HaiJun Zhang]

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

And why don’t check the old selected buffer in minibuffer-message?
在 2019年11月11日 +0800 AM5:23，Juri Linkov <juri@linkov.net>，写道：
tags 34614 + fixed
close 34614 27.0.50
thanks

Thanks. I think it will be better if emacs can record the last
buffer(Including minibuffer) selected manually by the user and provide
a function like selected-buffer to return this buffer.
And minibuffer-message can use this.

old-selected-window does exactly the same - it records the last window,
and getting its buffer is easy with just window-buffer.

Since now everything is fixed, I'm closing this bug report.
Thanks for reporting it.

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

bug#34614: 26.1.92; When reading input in mini-buffer, message to each area overide the input prompt

[martin rudalics]

 > Thanks. I think it will be better if emacs can record the last
 > buffer(Including minibuffer) selected manually by the user

That will be next to impossible.

 > and provide
 > a function like selected-buffer to return this buffer.
 > And minibuffer-message can use this.
 >
 > old-selected-window does exactly the same - it records the last window,
 > and getting its buffer is easy with just window-buffer.
 >
 > Doesn’t set-buffer and with-current-buffer change the current buffer in the window?

No.  Only set_window_buffer does that.

 > They are not selected manually by user.

How would you know?

martin

bug#34614: 26.1.92; When reading input in mini-buffer, message to each area overide the input prompt

[Juri Linkov]

> And why don’t check the old selected buffer in minibuffer-message?

Because some other code might activate the minibuffer and want
minibuffer-message to display message in the activated minibuffer.

bug#34614: 26.1.92; When reading input in mini-buffer, message to each area overide the input prompt

[Zhang Haijun]

> 在 2019年11月12日，下午4:10，martin rudalics <rudalics@gmx.at> 写道：
> 
> > Thanks. I think it will be better if emacs can record the last
> > buffer(Including minibuffer) selected manually by the user
> 
> That will be next to impossible.
> 
> > and provide
> > a function like selected-buffer to return this buffer.
> > And minibuffer-message can use this.
> >
> > old-selected-window does exactly the same - it records the last window,
> > and getting its buffer is easy with just window-buffer.
> >
> > Doesn’t set-buffer and with-current-buffer change the current buffer in the window?
> 
> No.  Only set_window_buffer does that.
> 
> > They are not selected manually by user.
> 
> How would you know?
> 
> martin
> 

Then is it possible to provide a function which returns whether the current context is in the foreground thread or in a background thread(a timer callback or a background thread)?

If the former, it can use the minibuffer freely.

If the latter, it can't. If it outputs messages, the minibuffer should be protected. If it reads user input, it should be queued and blocked.

I think it is not safe to call y-or-n-p in a timer callback, because user may be editing a file and typing 'y'. So the above checking should be done in low level function like y-or-n-p.

bug#34614: 26.1.92; When reading input in mini-buffer, message to each area overide the input prompt

[Zhang Haijun]

> 在 2019年11月13日，上午4:53，Juri Linkov <juri@linkov.net> 写道：
> 
>> And why don’t check the old selected buffer in minibuffer-message?
> 
> Because some other code might activate the minibuffer and want
> minibuffer-message to display message in the activated minibuffer.

Then it can just call message.