GNU bug report logs -
#48408
BUGFIX: window-default-font-height: check for nil string
Previous Next
Reported by: Boruch Baum <boruch_baum <at> gmx.com>
Date: Fri, 14 May 2021 01:16:02 UTC
Severity: normal
Done: Lars Ingebrigtsen <larsi <at> gnus.org>
Bug is archived. No further changes may be made.
Full log
Message #80 received at 48408 <at> debbugs.gnu.org (full text, mbox):
> Date: Wed, 19 May 2021 00:00:53 -0400
> From: Boruch Baum <boruch_baum <at> gmx.com>
> Cc: martin rudalics <rudalics <at> gmx.at>, 48408 <at> debbugs.gnu.org
>
> 1) In working on this bug, I noticed that the mode line on the GUI frame
> was not correctly indicating the frame name. Should I file that as a
> separate bug? Add it to some other current outstanding bug? Let it
> stand as part of this report?
GUI frame or TTY frame? GUI frames by default don't have names, you
need to give them a name if you want.
If all I said above doesn't help, then yes, please report a bug with
all the details.
> 2) Likewise, for more than two years I've intermittently been having a
> 'grave' emacs bug that I never reported on this list because I
> couldn't ever figure out how to reproduce it. In working on this bug,
> I seem to have figured out the problem (but not a solution):
>
> 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.
>
> 2.2) This most commonly seems to have been happening to me when
> composing an email message using mutt, which I have configured
> to use emacsclient as its editor.
>
> 2.3) Up until now, my work-around has been to `pkill emacsclient` and
> restart the client (this doesn't cause any data loss, since all
> data is on the server).
It's a "feature": Emacs can read input only from one frame at a time.
This bug report was last modified 3 years and 27 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.