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

Previous Next

Package: emacs;

Reported by: Zhang Haijun <ccsmile2008 <at> outlook.com>

Date: Fri, 22 Feb 2019 12:19:01 UTC

Severity: normal

Tags: fixed

Found in version 26.1.92

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 34614 in the body.
You can then email your comments to 34614 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

View this report as an mbox folder, status mbox, maintainer mbox


Report forwarded to bug-gnu-emacs <at> gnu.org:
bug#34614; Package emacs. (Fri, 22 Feb 2019 12:19:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Zhang Haijun <ccsmile2008 <at> outlook.com>:
New bug report received and forwarded. Copy sent to bug-gnu-emacs <at> gnu.org. (Fri, 22 Feb 2019 12:19:03 GMT) Full text and rfc822 format available.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Zhang Haijun <ccsmile2008 <at> outlook.com>
To: "bug-gnu-emacs <at> gnu.org" <bug-gnu-emacs <at> gnu.org>
Subject: 26.1.92; When reading input in mini-buffer, message to each area
 overide the input prompt
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.


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))


Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#34614; Package emacs. (Fri, 22 Feb 2019 13:21:02 GMT) Full text and rfc822 format available.

Message #8 received at 34614 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Zhang Haijun <ccsmile2008 <at> outlook.com>
Cc: 34614 <at> debbugs.gnu.org
Subject: Re: bug#34614: 26.1.92;
 When reading input in mini-buffer, message to each area overide the
 input prompt
Date: Fri, 22 Feb 2019 15:20:39 +0200
> From: Zhang Haijun <ccsmile2008 <at> 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?




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#34614; Package emacs. (Fri, 22 Feb 2019 13:37:01 GMT) Full text and rfc822 format available.

Message #11 received at 34614 <at> debbugs.gnu.org (full text, mbox):

From: Zhang Haijun <ccsmile2008 <at> outlook.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: "34614 <at> debbugs.gnu.org" <34614 <at> debbugs.gnu.org>
Subject: Re: bug#34614: 26.1.92; When reading input in mini-buffer, message to
 each area overide the input prompt
Date: Fri, 22 Feb 2019 13:35:59 +0000

> 在 2019年2月22日,下午9:20,Eli Zaretskii <eliz <at> 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.



Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#34614; Package emacs. (Fri, 22 Feb 2019 15:08:01 GMT) Full text and rfc822 format available.

Message #14 received at 34614 <at> debbugs.gnu.org (full text, mbox):

From: martin rudalics <rudalics <at> gmx.at>
To: Zhang Haijun <ccsmile2008 <at> outlook.com>, 34614 <at> debbugs.gnu.org
Subject: Re: bug#34614: 26.1.92; When reading input in mini-buffer, message
 to each area overide the input prompt
Date: Fri, 22 Feb 2019 16:07:33 +0100
> 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





Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#34614; Package emacs. (Fri, 22 Feb 2019 15:41:02 GMT) Full text and rfc822 format available.

Message #17 received at 34614 <at> debbugs.gnu.org (full text, mbox):

From: Zhang Haijun <ccsmile2008 <at> outlook.com>
To: martin rudalics <rudalics <at> gmx.at>
Cc: "34614 <at> debbugs.gnu.org" <34614 <at> debbugs.gnu.org>
Subject: Re: bug#34614: 26.1.92; When reading input in mini-buffer, message to
 each area overide the input prompt
Date: Fri, 22 Feb 2019 15:40:34 +0000

> 在 2019年2月22日,下午11:07,martin rudalics <rudalics <at> 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.


Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#34614; Package emacs. (Fri, 22 Feb 2019 21:39:01 GMT) Full text and rfc822 format available.

Message #20 received at 34614 <at> debbugs.gnu.org (full text, mbox):

From: martin rudalics <rudalics <at> gmx.at>
To: 34614 <at> debbugs.gnu.org
Subject: Re: bug#34614: 26.1.92; When reading input in mini-buffer, message
 to each area overide the input prompt
