How to debug a transient (message) bug

How to debug a transient (message) bug

[Dima Kogan]

Hi. I'm running a bleeding-edge build of emacs from git. Using X11 and
GTK.

Starting a month or two ago I'm observing a bug that's really annoying,
but I can't figure out how to reproduce it from an 'emacs -Q', or how to
debug it myself. Suggestions requested.

From any emacs buffer I interactively hit M-! (shell-command), and
interactively give it a command that will produce some output; for
instance "seq 5". The expected output is

===========
1
2
3
4
5
===========

This produces the expected output in the *Shell Command Output* buffer,
and also pops up at the bottom of the frame because
(display-message-or-buffer) is called, which calls (message).

Usually I see this correct behavior. However, in my long-running emacs
sessions I reliably do NOT see this behavior if I M-! from a buffer
visiting a remote file via TRAMP. In this case, the output ends up in
*Shell Command Output* as it should and (message) is called as it
should. The (message) output does show up at the bottom of the frame,
but only instantaneously: as soon as it comes up, it goes away
immediately.

I cannot figure out why, and I don't know how to debug it. I'd like to
trace some sort of message-transient-buffer-go-away event, but I don't
know what that is. This is 100% reproducible and 100% annoying, so I'd
like to fix it. Any debugging suggestions?

Thanks

Re: How to debug a transient (message) bug

[Jens Schmidt]

On 2023-05-26  08:43, Dima Kogan wrote:
 > I cannot figure out why, and I don't know how to debug it. I'd like to
 > trace some sort of message-transient-buffer-go-away event, but I don't
 > know what that is. This is 100% reproducible and 100% annoying, so I'd
 > like to fix it. Any debugging suggestions?

Messages go away when other messages are written - probably tramp 
interferes with the results you expect by overwriting them with empty or 
temporary text.  So a rather cheap (but uncertain) approach would be to 
trace function `message' with M-x trace-function message RET.

In buffer *trace-output* you should see the call for the message written 
by M-! and (probably) follow-up calls.

Switch off tracing with M-x untrace-all RET.

(Having said that I do not quite understand why the following example

(defun message-test ()
   (interactive)
   (message "bar")
   (with-temp-message
       (message "foo")))

in emacs/master -Q leaves "foo" in the message area and not "bar", but 
I'm kind of too lazy to follow up on that.)

HTH

Re: How to debug a transient (message) bug

[Jens Schmidt]

On 2023-05-26  21:05, Jens Schmidt wrote:
> (Having said that I do not quite understand why the following example
> 
> [...]
> 
> in emacs/master -Q leaves "foo" in the message area and not "bar", but 
> I'm kind of too lazy to follow up on that.)

Because I did not read documentation properly, that's why ... so ignore 
the second part of the previous post, please.

Re: How to debug a transient (message) bug

[Dima Kogan]

Jens Schmidt <jschmidt4gnu@vodafonemail.de> writes:

> On 2023-05-26  08:43, Dima Kogan wrote:
>> I cannot figure out why, and I don't know how to debug it. I'd like to
>> trace some sort of message-transient-buffer-go-away event, but I don't
>> know what that is. This is 100% reproducible and 100% annoying, so I'd
>> like to fix it. Any debugging suggestions?
>
> Messages go away when other messages are written - probably tramp interferes
> with the results you expect by overwriting them with empty or temporary text.

Thank you so much for the suggestion! I didn't think of it, and it was
the right guess. There is indeed another (message) call that overwrites
the first. And now that I know this I can see another thing I didn't
think of: simply looking at the *Messages* buffer would show the second
message.

Thanks much