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

[Boruch Baum]

On 2021-05-19 14:29, Eli Zaretskii wrote:
> > Date: Wed, 19 May 2021 00:00:53 -0400
> > From: Boruch Baum <boruch_baum@gmx.com>
> > Cc: martin rudalics <rudalics@gmx.at>, 48408@debbugs.gnu.org
>
> > 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.

Without that feature, the emacs 'server' functionality could be  useful
for >1 physical 'seats' (in X11/Xorg terms) or >1 separate IP addresses
by >1 individuals. There had been attempts in the past at some FOSS
version of 'collaborative editing' (eg. gobby), and I thought emacs had
that covered with its server/client option.

I'm looking at the emacswiki now ... and as so often the case it seems
very out-of-date.

I don't personally have any immediate or foreseeable need for
collaborative editing, but is there a 'recommended' method?

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