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

[Drew Adams]

> The current default value for desktop-restore-in-current-display is nil,
> and this default causes real problems with Emacs users that run the tmux
> terminal multiplexer atop xterm. Emacs hangs, and users have to kill it.
> To work around this problem for most users, let's change the default
> value from nil to t.
> 
> This request is inspired by Bug#20247, which is currently listed as a
> blocker for Emacs 25. I'm filing this new bug report so that we can list
> the new bug report as a blocker for Emacs 25, and stop listing Bug#20247
> as a blocker. The underlying bug will still be present, but there is no
> trivial fix for it and the idea is that fixing the underlying bug can
> wait until after Emacs 25 comes out.
> 
> The bottom line is that this new bug report asks to install the patch
> described in <http://bugs.gnu.org/20247#16>.

The default value should, I think, be nil.  A priori, it should
be nil because that was the chosen design for this variable.  And
because that is generally the behavior for other desktop settings
that are recorded - desktop generally tries to restore as much of
the previous session as possible, by default.

Reasonable arguments to the contrary could be presented.  Until
then, I'm not convinced - a priori, I favor the nil default chosen
for the original design.

So far, we have heard no such arguments - which is OK as long as
the change to t for now is regarded as only a tempoerary expedient.
We can discuss the proper default behavior later, in the context
of (unresolved) bug #20247.

Changing the default to t now (for Emacs 25.1) should be regarded
as only a temporary, hack workaround, not a deliberate change in
the design.  No design arguments have been given for changing it.

The choice of the default value (beyond this temporary workaround)
should not be governed by the existence of bug #20247.  Instead,
that bug should be fixed and the best default value chosen based
on what helps users the most.

Choosing a default value should not be based on the fact that
there is a bad bug when one of the values is used.  If we did
that, that would also be an argument for not allowing that value
as a possibility at all.  As long as nil can lead to Emacs
hanging, the use (not just by default) of nil is inappropriate.

It is too bad to change a default value only as a temporary
workaround, and then change it back again when the bug worked
around is finally fixed.  We should avoid doing this in Emacs.
Changing th default value to t does not fix bug #20247, we all
(finally) agree.

Apparently we are in such a hurry to toss Emacs 25.1 over the
wall that we don't want to take the time to fix this bug (#20247).
That's too bad, IMO.  (In the old (RMS) days, I think the release
would have been delayed for this.)

An alternative, and less inappropriate workaround could perhaps
be (i.e., have been) to change the default value only for the
platform where this bug was reported, if we had some idea that
other platforms were not necessarily affected by it.

Anyway, the right course of action now (if Emacs 25.1 is released
with the default value changed to t) is (after the 25.1 release)
to fix bug #20247 and revert the default value to nil.

At that point, if there is disagreement about the default value,
i.e., if someone really thinks it should be t by design (and not
just as a workaround), then we can discuss the pros & cons for
the default behavior.

One opinion.