From: Eli Zaretskii <eliz@gnu.org>
To: Daniel Clemente <n142857@gmail.com>
Cc: eggert@cs.ucla.edu, 71343@debbugs.gnu.org
Subject: bug#71343: 30.0.50; TTY frame doesn't automatically redisplay itself after having closed another frame
Date: Sun, 16 Jun 2024 09:33:06 +0300 [thread overview]
Message-ID: <86o781s8gt.fsf@gnu.org> (raw)
In-Reply-To: <CAJKAhPBxPjvJumS5u33vf9QxZP2o9kzpw0Refpvy27O5gCGfOA@mail.gmail.com> (message from Daniel Clemente on Sun, 16 Jun 2024 05:40:12 +0000)
> From: Daniel Clemente <n142857@gmail.com>
> Date: Sun, 16 Jun 2024 05:40:12 +0000
> Cc: eggert@cs.ucla.edu, 71343@debbugs.gnu.org
>
> I have a new discovery (it's about „initial frame“), you can skip to
> the gdb info below (line 16876).
It's a problematic discovery from where I stand...
> > > Random ideas, without knowing much about terminals.
> > > - Can't an X terminal detect „I've been given X focus“ and pass this
> > > signal to the program running inside it?
> >
> > You assume that it will be a terminal belonging to Emacs that will get
> > focus? That is not given.
>
> I was thinking that maybe X always does this (X notifies the terminal
> emulator, which notifies the program running inside it, whatever
> program it is).
Emacs doesn't really talk to the terminal emulator, unless the
emulator supports known protocols of doing so. You will see in
lisp/term/xterm.el that Emacs supports that for xterm that is new
enough. Don't know what happens with urxvt, but did you try using
xterm and saw the same problems?
> > > - What if, when resizing the frame (something which Emacs detects),
> > > Emacs knows/detects that a frame was closed, and decides not to delay
> > > the redisplay?
> >
> > Redisplay of which frame? Emacs only redisplays a frame if some
> > change in buffer text justifies that.
>
> I propose it should repaint/redisplay the frame whose size changed.
When a frame is resized, it is redisplayed, yes. But that requires
Emacs to know that it is resized.
> Don't we know which frame is the one being resized? It should be f in
> adjust_frame_size. It realizes that e.g. it's being resized from 72 to
> 61 columns.
I need a backtrace showing the call to adjust_frame_size, of a frame
that is not redrawn. I don't think I saw such a backtrace.
> In normal conditions, resizing a frame calls: adjust_frame size, then
> redisplay_internal, then clear_garbaged_frames, then redraw_frame
>
> But when I reproduce this bug (i.e. just after closing a frame),
> resizing a frame calls: adjust_frame_size, then redisplay_internal. It
> doesn't call the other two.
> (Only later when I press a key, it calls redisplay_internal, then
> clear_garbaged_frames, then redraw_frame)
> In this scenario, why doesn't redisplay_internal reach the point where
> it calls clear_garbaged_frames?
> Because this happens:
> Breakpoint 5, redisplay_internal () at xdisp.c:16831
> 16831 struct window *w = XWINDOW (selected_window);
> (gdb) n
> 16835 bool must_finish = false, match_p;
> (gdb)
> 16839 bool polling_stopped_here = false;
> (gdb)
> 16846 int hscroll_retries = 0;
> (gdb)
> 16854 int garbaged_frame_retries = 0;
> (gdb)
> 16862 bool update_miniwindow_p = false;
> (gdb)
> 16864 redisplay_trace ("redisplay_internal %d\n", redisplaying_p);
> (gdb)
> 16870 if (redisplaying_p)
> (gdb)
> 16876 if ((FRAME_INITIAL_P (SELECTED_FRAME ())
> (gdb)
> 16877 && redisplay_skip_initial_frame)
> (gdb)
> 16879 return;
> (gdb)
>
>
> So, apparently it thinks that my frame is initial.
And for a good reason:
> Some more data about the looks-initial frame:
>
> (gdb) p *SELECTED_FRAME()
> $102 = {
> header = {
> size = 4611686018595348501
> },
[...]
> output_data = {
> tty = 0x0,
> x = 0x0,
> w32 = 0x0,
> ns = 0x0,
> pgtk = 0x0,
> haiku = 0x0,
> android = 0x0
> },
This zero value exactly means this frame is "initial" it has not yet
been set up as a terminal frame. That setup happens inside
make-terminal-frame, here:
f = make_terminal_frame (t);
and make_terminal_frame does
f->output_method = output_termcap;
Somehow this frame escaped this code, so all kinds of weird things can
happen with it.
> By the way, C-x # isn't enough to close any Emacs frame. If I have
> opened it by running urxvtcd -e 'emacsclient' '-nw', then later C-x
> # doesn't close it, it just says „No server buffers remain to edit“.
> But C-x C-c does close it.
Use "C-x 5 0" to delete the current frame.
next prev parent reply other threads:[~2024-06-16 6:33 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-06-03 15:33 bug#71343: 30.0.50; TTY frame doesn't automatically redisplay itself after having closed another frame Daniel Clemente
2024-06-03 16:31 ` Eli Zaretskii
2024-06-06 13:22 ` Daniel Clemente
2024-06-06 11:54 ` Eli Zaretskii
2024-06-06 13:24 ` Daniel Clemente
2024-06-06 13:44 ` Eli Zaretskii
2024-06-16 5:40 ` Daniel Clemente
2024-06-16 6:33 ` Eli Zaretskii [this message]
2024-06-21 10:47 ` Daniel Clemente
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=86o781s8gt.fsf@gnu.org \
--to=eliz@gnu.org \
--cc=71343@debbugs.gnu.org \
--cc=eggert@cs.ucla.edu \
--cc=n142857@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).