From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.bugs 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 Message-ID: <837f0rc00d.fsf@gnu.org> References: <20170603142911.GB7275@gmail.com> <83fufhaznj.fsf@gnu.org> <20170603162244.GD7275@gmail.com> <87a85p0xwu.fsf@users.sourceforge.net> <83efv1aqzx.fsf@gnu.org> <83d1akc3ws.fsf@gnu.org> <877f0s26j9.fsf@users.sourceforge.net> <874lvw1xho.fsf@users.sourceforge.net> Reply-To: Eli Zaretskii NNTP-Posting-Host: blaine.gmane.org X-Trace: blaine.gmane.org 1496585774 14436 195.159.176.226 (4 Jun 2017 14:16:14 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sun, 4 Jun 2017 14:16:14 +0000 (UTC) Cc: 27210@debbugs.gnu.org, ambrevar@gmail.com To: npostavs@users.sourceforge.net Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Sun Jun 04 16:16:07 2017 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dHWK6-0003MF-Sn for geb-bug-gnu-emacs@m.gmane.org; Sun, 04 Jun 2017 16:16:06 +0200 Original-Received: from localhost ([::1]:57134 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dHWKC-0001Hx-6V for geb-bug-gnu-emacs@m.gmane.org; Sun, 04 Jun 2017 10:16:12 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:49371) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dHWK5-0001Hs-Np for bug-gnu-emacs@gnu.org; Sun, 04 Jun 2017 10:16:06 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1dHWK2-0001pY-93 for bug-gnu-emacs@gnu.org; Sun, 04 Jun 2017 10:16:05 -0400 Original-Received: from debbugs.gnu.org ([208.118.235.43]:53237) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1dHWK2-0001pT-4e for bug-gnu-emacs@gnu.org; Sun, 04 Jun 2017 10:16:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1dHWK1-0002lr-VA for bug-gnu-emacs@gnu.org; Sun, 04 Jun 2017 10:16:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 04 Jun 2017 14:16:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 27210 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: confirmed Original-Received: via spool by 27210-submit@debbugs.gnu.org id=B27210.149658574010622 (code B ref 27210); Sun, 04 Jun 2017 14:16:01 +0000 Original-Received: (at 27210) by debbugs.gnu.org; 4 Jun 2017 14:15:40 +0000 Original-Received: from localhost ([127.0.0.1]:55914 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dHWJg-0002lG-JJ for submit@debbugs.gnu.org; Sun, 04 Jun 2017 10:15:40 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:58374) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dHWJf-0002l3-IO for 27210@debbugs.gnu.org; Sun, 04 Jun 2017 10:15:39 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1dHWJZ-0001OW-4d for 27210@debbugs.gnu.org; Sun, 04 Jun 2017 10:15:34 -0400 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:54480) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dHWJR-0001JZ-Sk; Sun, 04 Jun 2017 10:15:25 -0400 Original-Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:3443 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1dHWJR-0000PN-0G; Sun, 04 Jun 2017 10:15:25 -0400 In-reply-to: <874lvw1xho.fsf@users.sourceforge.net> (npostavs@users.sourceforge.net) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 208.118.235.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.org gmane.emacs.bugs:133254 Archived-At: > 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 > 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.