bug#10348: 24.0.92; Save and load window states

bug#10348: 24.0.92; Save and load window states

[Michael Bach]

`window-state-put' as used within the following functions does not work.
Please see *Backtrace* below for error.  (See also post to
help-gnu-emacs@gnu.org with subject "Save and load window states")

Steps to reproduce: 
1) Start via `emacs -Q'.
2) evaluate the two functions:
(defun my-save-frame ()
  (interactive)
  (let ((buf (find-file-noselect "/tmp/emacs-layout")))
    (set-buffer buf)
    (erase-buffer)
    (print (window-state-get) buf)
    (save-buffer)
    (kill-buffer)))

(defun my-load-frame ()
  (interactive)
  (let ((buf (find-file-noselect "/tmp/emacs-layout")))
    (set-buffer buf)
    (beginning-of-buffer)
    (window-state-put (read buf))
    (kill-buffer)))

3) Do a `M-x my-save-frame' and after that `M-x my-load-frame'

Debugger entered--Lisp error: (invalid-read-syntax "#")
  read(#<buffer emacs-layout>)
  (window-state-put (read buf))
  (let ((buf (find-file-noselect "/tmp/emacs-layout"))) (set-buffer buf) (beginning-of-buffer) (window-state-put (read buf)) (save-buffer) (kill-buffer))
  my-load-frame()
  call-interactively(my-load-frame t nil)
  execute-extended-command(nil)
  call-interactively(execute-extended-command nil nil)

Important settings:
  value of $LC_ALL: nil
  value of $LC_COLLATE: nil
  value of $LC_CTYPE: nil
  value of $LC_MESSAGES: nil
  value of $LC_MONETARY: nil
  value of $LC_NUMERIC: nil
  value of $LC_TIME: nil
  value of $LANG: en_US.UTF-8
  value of $XMODIFIERS: nil
  locale-coding-system: utf-8
  default enable-multibyte-characters: t

Recent messages:
Wrote /tmp/emacs-layout
Quit
Mark set
window-state-put: Invalid read syntax: "#"

bug#10348: 24.0.92; Save and load window states

[martin rudalics]

 > Steps to reproduce:
 > 1) Start via `emacs -Q'.
 > 2) evaluate the two functions:
 > (defun my-save-frame ()
 >   (interactive)
 >   (let ((buf (find-file-noselect "/tmp/emacs-layout")))
 >     (set-buffer buf)
 >     (erase-buffer)
 >     (print (window-state-get) buf)
 >     (save-buffer)
 >     (kill-buffer)))
 >
 > (defun my-load-frame ()
 >   (interactive)
 >   (let ((buf (find-file-noselect "/tmp/emacs-layout")))
 >     (set-buffer buf)
 >     (beginning-of-buffer)
 >     (window-state-put (read buf))
 >     (kill-buffer)))
 >
 > 3) Do a `M-x my-save-frame' and after that `M-x my-load-frame'
 >
 > Debugger entered--Lisp error: (invalid-read-syntax "#")
 >   read(#<buffer emacs-layout>)
 >   (window-state-put (read buf))
 >   (let ((buf (find-file-noselect "/tmp/emacs-layout"))) (set-buffer buf) (beginning-of-buffer) (window-state-put (read buf)) (save-buffer) (kill-buffer))
 >   my-load-frame()
 >   call-interactively(my-load-frame t nil)
 >   execute-extended-command(nil)
 >   call-interactively(execute-extended-command nil nil)

FWIW, the behavior observed by Michael is caused by the presence of
window objects in the `clone-of' parameters saved by `window-state-get'.
I initially used the window number for this purpose but Stefan later
told me that a user can store arbitrary objects without read syntax in
window parameters so this would have just worked around the current
problem but would not work in general. (The corresponding thread was at
http://lists.gnu.org/archive/html/emacs-diffs/2011-06/msg00321.html but
I have no idea how to retrieve it.)

We have a variety of ways to deal with this:

(1) Do not save the `clone-of' parameter.  It's not yet useful anyway.
     This will not solve the more general problem mentioned above.

(2) Do not save window parameters.  While this should fix all problems
     in the context of this bug report, it will prevent us from saving
     and restoring information needed to make applications work that rely
     on window parameters.

(3) Save only parameters whose value have a read syntax.  This can be
     done either in `window-state-get' or in `my-save-frame'.

(4) Convert parameter values to something with a read syntax.  Basically
     this is what we already do with buffers (using the name of the
     buffer instead of the buffer object) and can be easily done with
     windows (save the window number instead of the window object).

(5) Make functions like `my-load-frame' aware that components of saved
     window states might not have a read syntax and have them take the
     appropriate action.

Unless you have a better suggestion I'll apply (1) for Emacs 24.1 and
try to propose a combination of (3) and (4) for later releases.

martin

bug#10348: 24.0.92; Save and load window states

[Drew Adams]

> We have a variety of ways to deal with this:
> 
> (1) Do not save the `clone-of' parameter.  It's not yet useful anyway.
>      This will not solve the more general problem mentioned above.
> 
> (2) Do not save window parameters.  While this should fix all problems
>      in the context of this bug report, it will prevent us from saving
>      and restoring information needed to make applications 
>      work that rely on window parameters.
> 
> (3) Save only parameters whose value have a read syntax.  This can be
>      done either in `window-state-get' or in `my-save-frame'.
> 
> (4) Convert parameter values to something with a read syntax. 
>      Basically
>      this is what we already do with buffers (using the name of the
>      buffer instead of the buffer object) and can be easily done with
>      windows (save the window number instead of the window object).
> 
> (5) Make functions like `my-load-frame' aware that components of saved
>      window states might not have a read syntax and have them take the
>      appropriate action.
> 
> Unless you have a better suggestion I'll apply (1) for Emacs 24.1 and
> try to propose a combination of (3) and (4) for later releases.

Perhaps another possibility?

(6) Provide read syntax for all known parameter values.

Just a thought - no idea whether it is a good idea.

bug#10348: 24.0.92; Save and load window states

[Juri Linkov]

> Unless you have a better suggestion I'll apply (1) for Emacs 24.1 and
> try to propose a combination of (3) and (4) for later releases.

(7) Save window ids as numbers for referencing them when reading, e.g.

  (...
   (hc
    ...
    (id 3)
    (parameters
     (clone-of . 7))
    (leaf
     ...
     (id 7)
     (parameters
      (clone-of . 9))
     (buffer "*scratch*" ...))
    (vc
     (id 9)
     (parameters
      (clone-of . 3))
      ...
      )))

bug#10348: 24.0.92; Save and load window states

[Juanma Barranquero]

> (7) Save window ids as numbers for referencing them when reading, e.g.

This is a fix for this specific bug, as is Martin's proposal 1, which
is also simpler.

But that does not fix the general problem of window parameters
containing objects with no read syntax. So Martin's 3, 4 or 5 is still
needed (post 24.1).

    Juanma

bug#10348: 24.0.92; Save and load window states

[Juri Linkov]

> But that does not fix the general problem of window parameters
> containing objects with no read syntax. So Martin's 3, 4 or 5 is still
> needed (post 24.1).

For the general problem we could use something like `desktop-outvar'
from desktop.el.

bug#10348: 24.0.92; Save and load window states

[martin rudalics]

 > For the general problem we could use something like `desktop-outvar'
 > from desktop.el.

Looks like Drew is already investigating `desktop-internal-v2s' ;-)

martin

bug#10348: 24.0.92; Save and load window states

[Drew Adams]

>  > For the general problem we could use something like 
>  > `desktop-outvar' from desktop.el.
> 
> Looks like Drew is already investigating `desktop-internal-v2s' ;-)

;-) Not really - just looked it over.

