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

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

bug#27210: 25.2; Recovering loaddefs.el with desktop-mode hangs when lin


From: Eli Zaretskii
Subject: bug#27210: 25.2; Recovering loaddefs.el with desktop-mode hangs when linum is on
Date: Sun, 04 Jun 2017 17:15:14 +0300

> From: npostavs@users.sourceforge.net
> Cc: 27210@debbugs.gnu.org,  ambrevar@gmail.com
> Date: Sat, 03 Jun 2017 19:07:31 -0400
> 
> > Because the hidden "F1" frame clearly isn't actually visible (and we
> > don't need to show line numbers on it).  But that just triggers
> > Bug#26912 "desktop-clear with emacs as daemon results in error on C-x 5
> > 0" even without desktop-clear, so it's not an acceptable solution by
> > itself at least.
> 
> I've expanded on this approach, it seems to work, though it's possible
> I'm overlooking some other place that assumes the initial frame is
> visible.
> 
> >From 129862e0621bf16e20ecc433e427b66626ba9bb8 Mon Sep 17 00:00:00 2001
> From: Noam Postavsky <npostavs@gmail.com>
> Date: Sat, 3 Jun 2017 17:59:17 -0400
> Subject: [PATCH v1] Make the initial frame invisible when in daemon mode
>  (Bug#27210)
> 
> * src/emacs.c (main): When starting as a daemon, add `daemonp'
> parameter to the initial frame.
> * src/frame.c (make_initial_frame): Set the initial frame as
> nonvisible when running in daemon mode.
> (other_frames): Return true if one of the other frames has a non-nil
> `daemonp' frame parameter.
> (delete_frame): Don't allow deleting a frame with a `daemonp'
> parameter.

I'm bothered by the possible unintended consequences of this, as we
are only starting to collect experience with the daemon, desktop
restoring, the various globalized modes, and the initial frame.  This
bug report is AFAIR the only one where that combination causes some
issues.  If similar cases will at some point start piling up, then I'd
agree we might need a common solution for them, but until then... it
sounds overkill to decide that the initial daemon frame be marked as
invisible, for the sake of this single use case.  And don't forget
that the initial frame is invisible in non-daemon sessions as well,
until some point during startup.

There are more than 70 references to FRAME_VISIBLE_P in the C sources,
and another 2 dozen references to frame-visible-p in Lisp sources --
sounds to me like a lot of potential for breaking stuff.

My alternative proposal is much simpler, is localized to linum.el, and
in a nutshell tests exactly the same condition, since any frame in a
daemon session that can be visible is by definition a client frame.
Do you see any disadvantages with installing that instead?

Thanks.





reply via email to

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