Date: Fri, 22 Feb 2019 22:38:05 +0100
> 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






Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#34614; Package emacs. (Sat, 23 Feb 2019 02:03:02 GMT) Full text and rfc822 format available.

Message #23 received at 34614 <at> debbugs.gnu.org (full text, mbox):

From: Zhang Haijun <ccsmile2008 <at> outlook.com>
To: martin rudalics <rudalics <at> gmx.at>
Cc: "34614 <at> debbugs.gnu.org" <34614 <at> debbugs.gnu.org>
Subject: Re: bug#34614: 26.1.92; When reading input in mini-buffer, message to
 each area overide the input prompt
Date: Sat, 23 Feb 2019 02:01:52 +0000

> 在 2019年2月23日,上午2:47,martin rudalics <rudalics <at> 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?



Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#34614; Package emacs. (Sat, 23 Feb 2019 02:34:02 GMT) Full text and rfc822 format available.

Message #26 received at 34614 <at> debbugs.gnu.org (full text, mbox):

From: Zhang Haijun <ccsmile2008 <at> outlook.com>
To: martin rudalics <rudalics <at> gmx.at>
Cc: "34614 <at> debbugs.gnu.org" <34614 <at> debbugs.gnu.org>
Subject: Re: bug#34614: 26.1.92; When reading input in mini-buffer, message to
 each area overide the input prompt
Date: Sat, 23 Feb 2019 02:33:23 +0000

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

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


Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#34614; Package emacs. (Sat, 23 Feb 2019 07:27:01 GMT) Full text and rfc822 format available.

Message #29 received at 34614 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: martin rudalics <rudalics <at> gmx.at>
Cc: 34614 <at> debbugs.gnu.org
Subject: Re: bug#34614: 26.1.92;
 When reading input in mini-buffer, message to each area overide the
 input prompt
Date: Sat, 23 Feb 2019 09:26:26 +0200
> Date: Fri, 22 Feb 2019 22:38:05 +0100
> From: martin rudalics <rudalics <at> 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?




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#34614; Package emacs. (Sat, 23 Feb 2019 07:55:01 GMT) Full text and rfc822 format available.

Message #32 received at 34614 <at> debbugs.gnu.org (full text, mbox):

From: martin rudalics <rudalics <at> gmx.at>
To: Zhang Haijun <ccsmile2008 <at> outlook.com>
Cc: "34614 <at> debbugs.gnu.org" <34614 <at> debbugs.gnu.org>
Subject: Re: bug#34614: 26.1.92; When reading input in mini-buffer, message
 to each area overide the input prompt
Date: Sat, 23 Feb 2019 08:53:42 +0100
>> 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




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#34614; Package emacs. (Sat, 23 Feb 2019 07:55:02 GMT) Full text and rfc822 format available.

Message #35 received at 34614 <at> debbugs.gnu.org (full text, mbox):

From: martin rudalics <rudalics <at> gmx.at>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 34614 <at> debbugs.gnu.org
Subject: Re: bug#34614: 26.1.92; When reading input in mini-buffer, message
 to each area overide the input prompt
Date: Sat, 23 Feb 2019 08:54:13 +0100
> 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




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#34614; Package emacs. (Sat, 23 Feb 2019 08:03:01 GMT) Full text and rfc822 format available.

Message #38 received at 34614 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Zhang Haijun <ccsmile2008 <at> outlook.com>
Cc: rudalics <at> gmx.at, 34614 <at> debbugs.gnu.org
Subject: Re: bug#34614: 26.1.92;
 When reading input in mini-buffer, message to each area overide the
 input prompt
Date: Sat, 23 Feb 2019 10:01:52 +0200
> From: Zhang Haijun <ccsmile2008 <at> outlook.com>
> Date: Sat, 23 Feb 2019 02:33:23 +0000
> Cc: "34614 <at> debbugs.gnu.org" <34614 <at> 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.




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#34614; Package emacs. (Sat, 23 Feb 2019 08:06:01 GMT) Full text and rfc822 format available.