But I do save things on my own and wanted to see if there was now a conventional
serialization route.

FWIW, maybe like something general like that should be autoloadable or, better
perhaps, somewhere other than desktop.el?  Just a thought - why need to load
desktop.el if you are not necessarily interested in saving/restoring desktops
and you just want to serialize something?

bug#10348: 24.0.92; Save and load window states

[Juri Linkov]

> FWIW, maybe like something general like that should be autoloadable or, better
> perhaps, somewhere other than desktop.el?  Just a thought - why need to load
> desktop.el if you are not necessarily interested in saving/restoring desktops
> and you just want to serialize something?

It is tied to desktop functionality.  For example, see how it serializes
markers, and delays restoration of their values in `desktop-delay-hook'
until the desktop is completely loaded:

(desktop-value-to-string (window-state-get nil t))
=>
(list '((min-height . 4)
        (min-width . 10)
        (min-height-ignore . 2)
        (min-width-ignore . 9)
        (min-height-safe . 1)
        (min-width-safe . 2))
      'leaf
      '(total-height . 61)
      '(total-width . 227)
      '(normal-height . 1.0)
      '(normal-width . 1.0)
      '(combination-limit)
      '(parameters
        (clone-of . "Unprintable entity"))
      (list 'buffer "*scratch*"
            '(selected . t)
            '(hscroll . 0)
            '(fringes 9 9 nil)
            '(margins nil)
            '(scroll-bars 16 3 t nil)
            '(vscroll . 0)
            '(dedicated)
            (desktop-list* 'point
                           (let ((mk (make-marker)))
                             (add-hook 'desktop-delay-hook
                                       (list 'lambda '()
                                             (list 'set-marker mk 243
                                                   (get-buffer "*scratch*"))))
                             mk))
            (desktop-list* 'start
                           (let ((mk (make-marker)))
                             (add-hook 'desktop-delay-hook
                                       (list 'lambda '()
                                             (list 'set-marker mk 1
                                                   (get-buffer "*scratch*"))))
                             mk))
            (desktop-list* 'mark
                           (let ((mk (make-marker)))
                             (add-hook 'desktop-delay-hook
                                       (list 'lambda '()
                                             (list 'set-marker mk 192
                                                   (get-buffer "*scratch*"))))
                             mk))))

bug#10348: 24.0.92; Save and load window states

[martin rudalics]

 > (7) Save window ids as numbers for referencing them when reading, e.g.
 >
 >   (...
 >    (hc
 >     ...
 >     (id 3)
 >     (parameters
 >      (clone-of . 7))

I did something like that in revision #104759.  Note, however, that
numbers work reliably only when using `window-state-put' in one and the
same session as the corresponding `window-state-get'.  It would be
rather difficult to make them work across sessions.

martin

bug#10348: 24.0.92; Save and load window states

[Stefan Monnier]

> (1) Do not save the `clone-of' parameter.  It's not yet useful anyway.
>     This will not solve the more general problem mentioned above.

As mentioned, it's not a really convincing solution.

> (2) Do not save window parameters.  While this should fix all problems
>     in the context of this bug report, it will prevent us from saving
>     and restoring information needed to make applications work that rely
>     on window parameters.

This is fairly attractive, tho a bit too radical.

> (3) Save only parameters whose value have a read syntax.  This can be
>     done either in `window-state-get' or in `my-save-frame'.

This can make the save&restore work and fail in somewhat
unpredictable ways.  Too magical.

> (4) Convert parameter values to something with a read syntax.  Basically
>     this is what we already do with buffers (using the name of the
>     buffer instead of the buffer object) and can be easily done with
>     windows (save the window number instead of the window object).

