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

Previous Next

Full log

View this message in rfc822 format

From: Boruch Baum <boruch_baum <at> gmx.com>
To: martin rudalics <rudalics <at> gmx.at>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 48408 <at> debbugs.gnu.org
Subject: bug#48408: BUGFIX: window-default-font-height: check for nil string
Date: Wed, 19 May 2021 06:39:23 -0400

On 2021-05-19 09:45, martin rudalics wrote:
> > 1) In working on this bug, I noticed that the mode line on the GUI frame
> >     was not correctly indicating the frame name.
>
> What do you use to indicate the frame name in the mode line?

Nothing. It's however the default mode-line is configured. From the
describe-variable page for `mode-line-format':

("%e" mode-line-front-space mode-line-mule-info mode-line-client
mode-line-modified mode-line-remote mode-line-frame-identification
mode-line-buffer-identification " " mode-line-position
 (vc-mode vc-mode) " " mode-line-modes mode-line-misc-info
mode-line-end-spaces)

> If you have a title bar, does it correctly display the frame name?

Yes.

> Note also that "the" mode line is ambiguous - with split windows a
> frame usually has several mode lines.

Performing 'C-x 3' does present two mode lines, both of which fail to
identify the GUI frame. In both cases, the mode line(s) read(s):

   U:@**-   *scratch*   All of 0     (1,0)

>
> >     2.1) Whenever a minibuffer is active in one frame, the other windows
> >          on that frame are navigable and operable. However, all elements
> >          of all other frames are completely frozen.
>
> What happens when you type C-x 5 o or C-x 5 2 in the navigable frame?

Initially, I thought the system responded fine to either commands, but
then got a shock. I used a GUI frame for testing the navigable frame,
Pressed M-x, then C-x 5 2. A second GUI frame *was* created. However,
upon performing Alt-TAB to have the underlying operating system (window
manager, really) switch me to the tmux window in which I had prior emacs
-nw frames, all were frozen and remained in their frozen state until
exiting the minibuffer (The M-x on the GUI frame). What's more
surprising to me was that when I tried M-x C-x 5 0 (yes, I misread your
suggestion of 'o' as zero), the -nw frames also froze, even though the
GUI frame no longer existed! I wasn't expecting that at all. To top
things off, the -nw frames unfroze when re-launching a GUI frame (using
the operating system's xdg-desktop method). When the -nw frames
un-froze, they displayed the 'type-ahead' characters that I mashed while
the frames were frozen.

--
hkp://keys.gnupg.net
CA45 09B5 5351 7C11 A9D1  7286 0036 9E45 1595 8BC0

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.