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

classic Classic list List threaded Threaded
83 messages Options
12345
Reply | Threaded
Open this post in threaded view
|

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

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

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

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

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

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

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

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

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



Reply | Threaded
Open this post in threaded view
|

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

Lars Ingebrigtsen
Drew Adams <[hidden email]> writes:

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

It would be helpful to have a recipe.

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



Reply | Threaded
Open this post in threaded view
|

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

Drew Adams
> It would be helpful to have a recipe.

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

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

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



Reply | Threaded
Open this post in threaded view
|

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

Michael Heerdegen
Drew Adams <[hidden email]> writes:

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

I tried this here with emacs 25:

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

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

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


Michael.



Reply | Threaded
Open this post in threaded view
|

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

Lars Ingebrigtsen
In reply to this post by Drew Adams
Drew Adams <[hidden email]> writes:

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

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

Perhaps you could make a recipe in Emacs 24?

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



Reply | Threaded
Open this post in threaded view
|

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

Lars Ingebrigtsen
In reply to this post by Michael Heerdegen
Michael Heerdegen <[hidden email]> writes:

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

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

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



Reply | Threaded
Open this post in threaded view
|

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

Eli Zaretskii
In reply to this post by Drew Adams
> Date: Sat, 26 Dec 2015 09:19:21 -0800 (PST)
> From: Drew Adams <[hidden email]>
> Cc: [hidden email]
>
> recent Emacs 25 snapshots I have just crash all the time.

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

Thanks.



Reply | Threaded
Open this post in threaded view
|

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

Lars Ingebrigtsen
In reply to this post by Lars Ingebrigtsen
Lars Ingebrigtsen <[hidden email]> writes:

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

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

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

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

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



Reply | Threaded
Open this post in threaded view
|

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

Michael Heerdegen
Lars Ingebrigtsen <[hidden email]> writes:

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

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

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

Regards,

Michael.



Reply | Threaded
Open this post in threaded view
|

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

Lars Ingebrigtsen
Michael Heerdegen <[hidden email]> writes:

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

Yeah, that would feel quite natural, I think.

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



Reply | Threaded
Open this post in threaded view
|

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

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

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

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



Reply | Threaded
Open this post in threaded view
|

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

Juri Linkov-2
In reply to this post by Michael Heerdegen
>>   Seems like whenever `y-or-n-p' (or just `read-key') is waiting

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


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

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

Lars Ingebrigtsen
In reply to this post by Juri Linkov-2
Juri Linkov <[hidden email]> writes:

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

[...]

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

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

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



Reply | Threaded
Open this post in threaded view
|

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

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

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

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

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

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

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

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



Reply | Threaded
Open this post in threaded view
|

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

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

Now this is fixed.

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

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

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

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

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

Maybe a new bug report should be created for this?



Reply | Threaded
Open this post in threaded view
|

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

Juri Linkov-2
In reply to this post by Lars Ingebrigtsen
>> -    (message "%s" msg))
>> +                            (if (minibufferp)
>> +                                (minibuffer-message "%s" msg)
>> +                              (message "%s" msg)))
>
> Wouldn't it make more sense to just have `message' behave like
> `minibuffer-message' if '(minibufferp)'?  Otherwise all async code will
> have to have this code snippet.

I agree, this would make code more manageable.

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



Reply | Threaded
Open this post in threaded view
|

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

martin rudalics
In reply to this post by Juri Linkov-2
 > But this problem is not new.  The same can be reproduced
 > in older versions with
 >
 > (progn
 >    (man "XYZ")
 >    (read-string "-->"))
 >
 > This is because quit-restore-window moves point to wrong window.

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

martin



Reply | Threaded
Open this post in threaded view
|

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

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

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

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



Reply | Threaded
Open this post in threaded view
|

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

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

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

martin



Reply | Threaded
Open this post in threaded view
|

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

Lars Ingebrigtsen
In reply to this post by Juri Linkov-2
Juri Linkov <[hidden email]> writes:

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

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

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



12345