This would be a good change, especially if by "window number" you mean
a number meaningful in an output file rather than only in the current
session (see Juri's example) but it doesn't fix all cases.

> (5) Make functions like `my-load-frame' aware that components of saved
>     window states might not have a read syntax and have them take the
>     appropriate action.

This is like (3) except the magic is done elsewhere.

> Unless you have a better suggestion I'll apply (1) for Emacs 24.1 and
> try to propose a combination of (3) and (4) for later releases.

I think the best course of action is to only save the window
parameters listed in some variable (window-state-saved-parameters?).
Adding some of (4) would be a good additional refinement.

Actually, it might even be good to filter which params to keep not just
when saving but already when constructing the window-state object (some
params may simply not belong in a window-state object because restoring
them would make no sense).  After all the window-configurations don't
save&restore window parameters.


        Stefan

bug#10348: 24.0.92; Save and load window states

[martin rudalics]

 >> (1) Do not save the `clone-of' parameter.  It's not yet useful anyway.
 >>     This will not solve the more general problem mentioned above.
 >
 > As mentioned, it's not a really convincing solution.

It would allow us to silently ignore this problem until 24.2.  And it
would obviously allow Michael to go on with his work.  His feedback
would be overly welcome here.

 >> (3) Save only parameters whose value have a read syntax.  This can be
 >>     done either in `window-state-get' or in `my-save-frame'.
 >
 > This can make the save&restore work and fail in somewhat
 > unpredictable ways.  Too magical.

IIUC this is what desktop does.  The problem is rather that we would
have to distinguish between values needed for intra-session purposes and
those that make sense for inter-session purposes too.

 >> (4) Convert parameter values to something with a read syntax.  Basically
 >>     this is what we already do with buffers (using the name of the
 >>     buffer instead of the buffer object) and can be easily done with
 >>     windows (save the window number instead of the window object).
 >
 > This would be a good change, especially if by "window number" you mean
 > a number meaningful in an output file rather than only in the current
 > session (see Juri's example)

... exactly (and that won't be easy since `window-state-put' could be
called at any time in a new session and not only before the first window
is created in that session).

 > but it doesn't fix all cases.

I'm afraid so.

 >> (5) Make functions like `my-load-frame' aware that components of saved
 >>     window states might not have a read syntax and have them take the
 >>     appropriate action.
 >
 > This is like (3) except the magic is done elsewhere.

Yes.  Just that (3) seems better.

 >> Unless you have a better suggestion I'll apply (1) for Emacs 24.1 and
 >> try to propose a combination of (3) and (4) for later releases.
 >
 > I think the best course of action is to only save the window
 > parameters listed in some variable (window-state-saved-parameters?).

You mean that anyone who misuses that variable (by including, for
example, a parameter that actually stores a window object as value)
would be on her own?  Doesn't look so attractive to me since the effect
will only be seen in a new session, some time after the problematic save
happened.

 > Adding some of (4) would be a good additional refinement.

If it can be reasonably done.

 > Actually, it might even be good to filter which params to keep not just
 > when saving but already when constructing the window-state object (some
 > params may simply not belong in a window-state object because restoring
 > them would make no sense).

Agreed.

 > After all the window-configurations don't
 > save&restore window parameters.

Currently they do (unless you modify them destructively).  Otherwise,
side windows and atomic windows won't work.

martin

bug#10348: 24.0.92; Save and load window states

[Michael Bach]

martin rudalics <rudalics@gmx.at> writes:

>>> (1) Do not save the `clone-of' parameter.  It's not yet useful anyway.
>>>     This will not solve the more general problem mentioned above.
>>
>> As mentioned, it's not a really convincing solution.
>
> It would allow us to silently ignore this problem until 24.2.  And it
> would obviously allow Michael to go on with his work.  His feedback
> would be overly welcome here.
>

As far as I am concerned, the issue is resolved thanks to Martin's
prompt and competent answers on the emacs help list.  For me, this bug
can be marked as fixed.

Michael

bug#10348: 24.0.92; Save and load window states

[Juri Linkov]

>>> (3) Save only parameters whose value have a read syntax.  This can be
>>>     done either in `window-state-get' or in `my-save-frame'.
>>
>> This can make the save&restore work and fail in somewhat
>> unpredictable ways.  Too magical.
>
> IIUC this is what desktop does.  The problem is rather that we would
> have to distinguish between values needed for intra-session purposes and
> those that make sense for inter-session purposes too.

Actually there exists already a parameter that distinguishes between values
needed for intra-session purposes and needed for inter-session purposes.
It is the argument `markers' of the function `window-state-get'.  When non-nil,
it returns internal values meaningful only in the current session.  When nil,
it returns integer values safe to save and read in another session.
This argument could be renamed to a more general name and used for
other values besides markers.  Then a caller of `window-state-get'
could decide whether its return value is intended for the same session
or for intra-session purposes.

bug#10348: 24.0.92; Save and load window states

[martin rudalics]

 > Actually there exists already a parameter that distinguishes between values
 > needed for intra-session purposes and needed for inter-session purposes.
 > It is the argument `markers' of the function `window-state-get'.  When non-nil,
 > it returns internal values meaningful only in the current session.  When nil,
 > it returns integer values safe to save and read in another session.
 > This argument could be renamed to a more general name and used for
 > other values besides markers.  Then a caller of `window-state-get'
 > could decide whether its return value is intended for the same session
 > or for intra-session purposes.

So we could add the `window-state-saved-parameters' variable Stefan
proposed and add parameters mentioned there only if the (probably)
renamed MARKERS argument is t or nil (whatever default we want here).

martin

bug#10348: 24.0.92; Save and load window states

[Juri Linkov]

> So we could add the `window-state-saved-parameters' variable Stefan
> proposed and add parameters mentioned there only if the (probably)
> renamed MARKERS argument is t or nil (whatever default we want here).

And (4) converting parameter values to something with a read syntax
looks promising as well.  We could reuse `desktop-value-to-string'
and additionally serialize window ids as numbers to handle cases like
when someone does (set-window-dedicated-p nil (selected-window))

bug#10348: 24.0.92; Save and load window states

[martin rudalics]

 > And (4) converting parameter values to something with a read syntax
 > looks promising as well.  We could reuse `desktop-value-to-string'
 > and additionally serialize window ids as numbers to handle cases like
 > when someone does (set-window-dedicated-p nil (selected-window))

Just that window numbers from a previous session won't be necessarily
meaningful in the present session.  So we either have to make such
window numbers very complex to rule out any misinterpretations or allow
only references to windows of the saved frame.

martin

bug#10348: 24.0.92; Save and load window states

[Stefan Monnier]

>>> (1) Do not save the `clone-of' parameter.  It's not yet useful anyway.
>>> This will not solve the more general problem mentioned above.
>> As mentioned, it's not a really convincing solution.
> It would allow us to silently ignore this problem until 24.2.  And it
> would obviously allow Michael to go on with his work.  His feedback
> would be overly welcome here.

No, it would address this particular bug-report, but similar problems
may reappear at any time.

> IIUC this is what desktop does.  The problem is rather that we would
> have to distinguish between values needed for intra-session purposes and
> those that make sense for inter-session purposes too.

I'm not sure distinguishing the two is needed (especially for
window-state-*).

>>> Unless you have a better suggestion I'll apply (1) for Emacs 24.1 and
>>> try to propose a combination of (3) and (4) for later releases.
>> I think the best course of action is to only save the window
>> parameters listed in some variable (window-state-saved-parameters?).
> You mean that anyone who misuses that variable (by including, for
> example, a parameter that actually stores a window object as value)
> would be on her own?

I don't see any harm in it.

> Doesn't look so attractive to me since the effect will only be seen in
> a new session, some time after the problematic save happened.

Not if we make this variable specify which parameters to include in
window-states, rather than only which parameters to write to a file.
Or maybe I don't understand the problem you're referring to.

>> Actually, it might even be good to filter which params to keep not just
>> when saving but already when constructing the window-state object (some
>> params may simply not belong in a window-state object because restoring
>> them would make no sense).
> Agreed.

>> After all the window-configurations don't save&restore
>> window parameters.
> Currently they do (unless you modify them destructively).  Otherwise,
> side windows and atomic windows won't work.

Oh, I see that's another change in Emacs-24.  It's actually problematic
because set-window-parameter does operate destructively, so it makes the
semantics rather irregular.


        Stefan

bug#10348: 24.0.92; Save and load window states

[martin rudalics]

 > No, it would address this particular bug-report, but similar problems
 > may reappear at any time.

Yes.  Someone could do (set-window-dedicated-p nil (selected-window)).

 >> IIUC this is what desktop does.  The problem is rather that we would
 >> have to distinguish between values needed for intra-session purposes and
 >> those that make sense for inter-session purposes too.
 >
 > I'm not sure distinguishing the two is needed (especially for
 > window-state-*).

So your proposed `window-state-saved-parameters' would never save and
restore a thing like the "clone-of" parameter?

 >> You mean that anyone who misuses that variable (by including, for
 >> example, a parameter that actually stores a window object as value)
 >> would be on her own?
 >
 > I don't see any harm in it.

Any application setting a window parameter to some non-standard value
would be held responsible for this.  Fine with me, but ...

 >> Doesn't look so attractive to me since the effect will only be seen in
 >> a new session, some time after the problematic save happened.
 >
 > Not if we make this variable specify which parameters to include in
 > window-states, rather than only which parameters to write to a file.
 > Or maybe I don't understand the problem you're referring to.

The window-state-* functions are primarily intended for inter-session
use.  So if we can save a bad value, the bug will be usually detected
when it's too late.

 >>> After all the window-configurations don't save&restore
 >>> window parameters.
 >> Currently they do (unless you modify them destructively).  Otherwise,
 >> side windows and atomic windows won't work.
 >
 > Oh, I see that's another change in Emacs-24.  It's actually problematic
 > because set-window-parameter does operate destructively,

`set-window-parameter' is harmless.  The problem occurs only if you
modify a window parameter's value destructively.

 > so it makes the
 > semantics rather irregular.

It's precisely the same as for the dedicated status of a window.

martin

bug#10348: 24.0.92; Save and load window states

[Stefan Monnier]

>> No, it would address this particular bug-report, but similar problems
>> may reappear at any time.
> Yes.  Someone could do (set-window-dedicated-p nil (selected-window)).

