unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
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.





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