Message #41 received at 34614 <at> debbugs.gnu.org (full text, mbox):

From: Zhang Haijun <ccsmile2008 <at> outlook.com>
To: martin rudalics <rudalics <at> gmx.at>
Cc: "34614 <at> debbugs.gnu.org" <34614 <at> debbugs.gnu.org>
Subject: Re: bug#34614: 26.1.92; When reading input in mini-buffer, message to
 each area overide the input prompt
Date: Sat, 23 Feb 2019 08:05:28 +0000
> 在 2019年2月23日,下午3:53,martin rudalics <rudalics <at> 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?



Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#34614; Package emacs. (Sat, 23 Feb 2019 08:26:02 GMT) Full text and rfc822 format available.

Message #44 received at 34614 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: martin rudalics <rudalics <at> gmx.at>
Cc: 34614 <at> debbugs.gnu.org
Subject: Re: bug#34614: 26.1.92; When reading input in mini-buffer, message
 to each area overide the input prompt
Date: Sat, 23 Feb 2019 10:25:26 +0200
> Date: Sat, 23 Feb 2019 08:54:13 +0100
> From: martin rudalics <rudalics <at> gmx.at>
> CC: 34614 <at> 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?




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#34614; Package emacs. (Sat, 23 Feb 2019 08:30:03 GMT) Full text and rfc822 format available.

Message #47 received at 34614 <at> debbugs.gnu.org (full text, mbox):

From: Zhang Haijun <ccsmile2008 <at> outlook.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: "rudalics <at> gmx.at" <rudalics <at> gmx.at>,
 "34614 <at> debbugs.gnu.org" <34614 <at> debbugs.gnu.org>
Subject: Re: bug#34614: 26.1.92; When reading input in mini-buffer, message to
 each area overide the input prompt
Date: Sat, 23 Feb 2019 08:29:34 +0000
> 在 2019年2月23日,下午4:01,Eli Zaretskii <eliz <at> gnu.org> 写道:
> 
>> From: Zhang Haijun <ccsmile2008 <at> outlook.com>
>> Date: Sat, 23 Feb 2019 02:33:23 +0000
>> Cc: "34614 <at> debbugs.gnu.org" <34614 <at> 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.


Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#34614; Package emacs. (Sat, 23 Feb 2019 08:30:04 GMT) Full text and rfc822 format available.

Message #50 received at 34614 <at> debbugs.gnu.org (full text, mbox):

From: martin rudalics <rudalics <at> gmx.at>
To: Zhang Haijun <ccsmile2008 <at> outlook.com>
Cc: "34614 <at> debbugs.gnu.org" <34614 <at> debbugs.gnu.org>
Subject: Re: bug#34614: 26.1.92; When reading input in mini-buffer, message
 to each area overide the input prompt
Date: Sat, 23 Feb 2019 09:29:45 +0100
> 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





Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#34614; Package emacs. (Sat, 23 Feb 2019 08:30:05 GMT) Full text and rfc822 format available.

Message #53 received at 34614 <at> debbugs.gnu.org (full text, mbox):

From: martin rudalics <rudalics <at> gmx.at>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 34614 <at> debbugs.gnu.org
Subject: Re: bug#34614: 26.1.92; When reading input in mini-buffer, message
 to each area overide the input prompt
Date: Sat, 23 Feb 2019 09:29:52 +0100
> 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




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#34614; Package emacs. (Sat, 23 Feb 2019 09:32:02 GMT) Full text and rfc822 format available.

Message #56 received at 34614 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: martin rudalics <rudalics <at> gmx.at>
Cc: 34614 <at> debbugs.gnu.org
Subject: Re: bug#34614: 26.1.92; When reading input in mini-buffer, message
 to each area overide the input prompt
Date: Sat, 23 Feb 2019 11:31:48 +0200
> Date: Sat, 23 Feb 2019 09:29:52 +0100
> From: martin rudalics <rudalics <at> gmx.at>
> CC: 34614 <at> 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.




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#34614; Package emacs. (Sat, 23 Feb 2019 09:58:02 GMT) Full text and rfc822 format available.