Yup.

>>> IIUC this is what desktop does.  The problem is rather that we would
>>> have to distinguish between values needed for intra-session purposes and
>>> those that make sense for inter-session purposes too.
>> I'm not sure distinguishing the two is needed (especially for
>> window-state-*).
> So your proposed `window-state-saved-parameters' would never save and
> restore a thing like the "clone-of" parameter?

Not quite "never", but at least not before we manage to serialize its value.

>>> You mean that anyone who misuses that variable (by including, for
>>> example, a parameter that actually stores a window object as value)
>>> would be on her own?
>> I don't see any harm in it.
> Any application setting a window parameter to some non-standard value
> would be held responsible for this.

That's right.  We should probably try to make the code a bit more robust
so that the "invalid read syntax" error gets turned into a warning.

>> Not if we make this variable specify which parameters to include in
>> window-states, rather than only which parameters to write to a file.
>> Or maybe I don't understand the problem you're referring to.
> The window-state-* functions are primarily intended for inter-session
> use.  So if we can save a bad value, the bug will be usually detected
> when it's too late.

I can't see any scenario where such errors could really be detected earlier.

>>>> After all the window-configurations don't save&restore
>>>> window parameters.
>>> Currently they do (unless you modify them destructively).  Otherwise,
>>> side windows and atomic windows won't work.
>> Oh, I see that's another change in Emacs-24.  It's actually problematic
>> because set-window-parameter does operate destructively,
> `set-window-parameter' is harmless.  The problem occurs only if you
> modify a window parameter's value destructively.

I must be missing something: set-window-parameter does "modify a window
parameter's value destructively".

>> so it makes the semantics rather irregular.
> It's precisely the same as for the dedicated status of a window.

Is it?
The irregularity I'm referring to, is that set-window-configuration will
remove parameters that were added since the save, but will not undo the
changes to the parameters that were modified since the save.


        Stefan

bug#10348: 24.0.92; Save and load window states

[martin rudalics]

 > I must be missing something: set-window-parameter does "modify a window
 > parameter's value destructively".
 >
 >>> so it makes the semantics rather irregular.
 >> It's precisely the same as for the dedicated status of a window.
 >
 > Is it?
 > The irregularity I'm referring to, is that set-window-configuration will
 > remove parameters that were added since the save, but will not undo the
 > changes to the parameters that were modified since the save.

You're right.  This makes window parameters useless for applications
where a window excursion can temporarily store some other value for that
parameter.  In particular, side windows can be broken very easily.

So we'd either have to copy the parameter list when creating a window
configuration, not use `setcdr' in `set-window-parameter', or make a new
slot for parameters that must not be modified destructively.  Neither
solution seems attractive to me.

martin

bug#10348: 24.0.92; Save and load window states

[Juri Linkov]

> So we'd either have to copy the parameter list when creating a window
> configuration, not use `setcdr' in `set-window-parameter', or make a new
> slot for parameters that must not be modified destructively.  Neither
> solution seems attractive to me.

Or to implement window-local variables like buffer-local variables.

bug#10348: 24.0.92; Save and load window states

[martin rudalics]

 > Or to implement window-local variables like buffer-local variables.

You mean in the sense of `desktop-buffer-locals'?

martin

bug#10348: 24.0.92; Save and load window states

[Stefan Monnier]

> So we'd either have to copy the parameter list when creating a window
> configuration, not use `setcdr' in `set-window-parameter', or make a new
> slot for parameters that must not be modified destructively.  Neither
> solution seems attractive to me.

Copying the alist seems perfectly fine to me.  This said, while we're
copying, we may as well filter at the same time: Emacs-23 did not
preserve parameters, so rather than preserving them all, we could make
Emacs-24 preserve only those params mentioned in a new var
`window-configuration-saved-parameters'.  For all I know, this new var
might even be shared with `window-state-saved-parameters'.


        Stefan

bug#10348: 24.0.92; Save and load window states

[martin rudalics]

 > Copying the alist seems perfectly fine to me.  This said, while we're
 > copying, we may as well filter at the same time: Emacs-23 did not
 > preserve parameters, so rather than preserving them all, we could make
 > Emacs-24 preserve only those params mentioned in a new var
 > `window-configuration-saved-parameters'.  For all I know, this new var
 > might even be shared with `window-state-saved-parameters'.

Suppose a window has a parameter which is not listed by that variable.
Shall `set-window-configuration' (implicitly) remove that parameter from
that window's parameters or keep it with its last value?

martin

bug#10348: 24.0.92; Save and load window states

[martin rudalics]

Looking into this I noticed the following: There's already a variable
`window-state-ignored-parameters'.  But it's broken since
`window-state-get-1' doesn't copy the parameter (so it behaves just like
`current-window-configuration') and it doesn't affect the `clone-of'
parameter.  So I'm afraid that we might need two variables say
`window-state-saved-parameters' and `window-state-ignored-parameters'.
The former would explicitly name the parameters that have to be
preserved accross window configuration changes.  The latter would be
responsible for not writing out parameters to disk.

The semantics of `window-state-saved-parameters' across a
`save-window-excursion' would then be as follows:

(1) If a parameter is a member of `window-state-saved-parameters'
     `current-window-configuration' makes a copy of its value in the
     window_parameters slot of saved_window.

(2) For each window, `set-window-configuration' clears out any non-nil
     value of a parameter in `window-state-saved-parameters'.  Thereafter
     it does a `set-window-parameter' for all entries it finds in the
     window_parameters slot of that window's saved_window entry.

This approach is inconsistent if `window-state-saved-parameters' changes
within the body of the `save-window-excursion'.

martin

bug#10348: 24.0.92; Save and load window states

[Stefan Monnier]

> The former would explicitly name the parameters that have to be
> preserved accross window configuration changes.  The latter would be
> responsible for not writing out parameters to disk.

It seems that we indeed need to distinguish window-states for
inter-session use and for intra-session use (e.g. via the `markers'
argument).

And of course the parameters preserved intra-session is a superset of
the parameters preserved inter-sessions.

Using window-state-ignored-parameters to specify the difference between
the two sets seems OK.

> This approach is inconsistent if `window-state-saved-parameters' changes
> within the body of the `save-window-excursion'.

Indeed, it's a bit ugly.  An alternative would be to ignore
window-state-saved-parameters (and window-state-ignored-parameters)
upon restore.  Instead, we'd save the parameters in a list where each
element is either (PARM . VAL) or just PARM where the second form
indicates that PARM was not set and should hence be unset upon restore.


        Stefan

bug#10348: 24.0.92; Save and load window states

[martin rudalics]

 > And of course the parameters preserved intra-session is a superset of
 > the parameters preserved inter-sessions.

I'm not so sure.  Maybe a parameter is useful intra-session but not
readable from disk.

 > Using window-state-ignored-parameters to specify the difference between
 > the two sets seems OK.

You mean that any value present in `window-state-ignored-parameters'
would have to be a member of the `window-persistent-parameters' I used
in my patch?  I'd rather not care about
`window-state-ignored-parameters' in `current-window-configuration' or
`set-window-configuration'.

(BTW, I use `window-persistent-parameters' instead of
`window-state-saved-parameters' because they apply to both,
`current-window-configuration` and `window-state-get'.)

 > An alternative would be to ignore
 > window-state-saved-parameters (and window-state-ignored-parameters)

