[Top][All Lists]

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

bug#23604: desktop-restore-in-current-display should default to t

From: Drew Adams
Subject: bug#23604: desktop-restore-in-current-display should default to t
Date: Mon, 23 May 2016 13:33:24 -0700 (PDT)

> > 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.)

reply via email to

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