bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#48408: BUGFIX: window-default-font-height: check for nil string


From: Eli Zaretskii
Subject: bug#48408: BUGFIX: window-default-font-height: check for nil string
Date: Sun, 16 May 2021 09:32:34 +0300

> Date: Sun, 16 May 2021 02:05:12 -0400
> From: Boruch Baum <boruch_baum@gmx.com>
> Cc: 48408@debbugs.gnu.org
> 
> I have several frames: at least one is definitely a gui frame (ie. it
> appears in its own gui 'window' after being created via a gui menu which
> seems to have accessed a gui emacsclient.desktop file), and at least one
> is definitely a tty frame (ie. my original 'emacs -nw' invocation, from
> within tmux).
> 
> In performing the final test again:
> 
> > > >   (frames-on-display-list ":0.0")
> 
> on tty frame: (#<frame F153 0x5599a3a9d710>)
> on gui frame: (#<frame F153 0x5599a3a9d710>)
> 
> So the output remains the same, but what you didn't ask me to report was
> the mode line output, which differs:
> 
> on tty frame: -UUU:@**--F139  *Ibuffer*
> on gui frame: -UUU:@**--      *Scratch*
> 
> Yes, the mode line displays a frame ID different than the
> frames-on-display-list output.
> 
> Frame 153 does exist: It is the frame created by my email client (mutt)
> to compose this email message). So, it would be the most recent tty
> frame created, although the GUI frame was created after.

Quite a mess, huh.

> Can you reproduce this?

No, I don't have access to a system where I can create this situation,
sorry.

But I sent a potential fix a few moments ago.





reply via email to

[Prev in Thread] Current Thread [Next in Thread]