So far, I didn't care about `window-state-ignored-parameters' when
restoring a state in `window-state-put'.

 > upon restore.  Instead, we'd save the parameters in a list where each
 > element is either (PARM . VAL) or just PARM where the second form
 > indicates that PARM was not set and should hence be unset upon restore.

Fine with me.  Obviously, this makes saved states a bit larger.

martin

bug#10348: 24.0.92; Save and load window states

[Stefan Monnier]

>> And of course the parameters preserved intra-session is a superset of
>> the parameters preserved inter-sessions.
> I'm not so sure.  Maybe a parameter is useful intra-session but not
> readable from disk.

I don't understand: you first seem to say you disagree with me, but then
what you say afterwards seems to agree with me.

>> Using window-state-ignored-parameters to specify the difference between
>> the two sets seems OK.
> You mean that any value present in `window-state-ignored-parameters'
> would have to be a member of the `window-persistent-parameters' I used
> in my patch?

Not necessarily, but an element in window-state-ignored-parameters which
is not in window-persistent-parameters would have no effect.

> I'd rather not care about `window-state-ignored-parameters' in
> `current-window-configuration' or `set-window-configuration'.

That's OK, window-configurations are intra-session objects anyway, so if
window-state-ignored-parameters specifies the difference between the two
sets, it indeed can be ignored by  `current-window-configuration' and
`set-window-configuration'.

> (BTW, I use `window-persistent-parameters' instead of
> `window-state-saved-parameters' because they apply to both,
> `current-window-configuration` and `window-state-get'.)

Yes, the name sounds fine.

>> An alternative would be to ignore window-state-saved-parameters (and
>> window-state-ignored-parameters)
> So far, I didn't care about `window-state-ignored-parameters' when
> restoring a state in `window-state-put'.

Fine.

>> upon restore.  Instead, we'd save the parameters in a list where each
>> element is either (PARM . VAL) or just PARM where the second form
>> indicates that PARM was not set and should hence be unset upon restore.
> Fine with me.  Obviously, this makes saved states a bit larger.

Indeed, but otherwise, as you pointed out, it makes the semantics rather
tricky if window-persistent-parameters is changed between the save and
the restore (which is something that is very likely to happen sometimes
since the restore may happen years after the save).


        Stefan

bug#10348: 24.0.92; Save and load window states

[martin rudalics]

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

 > I don't understand: you first seem to say you disagree with me, but then
 > what you say afterwards seems to agree with me.

Indeed.

 > Indeed, but otherwise, as you pointed out, it makes the semantics rather
 > tricky if window-persistent-parameters is changed between the save and
 > the restore (which is something that is very likely to happen sometimes
 > since the restore may happen years after the save).

I resolved the semantics by saving always all parameters unless I do
`window-state-get' with IGNORE non-nil and the parameter is in
`window-state-ignored-parameters'.  When restoring parameters via
`set-window-configuration'/`window-state-put', I overwrite/install a
value only if the parameter is in `window-persistent-parameters'.

martin

[-- Attachment #2: window-parameters.diff --]
[-- Type: text/plain, Size: 11588 bytes --]

=== modified file 'doc/lispref/windows.texi'
--- doc/lispref/windows.texi	2011-12-13 13:37:48 +0000
+++ doc/lispref/windows.texi	2011-12-29 10:34:38 +0000
@@ -3104,7 +3104,7 @@
 @defun current-window-configuration &optional frame
 This function returns a new object representing @var{frame}'s current
 window configuration.  The default for @var{frame} is the selected
-frame.
+frame.  This function copies the value of all window parameters.
 @end defun
 
 @defun set-window-configuration configuration
@@ -3121,6 +3121,9 @@
 know how to tell whether the new configuration actually differs from the
 old one.
 
+This function restores the values of all window parameters listed by
+@code{window-persistent-parameters}, see below.
+
 If the frame which @var{configuration} was saved from is dead, all this
 function does is restore the three variables @code{window-min-height},
 @code{window-min-width} and @code{minibuffer-scroll-window}. In this
@@ -3140,6 +3143,18 @@
 @end example
 @end defun
 
+@defvar window-persistent-parameters
+This variable lists all window parameters that are restored by
+@code{set-window-configuration}, see above.  This means that the value
+of any parameter listed by this variable and changed within the body of
+@code{save-window-excursion} is restored to its previous value when the
+window excursion exits.  Parameters not listed by this variable are left
+alone when the window excursion terminates.
+
+Parameters not listed by this variable are effectively not installed by
+the function @code{window-state-put}, see below.
+@end defvar
+
 @defspec save-window-excursion forms@dots{}
 This special form records the window configuration, executes @var{forms}
 in sequence, then restores the earlier window configuration.  The window
@@ -3209,18 +3224,25 @@
 configuration on disk and read it back in another Emacs session the
 following two functions can be used.
 
-@defun window-state-get &optional window markers
+@defun window-state-get &optional window ignore
 This function returns the state of @var{window} as a Lisp object.  The
 argument @var{window} can be any window and defaults to the root window
 of the selected frame.
 
-The optional argument @var{markers} non-@code{nil} means to use markers
-for sampling positions like @code{window-point} or @code{window-start}.
-This argument should be non-@code{nil} only if the value is used for
-putting the state back in the same session since markers slow down
-processing.
+If the optional argument @var{ignore} is non-@code{nil}, this means to
+not use markers for sampling positions like @code{window-point} or
+@code{window-start} and to not save values of parameters in the list
+@code{window-state-ignored-parameters}, see below.  This argument should
+be non-@code{nil} when the state shall be written on disk and read back
+in another session.
 @end defun
 
+@defvar window-state-ignored-parameters
+This variable lists all parameters whose value is not recorded by the
+function @code{window-state-get} when its @var{ignore} argument is
+non-@code{nil}, see above.
+@end defvar
+
 The value returned by @code{window-state-get} can be converted by using
 one of the functions defined by Desktop Save Mode (@pxref{Desktop Save
 Mode}) to an object that can be written to a file.  Such objects can be
@@ -3239,6 +3261,10 @@
 minimum window sizes and fixed size restrictions.  If @var{ignore}
 equals @code{safe}, this means windows can get as small as one line
 and/or two columns.
+
+This function installs the values of all window parameters listed by
+@code{window-persistent-parameters}, see above, provided their values
+are stored in @var{state}.
 @end defun
 
 

=== modified file 'lisp/window.el'
--- lisp/window.el	2011-12-24 19:16:53 +0000
+++ lisp/window.el	2011-12-29 10:11:05 +0000
@@ -3568,10 +3568,12 @@
     ))
 
 ;;; Window states, how to get them and how to put them in a window.
-(defvar window-state-ignored-parameters '(quit-restore)
-  "List of window parameters ignored by `window-state-get'.")
+(defvar window-state-ignored-parameters '(quit-restore clone-of)
+  "Window parameters ignored by `window-state-get'.
+Parameters in this list are not saved by `window-state-get' when
+its IGNORE argument is non-nil.")
 
-(defun window--state-get-1 (window &optional markers)
+(defun window--state-get-1 (window &optional ignore)
   "Helper function for `window-state-get'."
   (let* ((type
 	  (cond
@@ -3590,11 +3592,15 @@
             (combination-limit . ,(window-combination-limit window))
             ,@(let (list)
                 (dolist (parameter (window-parameters window))
-                  (unless (memq (car parameter)
-                                window-state-ignored-parameters)
-                    (setq list (cons parameter list))))
-                (unless (window-parameter window 'clone-of)
-                  ;; Make a clone-of parameter.
+		  ;; When IGNORE is non-nil, add a parameter if and only
+		  ;; if it is not in `window-state-ignored-parameters'.
+		  (unless (and ignore
+			       (memq (car parameter)
+				     window-state-ignored-parameters))
+                    (setq list (cons (cons (car parameter) (cdr parameter))
+				     list))))
+                (unless (or ignore (window-parameter window 'clone-of))
+                  ;; Make `clone-of' parameter unless IGNORE is non-nil.
                   (setq list (cons (cons 'clone-of window) list)))
                 (when list
                   `((parameters . ,list))))
@@ -3616,30 +3622,32 @@
                        (scroll-bars . ,(window-scroll-bars window))
                        (vscroll . ,(window-vscroll window))
                        (dedicated . ,(window-dedicated-p window))
-                       (point . ,(if markers (copy-marker point) point))
-                       (start . ,(if markers (copy-marker start) start))
+                       (point . ,(if ignore point (copy-marker point)))
+                       (start . ,(if ignore start (copy-marker start)))
                        ,@(when mark
-                           `((mark . ,(if markers
-                                          (copy-marker mark) mark)))))))))))
+                           `((mark . ,(if ignore
+                                          mark (copy-marker mark))))))))))))
 	 (tail
 	  (when (memq type '(vc hc))
 	    (let (list)
 	      (setq window (window-child window))
 	      (while window
-		(setq list (cons (window--state-get-1 window markers) list))
+		(setq list (cons (window--state-get-1 window ignore) list))
 		(setq window (window-right window)))
 	      (nreverse list)))))
     (append head tail)))
 
-(defun window-state-get (&optional window markers)
+(defun window-state-get (&optional window ignore)
   "Return state of WINDOW as a Lisp object.
 WINDOW can be any window and defaults to the root window of the
 selected frame.
 
-Optional argument MARKERS non-nil means use markers for sampling
-positions like `window-point' or `window-start'.  MARKERS should
-be non-nil only if the value is used for putting the state back
-in the same session (note that markers slow down processing).
+Optional argument IGNORE non-nil means do not use markers for
+sampling positions like `window-point' or `window-start' and do
+not record ignored window parameters as specified by
+`window-state-ignored-parameters'.  IGNORE should be non-nil when
+the return value shall be written to a file and read back in
+another session.
 
 The return value can be used as argument for `window-state-put'
 to put the state recorded here into an arbitrary window.  The
@@ -3665,7 +3673,7 @@
      ;; These are probably not needed.
      ,@(when (window-size-fixed-p window) `((fixed-height . t)))
      ,@(when (window-size-fixed-p window t) `((fixed-width . t))))
-   (window--state-get-1 window markers)))
+   (window--state-get-1 window ignore)))
 
 (defvar window-state-put-list nil
   "Helper variable for `window-state-put'.")
