all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Eli Zaretskii <eliz@gnu.org>
To: npostavs@users.sourceforge.net
Cc: 27210@debbugs.gnu.org, ambrevar@gmail.com
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	[thread overview]
Message-ID: <837f0rc00d.fsf@gnu.org> (raw)
In-Reply-To: <874lvw1xho.fsf@users.sourceforge.net> (npostavs@users.sourceforge.net)

> 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	other threads:[~2017-06-04 14:15 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-06-03 14:29 bug#27210: 25.2; Recovering loaddefs.el with desktop-mode hangs when linum is on Pierre Neidhardt
2017-06-03 14:56 ` Eli Zaretskii
2017-06-03 16:22   ` Pierre Neidhardt
2017-06-03 17:43     ` npostavs
2017-06-03 18:02       ` Eli Zaretskii
2017-06-03 18:38         ` Eli Zaretskii
2017-06-03 19:52           ` npostavs
2017-06-03 23:07             ` npostavs
2017-06-04 14:15               ` Eli Zaretskii [this message]
2017-06-04 15:08                 ` npostavs
2017-06-04 16:31                   ` Eli Zaretskii

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=837f0rc00d.fsf@gnu.org \
    --to=eliz@gnu.org \
    --cc=27210@debbugs.gnu.org \
    --cc=ambrevar@gmail.com \
    --cc=npostavs@users.sourceforge.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.