bug#20247: 24.4; Emacs hangs at startup in desktop mode

[Drew Adams <drew.adams@oracle.com>]

> > Can we not leave the default to respecting the saved display value,
> > but also use a `condition-case' or similar to DTRT if that display
> > does not exist or trying to use it raises an error in some other way?
> 
> Can you explain why using display that is not the current one even
> makes sense?

Ask Juanma, or whoever else might have been responsible for designing
this aspect of desktop.

Desktop is designed to support exactly that, no?  You are apparently
questioning the design.  That's fair, but is it necessary to address
this bug?

Anyway, I can't speak to the reasons why desktop is designed as
it is.  I'm just assuming that the design is not insane, as you
seem to be suggesting (this part of) it is.

> > The proposed cure sounds like killing the patient.
> 
> To me it sounds like the only sane behavior.

It sounds like you think it is insane for desktop to ever
specify (record) or use a `display' entry.  If so, that sounds
like a design change for desktop.

Do you not think there was a reason to allow users to record
the display as part of a desktop record, and to restore the
desktop using that recorded display?  Can you not imagine such
a use case?  I can, but maybe I'm missing something.

Desktop records lots of stuff that might not be usable when
an attempt is made to restore the recorded desktop.  Normally,
it tries to be fault-tolerant during restoration, and back off
when trying to restore something doesn't work or seems to be
inappropriate in the restoration context.

I don't see how this problem is different, or why it should be
handled differently, especially by simply getting rid of any
ability to restore to a particular display.

As I said, this in no way affects how I use Emacs, personally.
But I'm guessing that there was a (good) reason for allowing
recording (and so restoring) a `display' value.  And I'm
guessing that some users might be taking advantage of it.

I don't see how this bug necessitates tossing that part of the
desktop design.  But apparently you do.

> > And it doesn't solve the underlying problem for a user who decides
> > to customize the value to use the recorded display value.
> 
> The assumption is that if such a customization produces problematic
> behavior, users won't do that.

If you take the view you seem to be taking, then why not simply
remove all desktop support for a `display' entry?  Why stop with
changing the default value of this option?  Fix the problem by
eliminating the cause altogether, not just as a default value.

> > A better fix, I think, would be to do something like this:
> >
> > 1. Leave the default as is (not specifically important to this bug,
> > however, as I mentioned: changing the default does NOT solve the
> > problem, AFAICT).
> >
> > 2. If the current value says to use the recorded display then try
> > to do that.  If an error is raised then do not use it.
> 
> That's okay to try on master (if someone thinks it would be better),
> but not on the release branch.  Note that trying to use it might
> display some of the frames, which would then be tricky to remove, and
> flashing them might not look good.

I don't doubt that it might be tricky to try to fix.

> > I don't have the code for #2.  No doubt Someone (TM) would need to
> > _actually try to debug this_, to find out just what happens when a
> > bad display value is tried.
> 
> I think it's clear without any debugging.

Really?  In that case, can you please make it raise an error instead
of hanging?  And if you can do that then I'm guessing it should be
pretty simple to DTRT and check for that error - and when it is raised
not try to restore to the recorded `display' entry.  No?

> > The first task is for Someone (TM) to actually try to find out
> > what the problem is - what happens - when the display value is
> > inappropriate.
> 
> The same thing that happens when you try to communicate with a machine
> that is down or disconnected.

So turn that eventuality into raising an error, and handle the error
by abandoning continuing to try to use that nonexistent/broken display.
IOW, act, when there is such an error, the way you apparently want
Emacs to act all the time: as if no `display' entry were recorded.

Again. I don't really care what you do with this bug, personally.
It just sounds like you are perhaps throwing out the baby (= desktop
support for `display' entries) with the bathwater.  The baby needs a
bath, sure, but s?he shouldn't be tossed out in the process, I think.

I'm done here.  Do what you will.  Just trying to help.