@@ -3744,10 +3752,15 @@
 	  (state (cdr (assq 'buffer item))))
       (when combination-limit
 	(set-window-combination-limit window combination-limit))
-      ;; Process parameters.
+      ;; nil out values of parameters in `window-persistent-parameters'.
+      (dolist (parameter (window-parameters window))
+	(when (memq (car parameter) window-persistent-parameters)
+	  (set-window-parameter window (car parameter) nil)))
+      ;; Assign persistent window parameters.
       (when parameters
 	(dolist (parameter parameters)
-	  (set-window-parameter window (car parameter) (cdr parameter))))
+	  (when (memq (car parameter) window-persistent-parameters)
+	    (set-window-parameter window (car parameter) (cdr parameter)))))
       ;; Process buffer related state.
       (when state
 	;; We don't want to raise an error here so we create a buffer if

=== modified file 'src/window.c'
--- src/window.c	2011-12-13 13:58:20 +0000
+++ src/window.c	2011-12-29 11:21:42 +0000
@@ -5349,6 +5349,7 @@
   (Lisp_Object configuration)
 {
   register struct save_window_data *data;
+  register Lisp_Object tem, car;
   struct Lisp_Vector *saved_windows;
   Lisp_Object new_current_buffer;
   Lisp_Object frame;
@@ -5543,7 +5544,26 @@
 	  w->vertical_scroll_bar_type = p->vertical_scroll_bar_type;
 	  w->dedicated = p->dedicated;
 	  w->combination_limit = p->combination_limit;
-	  w->window_parameters = p->window_parameters;
+	  /* nil out values of persistent window parameters.  */
+	  if (!NILP (w->window_parameters))
+	    for (tem = w->window_parameters; CONSP (tem); tem = XCDR (tem))
+	      {
+		car = XCAR (tem);
+		if (CONSP (car)
+		    && !NILP (Fmemq (XCAR (car), Vwindow_persistent_parameters)))
+		  Fsetcdr (car, Qnil);
+	      }
+
+	  /* Restore persistent window parameters.  */
+	  if (!NILP (p->window_parameters))
+	    for (tem = p->window_parameters; CONSP (tem); tem = XCDR (tem))
+	      {
+		car = XCAR (tem);
+		if (CONSP (car)
+		    && !NILP (Fmemq (XCAR (car), Vwindow_persistent_parameters)))
+		  Fset_window_parameter (window, XCAR (car), XCDR (car));
+	      }
+
 	  XSETFASTINT (w->last_modified, 0);
 	  XSETFASTINT (w->last_overlay_modified, 0);
 
@@ -5810,7 +5830,7 @@
 {
   register struct saved_window *p;
   register struct window *w;
-  register Lisp_Object tem;
+  register Lisp_Object tem, car;
 
   for (;!NILP (window); window = w->next)
     {
@@ -5838,7 +5858,11 @@
       p->vertical_scroll_bar_type = w->vertical_scroll_bar_type;
       p->dedicated = w->dedicated;
       p->combination_limit = w->combination_limit;
-      p->window_parameters = w->window_parameters;
+      /* Store copies of all window parameters.  When
+	 Fset_window_configuration later considers a parameter as
+	 persistent it will take it from the copy stored here.  */
+      p->window_parameters = Fcopy_alist (w->window_parameters);
+
       if (!NILP (w->buffer))
 	{
 	  /* Save w's value of point in the window configuration.
@@ -6542,6 +6566,15 @@
 function `set-window-combination-limit'.  */);
   Vwindow_combination_limit = Qnil;
 
+  DEFVAR_LISP ("window-persistent-parameters", Vwindow_persistent_parameters,
+	       doc: /* List of persistent window parameters.
+
+The parameters in this list are restored to their previous values by the
+functions `set-window-configuration' and `window-state-put'.  Any
+parameterts not listed here are left alone by `set-window-configuration'
+respectively not installed by `window-state-put'.  */);
+  Vwindow_persistent_parameters = Qnil;
+
   defsubr (&Sselected_window);
   defsubr (&Sminibuffer_window);
   defsubr (&Swindow_minibuffer_p);

bug#10348: 24.0.92; Save and load window states

[martin rudalics]

 > An alternative would be to ignore
 > window-state-saved-parameters (and window-state-ignored-parameters)
 > upon restore.  Instead, we'd save the parameters in a list where each
 > element is either (PARM . VAL) or just PARM where the second form
 > indicates that PARM was not set and should hence be unset upon restore.

I more or less installed this now.  Please have a look.

martin

bug#10348: 24.0.92; Save and load window states

[martin rudalics]

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

I wrote a tentative patch to handle this.  Please have a look.

Thanks, martin


[-- Attachment #2: window-parameters.diff --]
[-- Type: text/plain, Size: 11614 bytes --]

=== modified file 'doc/lispref/windows.texi'
--- doc/lispref/windows.texi	2011-12-13 13:37:48 +0000
+++ doc/lispref/windows.texi	2011-12-27 17:51:15 +0000
@@ -3104,9 +3104,24 @@
 @defun current-window-configuration &optional frame
 This function returns a new object representing @var{frame}'s current
 window configuration.  The default for @var{frame} is the selected
-frame.
+frame.  This function copies the value of all window parameters listed
+by @code{window-persistent-parameters}, see below.
 @end defun
 
+@defvar window-persistent-parameters
+This variable lists all window parameters that shall be saved by
+@code{current-window-configuration}, see above, and restored by
+@code{set-window-configuration}, see below.  This means that the value
+of any parameter listed by this variable and changed within the body of
+@code{save-window-excursion} is restored to its previous value when the
+window excursion exits.  Parameters not listed by this variable are left
+alone when the window excursion terminates.
+
+The parameters listed by this variable are treated in a similar manner
+by the functions @code{window-state-get} and @code{window-state-put},
+see below.
+@end defvar
+
 @defun set-window-configuration configuration
 This function restores the configuration of windows and buffers as
 specified by @var{configuration}, for the frame that @var{configuration}
@@ -3121,6 +3136,10 @@
 know how to tell whether the new configuration actually differs from the
 old one.
 
+This function restores the values of all window parameters listed by
+@code{window-persistent-parameters}, see above, to their values saved in
+@var{configuration}.
+
 If the frame which @var{configuration} was saved from is dead, all this
 function does is restore the three variables @code{window-min-height},
 @code{window-min-width} and @code{minibuffer-scroll-window}. In this
@@ -3209,18 +3228,28 @@
 configuration on disk and read it back in another Emacs session the
 following two functions can be used.
 
-@defun window-state-get &optional window markers
+@defun window-state-get &optional window ignore
 This function returns the state of @var{window} as a Lisp object.  The
 argument @var{window} can be any window and defaults to the root window
 of the selected frame.
 
-The optional argument @var{markers} non-@code{nil} means to use markers
-for sampling positions like @code{window-point} or @code{window-start}.
-This argument should be non-@code{nil} only if the value is used for
-putting the state back in the same session since markers slow down
-processing.
+If the optional argument @var{ignore} is non-@code{nil}, this means to
+not use markers for sampling positions like @code{window-point} or
+@code{window-start} and to not save values of parameters in the list
+@code{window-state-ignored-parameters}, see below.  This argument should
+be non-@code{nil} when the state shall be written on disk and read back
+in another session.
+
+This function copies the value of all window parameters listed by the
+variable @code{window-persistent-parameters}, see above.
 @end defun
 
+@defvar window-state-ignored-parameters
+This variable lists all parameters whose value must not be recorded by
+the function @code{window-state-get} when its @var{ignore} argument is
+non-@code{nil}, see above.
+@end defvar
+
 The value returned by @code{window-state-get} can be converted by using
 one of the functions defined by Desktop Save Mode (@pxref{Desktop Save
 Mode}) to an object that can be written to a file.  Such objects can be
@@ -3239,6 +3268,10 @@
 minimum window sizes and fixed size restrictions.  If @var{ignore}
 equals @code{safe}, this means windows can get as small as one line
 and/or two columns.
+
+This function restores the values of all window parameters listed by
+@code{window-persistent-parameters}, see above, to their values in
+@var{state}.
 @end defun
 
 

=== modified file 'lisp/window.el'
--- lisp/window.el	2011-12-24 19:16:53 +0000
+++ lisp/window.el	2011-12-27 16:36:57 +0000
@@ -3568,10 +3568,12 @@
     ))
 
 ;;; Window states, how to get them and how to put them in a window.
-(defvar window-state-ignored-parameters '(quit-restore)
-  "List of window parameters ignored by `window-state-get'.")
+(defvar window-state-ignored-parameters '(quit-restore clone-of)
+  "Window parameters ignored by `window-state-get'.
+Parameters in this list are not saved by `window-state-get' when
+its IGNORE argument is non-nil.")
 
-(defun window--state-get-1 (window &optional markers)
+(defun window--state-get-1 (window &optional ignore)
   "Helper function for `window-state-get'."
   (let* ((type
 	  (cond
@@ -3590,11 +3592,18 @@
             (combination-limit . ,(window-combination-limit window))
             ,@(let (list)
                 (dolist (parameter (window-parameters window))
-                  (unless (memq (car parameter)
-                                window-state-ignored-parameters)
-                    (setq list (cons parameter list))))
-                (unless (window-parameter window 'clone-of)
-                  ;; Make a clone-of parameter.
+		  ;; When IGNORE is nil, add a parameter only if it is
+		  ;; in `window-persistent-parameters'.  When IGNORE is
+		  ;; non-nil, add a parameter if and only if it is not
+		  ;; in `window-state-ignored-parameters'.
+		  (when (if ignore
+			    (not (memq (car parameter)
+				       window-state-ignored-parameters))
+			  (memq (car parameter) window-persistent-parameters))
+                    (setq list (cons (cons (car parameter) (cdr parameter))
+				     list))))
+                (unless (or ignore (window-parameter window 'clone-of))
+                  ;; Make `clone-of' parameter unless IGNORE is non-nil.
                   (setq list (cons (cons 'clone-of window) list)))
                 (when list
                   `((parameters . ,list))))
@@ -3616,30 +3625,32 @@
                        (scroll-bars . ,(window-scroll-bars window))
                        (vscroll . ,(window-vscroll window))
                        (dedicated . ,(window-dedicated-p window))
-                       (point . ,(if markers (copy-marker point) point))
-                       (start . ,(if markers (copy-marker start) start))
+                       (point . ,(if ignore point (copy-marker point)))
+                       (start . ,(if ignore start (copy-marker start)))
                        ,@(when mark
-                           `((mark . ,(if markers
-                                          (copy-marker mark) mark)))))))))))
+                           `((mark . ,(if ignore
+                                          mark (copy-marker mark))))))))))))
 	 (tail
 	  (when (memq type '(vc hc))
 	    (let (list)
 	      (setq window (window-child window))
 	      (while window
-		(setq list (cons (window--state-get-1 window markers) list))
+		(setq list (cons (window--state-get-1 window ignore) list))
 		(setq window (window-right window)))
 	      (nreverse list)))))
     (append head tail)))
 
-(defun window-state-get (&optional window markers)
+(defun window-state-get (&optional window ignore)
   "Return state of WINDOW as a Lisp object.
 WINDOW can be any window and defaults to the root window of the
 selected frame.
 
-Optional argument MARKERS non-nil means use markers for sampling
-positions like `window-point' or `window-start'.  MARKERS should
-be non-nil only if the value is used for putting the state back
-in the same session (note that markers slow down processing).
+Optional argument IGNORE non-nil means do not use markers for
+sampling positions like `window-point' or `window-start' and do
+not record ignored window parameters as specified by
+`window-state-ignored-parameters'.  IGNORE should be non-nil when
+the return value shall be written to a file and read back in
+another session.
 
 The return value can be used as argument for `window-state-put'
 to put the state recorded here into an arbitrary window.  The
@@ -3665,7 +3676,7 @@
      ;; These are probably not needed.
      ,@(when (window-size-fixed-p window) `((fixed-height . t)))
      ,@(when (window-size-fixed-p window t) `((fixed-width . t))))
-   (window--state-get-1 window markers)))
+   (window--state-get-1 window ignore)))
 
 (defvar window-state-put-list nil
   "Helper variable for `window-state-put'.")