Message #59 received at 34614 <at> debbugs.gnu.org (full text, mbox):

From: martin rudalics <rudalics <at> gmx.at>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 34614 <at> debbugs.gnu.org
Subject: Re: bug#34614: 26.1.92; When reading input in mini-buffer, message
 to each area overide the input prompt
Date: Sat, 23 Feb 2019 10:57:36 +0100
> 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




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#34614; Package emacs. (Sat, 23 Feb 2019 10:36:01 GMT) Full text and rfc822 format available.

Message #62 received at 34614 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: martin rudalics <rudalics <at> gmx.at>
Cc: 34614 <at> debbugs.gnu.org
Subject: Re: bug#34614: 26.1.92; When reading input in mini-buffer, message
 to each area overide the input prompt
Date: Sat, 23 Feb 2019 12:35:32 +0200
> Date: Sat, 23 Feb 2019 10:57:36 +0100
> From: martin rudalics <rudalics <at> gmx.at>
> CC: 34614 <at> 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.




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#34614; Package emacs. (Sat, 23 Feb 2019 14:03:02 GMT) Full text and rfc822 format available.

Message #65 received at 34614 <at> debbugs.gnu.org (full text, mbox):

From: martin rudalics <rudalics <at> gmx.at>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 34614 <at> debbugs.gnu.org
Subject: Re: bug#34614: 26.1.92; When reading input in mini-buffer, message
 to each area overide the input prompt
Date: Sat, 23 Feb 2019 15:02:26 +0100
> 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




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#34614; Package emacs. (Sat, 23 Feb 2019 16:52:01 GMT) Full text and rfc822 format available.

Message #68 received at 34614 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: martin rudalics <rudalics <at> gmx.at>
Cc: 34614 <at> debbugs.gnu.org
Subject: Re: bug#34614: 26.1.92; When reading input in mini-buffer, message
 to each area overide the input prompt
Date: Sat, 23 Feb 2019 18:51:07 +0200
> Date: Sat, 23 Feb 2019 15:02:26 +0100
> From: martin rudalics <rudalics <at> gmx.at>
> CC: 34614 <at> 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?




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#34614; Package emacs. (Sun, 24 Feb 2019 08:45:03 GMT) Full text and rfc822 format available.

Message #71 received at 34614 <at> debbugs.gnu.org (full text, mbox):

From: martin rudalics <rudalics <at> gmx.at>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 34614 <at> debbugs.gnu.org
Subject: Re: bug#34614: 26.1.92; When reading input in mini-buffer, message
 to each area overide the input prompt
Date: Sun, 24 Feb 2019 09:44:10 +0100
>> 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




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#34614; Package emacs. (Sun, 24 Feb 2019 16:12:01 GMT) Full text and rfc822 format available.

Message #74 received at 34614 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: martin rudalics <rudalics <at> gmx.at>
Cc: 34614 <at> debbugs.gnu.org
Subject: Re: bug#34614: 26.1.92; When reading input in mini-buffer, message
 to each area overide the input prompt
Date: Sun, 24 Feb 2019 18:11:45 +0200
> Date: Sun, 24 Feb 2019 09:44:10 +0100
> From: martin rudalics <rudalics <at> gmx.at>
> CC: 34614 <at> 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.




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#34614; Package emacs. (Sun, 24 Feb 2019 18:32:02 GMT) Full text and rfc822 format available.

Message #77 received at 34614 <at> debbugs.gnu.org (full text, mbox):

From: martin rudalics <rudalics <at> gmx.at>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 34614 <at> debbugs.gnu.org
Subject: Re: bug#34614: 26.1.92; When reading input in mini-buffer, message
 to each area overide the input prompt
Date: Sun, 24 Feb 2019 19:31:10 +0100
> 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




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#34614; Package emacs. (Sun, 24 Feb 2019 19:04:02 GMT) Full text and rfc822 format available.

