GNU bug report logs - #27210
25.2; Recovering loaddefs.el with desktop-mode hangs when linum is on

Previous Next

Full log

Message #39 received at 27210-done <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: npostavs <at> users.sourceforge.net
Cc: 27210-done <at> debbugs.gnu.org, ambrevar <at> gmail.com
Subject: Re: bug#27210: 25.2;
 Recovering loaddefs.el with desktop-mode hangs when linum is on
Date: Sun, 04 Jun 2017 19:31:34 +0300

> From: npostavs <at> users.sourceforge.net
> Cc: 27210 <at> debbugs.gnu.org,  ambrevar <at> gmail.com
> Date: Sun, 04 Jun 2017 11:08:59 -0400
> 
> Eli Zaretskii <eliz <at> gnu.org> writes:
> 
> > And don't forget that the initial frame is invisible in non-daemon
> > sessions as well, until some point during startup.
> 
> I don't understand, is this an objection?

Sorry for being unclear: I meant to point out that a non-daemon
startup initially has such a frame as well, and we never heard any
complaints about that.  Which might mean that some of the code
routinely run during startup expects to find that frame marked
visible.

> > 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?
> 
> The only disadvantage is that we still have this invisible daemon frame
> which is marked as visible.  I agree it's okay to apply your patch now
> and see if we get some other similar problems later.

OK, I've pushed the change.  Let's keep an eye on similar problems if
they pop up.

Previous Next

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