Subject: bug#55070: 28.1; desktop-load doesn't work in -nw (non-gui) emacs

From: Eric Swenson <[email-masked]>
Date: Sat, 23 Apr 2022 08:39:12 -0700

Ah, that makes sense. Thanks. Still, this is very non-obvious to the user and is really an current implementation decision issue rather than a good reason for not supporting it.

I suggest two action items. 1) update the documentation for desktop-save and desktop-read to say that it only works in non -nw sessions. 2) keep this ticket open since the functionality makes as much sense in -nw sessions as in GUI sessions. 

The code could certainly be updated to handle the case where there is a single frame and the user is trying to restore in an -nw session. 

Also, while I have your ear, the obvious command for restoring a desktop when desktop-save is used to save it would be desktop-restore. Desktop-read is very non-intuitive.

Thanks for listening and explaining the reason for the limitation.

-- Eric (KN6SIJ)

> On Apr 23, 2022, at 08:16, Eli Zaretskii <[email-masked]> wrote:
> 
> 
>> 
>> From: Eric Swenson <[email-masked]>
>> Date: Sat, 23 Apr 2022 07:53:43 -0700
>> Cc: [email-masked]
>> 
>> Thanks. It seems really strange that this should be problematic in -nw sessions. I could understand not being able to restore windows between a GUI and -nw sessions, but I don’t see why, since windows work perfectly well in a single frame in a -nw session that restoring them should be problematic.
>> 
>> Can you explain why this is difficult? In -nw sessions the same commands split windows perfectly well. So clearly -nw sessions support window splitting — why not restoring? (I think a restriction that requires the saving and restoring sessions to be the same kind (either both -nw or both GUI) is a perfectly sensible restriction.
> 
> Emacs currently cannot restore windows without also restoring the
> frames.  Technically, this is because we use the frameset.el package
> as infrastructure for this desktop.el facility.  And restoring frames
> in a -nw session will create GUI frames, something the user didn't
> intend.  So we disabled that.