Message #80 received at 34614 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: martin rudalics <rudalics <at> gmx.at>
Cc: 34614 <at> debbugs.gnu.org
Subject: Re: bug#34614: 26.1.92; When reading input in mini-buffer, message
 to each area overide the input prompt
Date: Sun, 24 Feb 2019 21:02:44 +0200
> Date: Sun, 24 Feb 2019 19:31:10 +0100
> From: martin rudalics <rudalics <at> gmx.at>
> CC: 34614 <at> 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.




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#34614; Package emacs. (Mon, 25 Feb 2019 10:12:01 GMT) Full text and rfc822 format available.

Message #83 received at 34614 <at> debbugs.gnu.org (full text, mbox):

From: martin rudalics <rudalics <at> gmx.at>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 34614 <at> debbugs.gnu.org
Subject: Re: bug#34614: 26.1.92; When reading input in mini-buffer, message
 to each area overide the input prompt
Date: Mon, 25 Feb 2019 11:11:33 +0100
> 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




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#34614; Package emacs. (Wed, 06 Nov 2019 22:32:03 GMT) Full text and rfc822 format available.

Message #86 received at 34614 <at> debbugs.gnu.org (full text, mbox):

From: Juri Linkov <juri <at> linkov.net>
To: Zhang Haijun <ccsmile2008 <at> outlook.com>
Cc: martin rudalics <rudalics <at> gmx.at>,
 "34614 <at> debbugs.gnu.org" <34614 <at> debbugs.gnu.org>
Subject: Re: bug#34614: 26.1.92; When reading input in mini-buffer, message
 to each area overide the input prompt
Date: Thu, 07 Nov 2019 00:02:48 +0200
> 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.




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#34614; Package emacs. (Thu, 07 Nov 2019 14:53:01 GMT) Full text and rfc822 format available.

Message #89 received at 34614 <at> debbugs.gnu.org (full text, mbox):

From: HaiJun Zhang <netjune <at> outlook.com>
To: Zhang Haijun <ccsmile2008 <at> outlook.com>, Juri Linkov <juri <at> linkov.net>
Cc: "34614 <at> debbugs.gnu.org" <34614 <at> debbugs.gnu.org>
Subject: Re: bug#34614: 26.1.92; When reading input in mini-buffer, message to
 each area overide the input prompt
Date: Thu, 7 Nov 2019 14:52:24 +0000
[Message part 1 (text/plain, inline)]
在 2019年11月7日 +0800 AM6:33,Juri Linkov <juri <at> 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.

[Message part 2 (text/html, inline)]

Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#34614; Package emacs. (Thu, 07 Nov 2019 22:59:04 GMT) Full text and rfc822 format available.

Message #92 received at 34614 <at> debbugs.gnu.org (full text, mbox):

From: Juri Linkov <juri <at> linkov.net>
To: HaiJun Zhang <netjune <at> outlook.com>
Cc: "34614 <at> debbugs.gnu.org" <34614 <at> debbugs.gnu.org>,
 Zhang Haijun <ccsmile2008 <at> outlook.com>
Subject: Re: bug#34614: 26.1.92; When reading input in mini-buffer, message
 to each area overide the input prompt
Date: Fri, 08 Nov 2019 00:12:44 +0200
> 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.




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#34614; Package emacs. (Fri, 08 Nov 2019 01:47:02 GMT) Full text and rfc822 format available.

Message #95 received at 34614 <at> debbugs.gnu.org (full text, mbox):

From: HaiJun Zhang <netjune <at> outlook.com>
To: Juri Linkov <juri <at> linkov.net>
Cc: "34614 <at> debbugs.gnu.org" <34614 <at> debbugs.gnu.org>,
 Zhang Haijun <ccsmile2008 <at> outlook.com>
Subject: Re: bug#34614: 26.1.92; When reading input in mini-buffer, message to
 each area overide the input prompt
