Re: desktop.el and frame parameters when -nw

Re: desktop.el and frame parameters when -nw

[martin rudalics]

 > When desktop.el saves/loads a session, it normally saves and loads the 'frame
 > parameters' (set with `set-frame-parameter' and `frame-parameter'). However,
 > when starting emacs with -nw (in a terminal, with no gui), these frame
 > parameters don't seem to be restored.

I suppose this is due to desktop.el's

(defun desktop-restoring-frameset-p ()
   "True if calling `desktop-restore-frameset' will actually restore it."
   (and desktop-restore-frames desktop-saved-frameset (display-graphic-p) t))

Try removing the (display-graphic-p).  But I'm quite confident that
this will get you into lots of other troubles.

martin

Re: desktop.el and frame parameters when -nw

[Eli Zaretskii]

> Date: Wed, 25 Jul 2018 08:33:40 +0200
> From: martin rudalics <rudalics@gmx.at>
> Cc: help-gnu-emacs@gnu.org
> 
> (defun desktop-restoring-frameset-p ()
>    "True if calling `desktop-restore-frameset' will actually restore it."
>    (and desktop-restore-frames desktop-saved-frameset (display-graphic-p) t))
> 
> Try removing the (display-graphic-p).  But I'm quite confident that
> this will get you into lots of other troubles.

Neither do I.  I think we need to look into this more carefully, as
that test wasn't added there by chance.  And there _are_ frame
parameters which we do NOT want to restore in TTY frames.

desktop.el and frame parameters when -nw

[Jay Kamat]

Hi!

I'm running into an odd issue, and I'd like to see if anyone else has seen it
before (or knows any way to solve it).

When desktop.el saves/loads a session, it normally saves and loads the 'frame
parameters' (set with `set-frame-parameter' and `frame-parameter'). However,
when starting emacs with -nw (in a terminal, with no gui), these frame
parameters don't seem to be restored.

Steps I took to reproduce:

1. Start emacs -q
2. Eval (set-frame-parameter nil 'test 44)
3. M-x desktop-save to an unused directory.
4. emacs -q -nw
5. M-x desktop-change-dir to the directory from before
6. (frame-parameter nil 'test) returns nil.

However, running steps 4->6 without -nw returns the frame parameter as
expected.

Does this have anything to do with the special ways that frames are handled in
a terminal? If so, what can I do to work around that?

-Jay

Re: desktop.el and frame parameters when -nw

[Eli Zaretskii]

> From: Jay Kamat <jaygkamat@gmail.com>
> Date: Tue, 24 Jul 2018 19:03:44 -0700
> 
> When desktop.el saves/loads a session, it normally saves and loads the 'frame
> parameters' (set with `set-frame-parameter' and `frame-parameter'). However,
> when starting emacs with -nw (in a terminal, with no gui), these frame
> parameters don't seem to be restored.
> 
> Steps I took to reproduce:
> 
> 1. Start emacs -q
> 2. Eval (set-frame-parameter nil 'test 44)
> 3. M-x desktop-save to an unused directory.
> 4. emacs -q -nw
> 5. M-x desktop-change-dir to the directory from before
> 6. (frame-parameter nil 'test) returns nil.
> 
> However, running steps 4->6 without -nw returns the frame parameter as
> expected.

Why do you need such frame parameters restored when you start Emacs
with -nw?  IOW, what is your real-life use case, and why cannot you
start Emacs without -nw, and then create a TTY frame in that session?

Re: desktop.el and frame parameters when -nw

[Jay Kamat]

Hi Eli, Martin,

Eli Zaretskii writes:

> Why do you need such frame parameters restored when you start Emacs
> with -nw?  IOW, what is your real-life use case, and why cannot you
> start Emacs without -nw, and then create a TTY frame in that session?

I use a package called 'eyebrowse' which stores information about workspaces
in the frame parameters. Because this data is not saved and restored, my
eyebrowse workspaces get lost in tty frames after an Emacs quit. I'm trying to
run Emacs on a remote server with no graphical interface at all, so I don't
think I'll be able to run the gui version and open a frame (without installing
all of X).

I'm not sure why eyebrowse stores it's information in the frame parameters...

> I suppose this is due to desktop.el's
>
> (defun desktop-restoring-frameset-p ()
>    "True if calling `desktop-restore-frameset' will actually restore it."
>    (and desktop-restore-frames desktop-saved-frameset (display-graphic-p) t))
>
> Try removing the (display-graphic-p). But I'm quite confident that this will
> get you into lots of other troubles.

Thanks for the pointer! I was able to come up with this:

(unless (display-graphic-p)
  (setq desktop-restore-forces-onscreen nil)
  (defun desktop-restoring-frameset-p ()
    "True if calling `desktop-restore-frameset' will actually restore it.

Removes graphical from the list of required parameters."
    (and desktop-restore-frames desktop-saved-frameset t)))

I'm not sure why I needed to set `desktop-restore-forces-onscreen' to nil, but
I was getting errors without it. With this though, I'm getting the expected
behavior. I'll remember to disable this if I run into any odd issues or
breakages though. Hopefully the gui frame parameters that I shouldn't be
restoring isn't a problem since the desktop sessions I'm loading from are
terminal-only (for now at least).

-Jay

Re: desktop.el and frame parameters when -nw

[Eli Zaretskii]

> From: Jay Kamat <jaygkamat@gmail.com>
> Cc: help-gnu-emacs@gnu.org
> Date: Wed, 25 Jul 2018 20:02:57 -0700
> 
> > Try removing the (display-graphic-p). But I'm quite confident that this will
> > get you into lots of other troubles.
> 
> Thanks for the pointer! I was able to come up with this:
> 
> (unless (display-graphic-p)
>   (setq desktop-restore-forces-onscreen nil)
>   (defun desktop-restoring-frameset-p ()
>     "True if calling `desktop-restore-frameset' will actually restore it.
> 
> Removes graphical from the list of required parameters."
>     (and desktop-restore-frames desktop-saved-frameset t)))
> 
> I'm not sure why I needed to set `desktop-restore-forces-onscreen' to nil, but
> I was getting errors without it. With this though, I'm getting the expected
> behavior. I'll remember to disable this if I run into any odd issues or
> breakages though. Hopefully the gui frame parameters that I shouldn't be
> restoring isn't a problem since the desktop sessions I'm loading from are
> terminal-only (for now at least).

The reason for the condition you removed is that restoring the
frameset on TTYs which were saved in a GUI session triggers bugs.  If
you don't care about those bugs, fine.