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

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

[Paul Eggert]

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

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.

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

[Eli Zaretskii]

> Date: Mon, 23 May 2016 10:13:58 -0700 (PDT)
> From: Drew Adams <drew.adams@oracle.com>
> 
> 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.

Leaving it at nil makes no sense to me.  It means that you invoke
Emacs, which will then display on a different terminal -- could be a
terminal half a world away.  That could be something that is desired
in some specialized use cases, but makes no sense at all as the
default.

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

This problem will exist on any platform that supports X displays,
i.e. on any Posix system.

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

No, the right course is to set it to t and leave it at that.

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

[Drew Adams]

> Leaving it at nil makes no sense to me.  It means that you invoke
> Emacs, which will then display on a different terminal -- could be a
> terminal half a world away.  That could be something that is desired
> in some specialized use cases, but makes no sense at all as the
> default.
> 
> This problem will exist on any platform that supports X displays,
> i.e. on any Posix system.
> 
> > 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.
> 
> No, the right course is to set it to t and leave it at that.

You elided this, just after that paragraph:

  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.

The proper default value to use, once bug #20274 is fixed, should
be discussed in that context, not in the context of this temporary
workaround (#23604).

Let's have that discussion there and then.
____

As I said before, there are other things that desktop can try to
restore by default that can sometimes not be restored.  And it is
designed to fall back when such a restoration attempt fails.  The
same design applies, a priori, to restoring to a recorded display.
It should be possible to try that and fall back if it is not
possible for some reason (e.g. the display does not exist).

(This is not essentially different from `recentf-exclude' having
a default value of nil, which can lead to problems if the next
session is not in an environment that has access to, for example,
a given host recorded in a remote file or directory entry.)

But we should discuss this later and not here.  This bug is only
about the temporary workaround of setting the value to `t' _to
avoid bug #20274_ rearing its head by default.

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

[Paul Eggert]

On 05/23/2016 10:13 AM, Drew Adams wrote:
> 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. We could 
ask Juanma, who added desktop-restore-in-current-display in 2013, so 
I'll CC Juanma.

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

It's quite bad for Emacs to freeze, so it may make sense to change the 
default in this area even if defaulting to t is suboptimal in some other 
way.

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

[Eli Zaretskii]

> Date: Mon, 23 May 2016 10:47:36 -0700 (PDT)
> From: Drew Adams <drew.adams@oracle.com>
> Cc: eggert@cs.ucla.edu, 23604@debbugs.gnu.org
> 
> > Leaving it at nil makes no sense to me.  It means that you invoke
> > Emacs, which will then display on a different terminal -- could be a
> > terminal half a world away.  That could be something that is desired
> > in some specialized use cases, but makes no sense at all as the
> > default.
> > 
> > This problem will exist on any platform that supports X displays,
> > i.e. on any Posix system.
> > 
> > > 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.
> > 
> > No, the right course is to set it to t and leave it at that.
> 
> You elided this, just after that paragraph:
> 
>   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.

And you elided the part where you claim that no arguments were
presented in favor of the non-nil value.

> The proper default value to use, once bug #20274 is fixed, should
> be discussed in that context, not in the context of this temporary
> workaround (#23604).
> 
> Let's have that discussion there and then.

I don't see any point in delaying the discussion.  The correct default
value is clear already.

> It should be possible to try that and fall back if it is not
> possible for some reason (e.g. the display does not exist).

Feel free to suggest such a test.

> But we should discuss this later and not here.  This bug is only
> about the temporary workaround of setting the value to `t' _to
> avoid bug #20274_ rearing its head by default.

I don't see that as a temporary workaround, I think the default should
be t regardless.

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

[Drew Adams]

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

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

[Drew Adams]

> > The proper default value to use, once bug #20274 is fixed, should
> > be discussed in that context, not in the context of this temporary
> > workaround (#23604).
> >
> > Let's have that discussion there and then.
> 
> I don't see any point in delaying the discussion.  The correct
> default value is clear already.

The discussion is for bug #20274.  It makes sense to continue it
after that bug is fixed, or perhaps while fixing it.  Especially
since if you are making arguments in favor of a particular default
value based on the problem that is #20274.

If the nil use case is as insane as you say it is, then there is
apparently no sense in trying to fix bug #20274 to make it work.

> > It should be possible to try that and fall back if it is not
> > possible for some reason (e.g. the display does not exist).
> 
> Feel free to suggest such a test.

Sorry, I won't be fixing bug #20274.  And what you are discussing
now is exactly how to do that.

Do you maintain your claim that the nil use case is anyway so
inherently problematic that it is not a "sane" case, whether or
not it is the default behavior, so there is, in effect, no bug
#20274 to be fixed - no need to try to make Emacs provide a
reasonable behavior for nil?

> > But we should discuss this later and not here.  This bug is only
> > about the temporary workaround of setting the value to `t' _to
> > avoid bug #20274_ rearing its head by default.
> 
> I don't see that as a temporary workaround, I think the default should
> be t regardless.

But you apparently also think that the nil value should be
removed altogether, because it is not "sane".  No?

Regardless of such an opinion, that is for bug #20274, not this
bug.  Please take discussion of it there.

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

[Paul Eggert]

On 05/23/2016 01:33 PM, Drew Adams wrote:
>> 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?

No, that problem was exposed quite a bit later, months after the 
desktop-restore-in-current-display code was installed.

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

[Drew Adams]

> >> 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?
> 
> No, that problem was exposed quite a bit later, months after the
> desktop-restore-in-current-display code was installed.

Yes, but you have there a clear reiteration of the design intent
and the designer saying that he still thinks that is a sane
default behavior.

So sure, the "original" design predates the use of it and hence
the discovery of such a problem.  But that original design was
still supported by the original designer, with knowledge of the
problem.

Let's not quibble about the words.  In that exchange, at least,
Juanma both (a) still considered the nil default to be a good one,
for the original-design reasons that he reiterated, and (b) was
open to the question of changing the default.  IOW, he was saying
pretty much what I'm saying, IIUC: (a) a nil design choice is a
sane one; it supports a good use case and (b) another default
choice could be OK too.

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

[Paul Eggert]

On 05/23/2016 02:11 PM, Drew Adams wrote:
> Yes, but you have there a clear reiteration of the design intent
> and the designer saying that he still thinks that is a sane
> default behavior.

It's not clear that Juanma would still think the same now, given that he 
was wobbling even then, and we've had more evidence since then (in 
Bug#20247) of problems with the current default. Anyway I hope Juanma 
has time to weigh in so that we don't need to guess.

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

[Juanma Barranquero]

[-- Attachment #1: Type: text/plain, Size: 1170 bytes --]

On Tue, May 24, 2016 at 2:23 AM, Paul Eggert <eggert@cs.ucla.edu> wrote:

> Anyway I hope Juanma has time to weigh in so that we don't need to guess.

I'm alive, which is quite different from active.

Regarding this issue, if memory serves I'd
say desktop-restore-in-current-display defaults to nil because

a) It made sense (to me anyway) that you would restore frames where they
were created. "Bringing them" to the current display seems to me like a
specialized use (a last resort), not the default one. If having it set to
nil means that you open a frame "half a world away" is because you were
working with a display half a world away in the first place...

b) I could be wrong, but I think that was Stefan's preferred default.

That said, I really have no strong preference. We should use the one which
is likely to cause less trouble. OTOH, if it does cause trouble only
for "Emacs users that run the tmux terminal multiplexer atop xterm", it
could be solved at the social level (I mean, warning users), or there's
perhaps a way to detect it (perhaps some frame parameters could give a
clue?) and avoid the problem altogether.

Am I making any sense?

    Juanma

[-- Attachment #2: Type: text/html, Size: 1488 bytes --]

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

[Drew Adams]

> Am I making any sense?

To me you are.  Thanks for your input and your memory of the history.

My hope is that something interesting and useful can come from
trying to deal with bug #20274, whatever default value is chosen.

The major question is that bug, I think: whether a nil use case
can be made less problematic.

Perhaps one way to start to trim it down a bit is to identify
cases where it is problematic.  E.g., "tmux terminal multiplexer
atop xterm", "Emacs -nw", whatever else.  And then try to do so
programmatically.  IOW, perhaps keeping a nil behavior need not
be a case of all or nothing.

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

[Eli Zaretskii]

> Date: Mon, 23 May 2016 13:33:31 -0700 (PDT)
> From: Drew Adams <drew.adams@oracle.com>
> Cc: eggert@cs.ucla.edu, 23604@debbugs.gnu.org,
>         Juanma Barranquero
>  <lekktu@gmail.com>
> 
> Do you maintain your claim that the nil use case is anyway so
> inherently problematic that it is not a "sane" case, whether or
> not it is the default behavior, so there is, in effect, no bug
> #20274 to be fixed - no need to try to make Emacs provide a
> reasonable behavior for nil?

I was talking only about the default value.  Please stop putting your
words into my mouth.

> > I don't see that as a temporary workaround, I think the default should
> > be t regardless.
> 
> But you apparently also think that the nil value should be
> removed altogether, because it is not "sane".  No?

See above.

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

[Drew Adams]

> I was talking only about the default value.  Please stop
> putting your words into my mouth.

Hm.  Sorry if I misunderstood you.  But these were your words:

  Can you explain why using display that is not the current
  one even makes sense?

Anyway, great.  Glad to hear it, if you're not claiming that
using a display other than the current makes no sense.

So the problems we see now with nil, once taken care of (bug
#20247), should have no bearing on which value to choose as
the default.

Which is what I said: let's see what happens with bug #20247,
and then decide which value is more useful as the default.

(Until then t is more useful, of course - that's this
workaround, #23604.)

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

[Paul Eggert]

No further comment, and there seems general agreement that the default should be 
t in the emacs-25 branch, so I installed that change and am closing Bug#23604. 
The more-general Bug#20247 remains, but is not a blocker for the Emacs 25 release.