@@ -3744,6 +3755,10 @@
 	  (state (cdr (assq 'buffer item))))
       (when combination-limit
 	(set-window-combination-limit window combination-limit))
+      ;; nil out values of parameters in `window-persistent-parameters'.
+      (dolist (parameter (window-parameters window))
+	(when (memq (car parameter) window-persistent-parameters)
+	  (set-window-parameter window (car parameter) nil)))
       ;; Process parameters.
       (when parameters
 	(dolist (parameter parameters)

=== modified file 'src/window.c'
--- src/window.c	2011-12-13 13:58:20 +0000
+++ src/window.c	2011-12-27 09:37:03 +0000
@@ -5349,6 +5349,7 @@
   (Lisp_Object configuration)
 {
   register struct save_window_data *data;
+  register Lisp_Object tem, car;
   struct Lisp_Vector *saved_windows;
   Lisp_Object new_current_buffer;
   Lisp_Object frame;
@@ -5543,7 +5544,25 @@
 	  w->vertical_scroll_bar_type = p->vertical_scroll_bar_type;
 	  w->dedicated = p->dedicated;
 	  w->combination_limit = p->combination_limit;
-	  w->window_parameters = p->window_parameters;
+	  /* nil out values of persistent window parameters.  */
+	  if (!NILP (w->window_parameters))
+	    for (tem = w->window_parameters; CONSP (tem); tem = XCDR (tem))
+	      {
+		car = XCAR (tem);
+		if (CONSP (car)
+		    && !NILP (Fmemq (XCAR (car), Vwindow_persistent_parameters)))
+		  Fsetcdr (car, Qnil);
+	      }
+
+	  /* Restore persistent window parameters.  */
+	  if (!NILP (p->window_parameters))
+	    for (tem = p->window_parameters; CONSP (tem); tem = XCDR (tem))
+	      {
+		car = XCAR (tem);
+		if (CONSP (car))
+		  Fset_window_parameter (window, XCAR (car), XCDR (car));
+	      }
+
 	  XSETFASTINT (w->last_modified, 0);
 	  XSETFASTINT (w->last_overlay_modified, 0);
 
@@ -5810,7 +5829,7 @@
 {
   register struct saved_window *p;
   register struct window *w;
-  register Lisp_Object tem;
+  register Lisp_Object tem, car;
 
   for (;!NILP (window); window = w->next)
     {
@@ -5838,7 +5857,18 @@
       p->vertical_scroll_bar_type = w->vertical_scroll_bar_type;
       p->dedicated = w->dedicated;
       p->combination_limit = w->combination_limit;
-      p->window_parameters = w->window_parameters;
+      p->window_parameters = Qnil;
+      /* Store copies of persistent window parameters.  */
+      if (!NILP (w->window_parameters))
+	for (tem = w->window_parameters; CONSP (tem); tem = XCDR (tem))
+	  {
+	    car = XCAR (tem);
+	    if (CONSP (car)
+		&& !NILP (Fmemq (XCAR (car), Vwindow_persistent_parameters)))
+	      p->window_parameters = Fcons (Fcons (XCAR (car), XCDR (car)),
+					    p->window_parameters);
+	  }
+
       if (!NILP (w->buffer))
 	{
 	  /* Save w's value of point in the window configuration.
@@ -6542,6 +6572,13 @@
 function `set-window-combination-limit'.  */);
   Vwindow_combination_limit = Qnil;
 
+  DEFVAR_LISP ("window-persistent-parameters", Vwindow_persistent_parameters,
+	       doc: /* List of persistent window parameters.
+The parameters in this list are saved by `current-window-configuration'
+and `window-state-get' and restored by `set-window-configuration' and
+`window-state-put'.  */);
+  Vwindow_persistent_parameters = Qnil;
+
   defsubr (&Sselected_window);
   defsubr (&Sminibuffer_window);
   defsubr (&Swindow_minibuffer_p);

bug#10348: 24.0.92; Save and load window states

[Juri Linkov]

> Debugger entered--Lisp error: (invalid-read-syntax "#")

There was another error in `window--state-get-1':

(setq mark-even-if-inactive nil)

(window-state-get)

Debugger entered--Lisp error: (mark-inactive)
  signal(mark-inactive nil)
  mark()
  window--state-get-1(#<window 3 on *scratch*> nil)
  window-state-get()
  eval((window-state-get) nil)
  eval-last-sexp-1(nil)
  eval-last-sexp(nil)
  call-interactively(eval-last-sexp nil nil)

That's because `(mark)' should be used with the `t' arg as `(mark t)'.
I installed the fix.

bug#10348: 24.0.92; Save and load window states

[martin rudalics]

 > `window-state-put' as used within the following functions does not work.
 > Please see *Backtrace* below for error.  (See also post to
 > help-gnu-emacs@gnu.org with subject "Save and load window states")
 >
 > Steps to reproduce:
 > 1) Start via `emacs -Q'.
 > 2) evaluate the two functions:
 > (defun my-save-frame ()
 >   (interactive)
 >   (let ((buf (find-file-noselect "/tmp/emacs-layout")))
 >     (set-buffer buf)
 >     (erase-buffer)
 >     (print (window-state-get) buf)
 >     (save-buffer)
 >     (kill-buffer)))
 >
 > (defun my-load-frame ()
 >   (interactive)
 >   (let ((buf (find-file-noselect "/tmp/emacs-layout")))
 >     (set-buffer buf)
 >     (beginning-of-buffer)
 >     (window-state-put (read buf))
 >     (kill-buffer)))
 >
 > 3) Do a `M-x my-save-frame' and after that `M-x my-load-frame'
 >
 > Debugger entered--Lisp error: (invalid-read-syntax "#")
 >   read(#<buffer emacs-layout>)
 >   (window-state-put (read buf))
 >   (let ((buf (find-file-noselect "/tmp/emacs-layout"))) (set-buffer buf) (beginning-of-buffer) (window-state-put (read buf)) (save-buffer) (kill-buffer))
 >   my-load-frame()
 >   call-interactively(my-load-frame t nil)
 >   execute-extended-command(nil)
 >   call-interactively(execute-extended-command nil nil)

This problem should have been resolved with revision 106873 on trunk.

Thanks, martin