From: Drew Adams <drew.adams@oracle.com>
To: Paul Eggert <eggert@cs.ucla.edu>
Cc: Juanma Barranquero <lekktu@gmail.com>, 23604@debbugs.gnu.org
Subject: bug#23604: desktop-restore-in-current-display should default to t
Date: Mon, 23 May 2016 13:33:24 -0700 (PDT) [thread overview]
Message-ID: <00be9358-ec48-46da-adc9-52038ddf3b2c@default> (raw)
In-Reply-To: <51d2f8d4-03a4-d585-fe6f-cd61a7d71238@cs.ucla.edu>
> > The default value should, I think, be nil. A priori, it should
> > be nil because that was the chosen design for this variable.
>
> It's not clear that the original design choice was made in full
> knowledge of the problems that have been exposed since then.
And yet you cite (below) one such problem, from the time the design
was developed, no?
The problem, which is bug #20274, is a _bug_, which needs to be fixed.
I thought we all agreed on that, but now I'm not so sure.
> We could ask Juanma, who added desktop-restore-in-current-display
> in 2013, so I'll CC Juanma.
Unfortunately, Juanma has been incommunicado wrt Emacs for a while
now, but yes, ccing him might bring him back to Emacs life. ;-)
> This problem of Emacs freezing has been a recurring one; see, e.g., the
> thread that starts here:
>
> https://lists.gnu.org/archive/html/emacs-devel/2013-12/msg00472.html
Where a certain D, Adams said this, BTW:
"(Not sure what the default value should be, BTW.)"
Which is still my thought. _A priori_, I think it should be t, for
the reasons I gave. But I'm open to being convinced otherwise.
In any case, the behavior for the nil caseneeds to be fixed, whether
or not it is the default choice. That is bug #20274.
Emacs needs to DTRT when nil is chosen, even when a recorded display
cannot, in fact, be used. _How_ it might do that is for bug #20274
to work out (not here).
> It's quite bad for Emacs to freeze,
Agreed 100%.
> so it may make sense to change the default in this area even if
> defaulting to t is suboptimal in some other way.
Changing the default behavior from nil does not change the behavior
for nil.
The point of separating this bug out is to be able to bypass the
bug (#20274) for the default case, which at least reduces the
chances of running into it.
But the fact _that_ the nil case can be problematic is not in
dispute. And neither, I would hope, is the fact that bug #20274
is a bug, and should be fixed.
(The latter may be in dispute by Eli, who seems to think that a
nil choice is not sane even if #20274 is fixed (?).)
As for your question earlier as to what the original design/intent
was, this sentence from Juanma in the thread you cite should help:
The current default is to restore every frame in its original
display, which seems pretty sane to me.
Interesting that both he and Eli use the word "sane", but attribute
it oppositely for this (nil default) use case.
Juanma also said this in this regard:
We could change the default, or we could make the default be t
or nil depending on -nw. WDOT?
(And I repeat that the default value does not affect my own use
of Emacs.)
next prev parent reply other threads:[~2016-05-23 20:33 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-05-23 16:37 bug#23604: desktop-restore-in-current-display should default to t Paul Eggert
2016-05-23 17:13 ` Drew Adams
2016-05-23 17:28 ` Eli Zaretskii
2016-05-23 18:07 ` Paul Eggert
2016-05-23 20:33 ` Drew Adams [this message]
2016-05-23 21:01 ` Paul Eggert
2016-05-23 21:11 ` Drew Adams
2016-05-24 0:23 ` Paul Eggert
2016-05-24 0:37 ` Juanma Barranquero
2016-05-24 0:54 ` Drew Adams
2016-05-30 5:50 ` Paul Eggert
[not found] <<278b113b-21aa-5c54-6550-79bf1e481530@cs.ucla.edu>
[not found] ` <<f47f4679-8838-4410-968b-c3e9335fa806@default>
[not found] ` <<83a8jg65vd.fsf@gnu.org>
2016-05-23 17:47 ` Drew Adams
2016-05-23 18:19 ` Eli Zaretskii
[not found] <<<278b113b-21aa-5c54-6550-79bf1e481530@cs.ucla.edu>
[not found] ` <<<f47f4679-8838-4410-968b-c3e9335fa806@default>
[not found] ` <<<83a8jg65vd.fsf@gnu.org>
[not found] ` <<76836464-8187-469c-9ddd-df27b6da1acc@default>
[not found] ` <<831t4s63i2.fsf@gnu.org>
2016-05-23 20:33 ` Drew Adams
2016-05-24 2:31 ` Eli Zaretskii
[not found] <<<<278b113b-21aa-5c54-6550-79bf1e481530@cs.ucla.edu>
[not found] ` <<<<f47f4679-8838-4410-968b-c3e9335fa806@default>
[not found] ` <<<<83a8jg65vd.fsf@gnu.org>
[not found] ` <<<76836464-8187-469c-9ddd-df27b6da1acc@default>
[not found] ` <<<831t4s63i2.fsf@gnu.org>
[not found] ` <<48df821e-5abc-4e05-8b1e-82365ff6f15c@default>
[not found] ` <<83wpmk426m.fsf@gnu.org>
2016-05-24 4:43 ` Drew Adams
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
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=00be9358-ec48-46da-adc9-52038ddf3b2c@default \
--to=drew.adams@oracle.com \
--cc=23604@debbugs.gnu.org \
--cc=eggert@cs.ucla.edu \
--cc=lekktu@gmail.com \
/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 public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).