Date: Fri, 8 Nov 2019 01:46:45 +0000
[Message part 1 (text/plain, inline)]
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 <at> 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.
[Message part 2 (text/html, inline)]

Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#34614; Package emacs. (Sat, 09 Nov 2019 23:08:03 GMT) Full text and rfc822 format available.

Message #98 received at 34614 <at> debbugs.gnu.org (full text, mbox):

From: Juri Linkov <juri <at> linkov.net>
To: HaiJun Zhang <netjune <at> outlook.com>
Cc: "34614 <at> debbugs.gnu.org" <34614 <at> debbugs.gnu.org>,
 Zhang Haijun <ccsmile2008 <at> outlook.com>
Subject: Re: bug#34614: 26.1.92; When reading input in mini-buffer, message
 to each area overide the input prompt
Date: Sun, 10 Nov 2019 01:05:08 +0200
> 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 <at> 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.





Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#34614; Package emacs. (Sat, 09 Nov 2019 23:39:02 GMT) Full text and rfc822 format available.

Message #101 received at 34614 <at> debbugs.gnu.org (full text, mbox):

From: HaiJun Zhang <netjune <at> outlook.com>
To: Juri Linkov <juri <at> linkov.net>
Cc: "34614 <at> debbugs.gnu.org" <34614 <at> debbugs.gnu.org>,
 Zhang Haijun <ccsmile2008 <at> outlook.com>
Subject: Re: bug#34614: 26.1.92; When reading input in mini-buffer, message to
 each area overide the input prompt
Date: Sat, 9 Nov 2019 23:38:29 +0000
[Message part 1 (text/plain, inline)]
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 <at> 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 <at> 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.

[Message part 2 (text/html, inline)]

Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#34614; Package emacs. (Sun, 10 Nov 2019 21:24:02 GMT) Full text and rfc822 format available.

Message #104 received at 34614 <at> debbugs.gnu.org (full text, mbox):

From: Juri Linkov <juri <at> linkov.net>
To: HaiJun Zhang <netjune <at> outlook.com>
Cc: "34614 <at> debbugs.gnu.org" <34614 <at> debbugs.gnu.org>,
 Zhang Haijun <ccsmile2008 <at> outlook.com>
Subject: Re: bug#34614: 26.1.92; When reading input in mini-buffer, message
 to each area overide the input prompt
Date: Sun, 10 Nov 2019 23:22:11 +0200
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.




Added tag(s) fixed. Request was from Juri Linkov <juri <at> linkov.net> to control <at> debbugs.gnu.org. (Sun, 10 Nov 2019 21:24:02 GMT) Full text and rfc822 format available.

bug marked as fixed in version 27.0.50, send any further explanations to 34614 <at> debbugs.gnu.org and Zhang Haijun <ccsmile2008 <at> outlook.com> Request was from Juri Linkov <juri <at> linkov.net> to control <at> debbugs.gnu.org. (Sun, 10 Nov 2019 21:24:02 GMT) Full text and rfc822 format available.

Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#34614; Package emacs. (Tue, 12 Nov 2019 00:50:02 GMT) Full text and rfc822 format available.

Message #111 received at 34614 <at> debbugs.gnu.org (full text, mbox):

From: HaiJun Zhang <netjune <at> outlook.com>
To: Juri Linkov <juri <at> linkov.net>
Cc: "34614 <at> debbugs.gnu.org" <34614 <at> debbugs.gnu.org>,
 Zhang Haijun <ccsmile2008 <at> outlook.com>
Subject: Re: bug#34614: 26.1.92; When reading input in mini-buffer, message to
 each area overide the input prompt
Date: Tue, 12 Nov 2019 00:49:22 +0000
[Message part 1 (text/plain, inline)]
在 2019年11月11日 +0800 AM5:23,Juri Linkov <juri <at> 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.




[Message part 2 (text/html, inline)]

Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#34614; Package emacs. (Tue, 12 Nov 2019 01:16:05 GMT) Full text and rfc822 format available.

Message #114 received at 34614 <at> debbugs.gnu.org (full text, mbox):

