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

[Boruch Baum <boruch_baum@gmx.com>]

On 2021-05-16 11:30, Eli Zaretskii wrote:
> Which is a Good Thing, because I've changed my mind.  Please try the
> much simpler patch below.
> ...
> -    (if (and (display-multi-font-p (frame-parameter frame 'display))
> +    (if (and (not (eq (framep frame) t))
> +             (display-multi-font-p (frame-parameter frame 'display))

This patch does do the job; The bug does not happen with this patch.

Two other things, though:

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?

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


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