From: HaiJun Zhang <netjune <at> outlook.com>
To: Juri Linkov <juri <at> linkov.net>
Cc: "34614 <at> debbugs.gnu.org" <34614 <at> debbugs.gnu.org>,
 Zhang Haijun <ccsmile2008 <at> outlook.com>
Subject: Re: bug#34614: 26.1.92; When reading input in mini-buffer, message to
 each area overide the input prompt
Date: Tue, 12 Nov 2019 01:15:44 +0000
[Message part 1 (text/plain, inline)]
And why don’t check the old selected buffer in minibuffer-message?
在 2019年11月11日 +0800 AM5:23,Juri Linkov <juri <at> 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.
[Message part 2 (text/html, inline)]

Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#34614; Package emacs. (Tue, 12 Nov 2019 08:17:02 GMT) Full text and rfc822 format available.

Message #117 received at 34614 <at> debbugs.gnu.org (full text, mbox):

From: martin rudalics <rudalics <at> gmx.at>
To: HaiJun Zhang <netjune <at> outlook.com>, Juri Linkov <juri <at> linkov.net>
Cc: "34614 <at> debbugs.gnu.org" <34614 <at> debbugs.gnu.org>,
 Zhang Haijun <ccsmile2008 <at> outlook.com>
Subject: Re: bug#34614: 26.1.92; When reading input in mini-buffer, message to
 each area overide the input prompt
Date: Tue, 12 Nov 2019 09:10:59 +0100
> 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





Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#34614; Package emacs. (Tue, 12 Nov 2019 21:11:05 GMT) Full text and rfc822 format available.

Message #120 received at 34614 <at> debbugs.gnu.org (full text, mbox):

From: Juri Linkov <juri <at> linkov.net>
To: HaiJun Zhang <netjune <at> outlook.com>
Cc: "34614 <at> debbugs.gnu.org" <34614 <at> debbugs.gnu.org>,
 Zhang Haijun <ccsmile2008 <at> outlook.com>
Subject: Re: bug#34614: 26.1.92; When reading input in mini-buffer, message
 to each area overide the input prompt
Date: Tue, 12 Nov 2019 22:53:22 +0200
> 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.




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#34614; Package emacs. (Thu, 14 Nov 2019 00:45:01 GMT) Full text and rfc822 format available.

Message #123 received at 34614 <at> debbugs.gnu.org (full text, mbox):

From: Zhang Haijun <ccsmile2008 <at> outlook.com>
To: martin rudalics <rudalics <at> gmx.at>
Cc: HaiJun Zhang <netjune <at> outlook.com>,
 "34614 <at> debbugs.gnu.org" <34614 <at> debbugs.gnu.org>, Juri Linkov <juri <at> linkov.net>
Subject: Re: bug#34614: 26.1.92; When reading input in mini-buffer, message to
 each area overide the input prompt
Date: Thu, 14 Nov 2019 00:44:35 +0000

> 在 2019年11月12日,下午4:10,martin rudalics <rudalics <at> 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.



Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#34614; Package emacs. (Thu, 14 Nov 2019 00:47:02 GMT) Full text and rfc822 format available.

Message #126 received at 34614 <at> debbugs.gnu.org (full text, mbox):

From: Zhang Haijun <ccsmile2008 <at> outlook.com>
To: Juri Linkov <juri <at> linkov.net>
Cc: HaiJun Zhang <netjune <at> outlook.com>,
 "34614 <at> debbugs.gnu.org" <34614 <at> debbugs.gnu.org>
Subject: Re: bug#34614: 26.1.92; When reading input in mini-buffer, message to
 each area overide the input prompt
Date: Thu, 14 Nov 2019 00:46:12 +0000

> 在 2019年11月13日,上午4:53,Juri Linkov <juri <at> 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.


bug archived. Request was from Debbugs Internal Request <help-debbugs <at> gnu.org> to internal_control <at> debbugs.gnu.org. (Thu, 12 Dec 2019 12:24:05 GMT) Full text and rfc822 format available.

This bug report was last modified 4 years and 108 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.