RE: [External] : Re: How to persist registers across sessions?

[Drew Adams]

> > > Can you in parallel with that good idea, give some clue how to
> > > obtain window configuration as lisp object?
> >
> > People already told you: current-window-configuration does that.
> 
> If I wish to get Lisp object of window configuration I get
> some result which does not give data:
> (current-window-configuration) ⇒ #<window-configuration>
> and no matter if I have 3 windows, I get same result:
> (current-window-configuration) ⇒ #<window-configuration>
> 
> I think this is function which should do that:
> 
>    The objects returned by ‘current-window-configuration’ die together
> with the Emacs process.  In order to store a window configuration on
> disk and read it back in another Emacs session, you can use the
> functions described next.  These functions are also useful to clone the
> state of a frame into an arbitrary live window
> (‘set-window-configuration’ effectively clones the windows of a frame
> into the root window of that very frame only).
> 
>  -- Function: window-state-get &optional window writable
>      This function returns the state of WINDOW as a Lisp object.  The
>      argument WINDOW must be a valid window and defaults to the root
>      window of the selected frame.
> 
>      If the optional argument WRITABLE is non-‘nil’, this means to not
>      use markers for sampling positions like ‘window-point’ or
>      ‘window-start’.  This argument should be non-‘nil’ when the state
>      will be written to disk and read back in another session.
> 
>      Together, the argument WRITABLE and the variable
>      ‘window-persistent-parameters’ specify which window parameters are
>      saved by this function.  *Note Window Parameters::.
> 
> So I try this way:
> 
> (prin1-to-string (window-state-get (get-buffer-window))) ⇒ "...
> (parameters (clone-of . #<window 2515 on mutt-protected-1001-4153-
> 16793396821956371330>)) (buffer #<buffer mutt-protected-1001-4153-
> 16793396821956371330> ... (point . #<marker at 1892 in...>) ..."
> 
> But I cannot read it back:
> 
> (read-from-string (prin1-to-string (window-state-get (get-buffer-
> window)))) as I get error:
> Debugger entered--Lisp error: (invalid-read-syntax "#")


FYI: from bug #14964, this message:

https://debbugs.gnu.org/cgi/bugreport.cgi?bug=14964

  We have `window-state-(get|put)', but I would also like
  to see Lisp-readable window configurations.  IOW, wrap
  with (window-configuration...) what `window-state-get'
  with non-nil WRITABLE arg returns.  E.g.:

  (window-configuration
    (((min-height . 4)
      (min-width . 10)
      (min-height-ignore . 2)
      (min-width-ignore . 5)
      (min-height-safe . 1)
      (min-width-safe . 2))
     leaf
     (last . t)
     (total-height . 63)
     (total-width . 112)
     (normal-height . 1.0)
     (normal-width . 1.0)
     (buffer "foobar.el"
             (selected . t)
             (hscroll . 0)
             (fringes 0 0 nil)
             (margins nil)
             (scroll-bars 21 3 t nil)
             (vscroll . 0)
             (dedicated)
             (point . 426354)
             (start . 424331))))

And from this message:

https://debbugs.gnu.org/cgi/bugreport.cgi?bug=14964#23

  The form of the result would be similar to the non Lisp-readable frame
  config: a list with `frame-configuration' as car, a nil FRAME as cadr
  (for example), an ALIST of the traditional or standard frame parameters
  (i.e., the same ones), and a readable version of the frame's window
  configuration.

  That would (if we think it is important to separate these) be followed
  by any additional frame parameters that are not recorded for the non
  Lisp-readable frame config.  Or alternatively, if it is not important to
  keep those separate (identifiable as such), then just include them in
  ALIST.  If all recorded frame parameters are in ALIST, then the only
  differences from a non-readable frame config are (a) a nil FRAME (or
  some other convention for FRAME) and (b) the fact that each component
  is readable.

  ... an optional parameter 'WRITABLE, for instance, similar to what
  Martin did for `window-state-get'.  (WRITABLE is actually READABLE,
  in my book, but either name is OK.)

  ... the `window-state-*' functions do not explicitly provide for
  readable window configurations.  Consider something like this, for
  example:

  (defun readable-window-config (window-configuration)
    "Return a Lisp-readable representation of WINDOW-CONFIGURATION.
  The form is (window-configuration FRAME-NAME . ROOT-WINDOW-STATE)."
    ;; Record the name of the frame and its root window state.
    (let ((winfr  (window-configuration-frame window-configuration)))
      `(window-configuration
        ,(frame-parameter winfr 'name)
        . ,(window-state-get (frame-root-window winfr) 'WRITABLE))))

  Just one possibility, as an illustration of what I mean.

  ... the point is to have a standard structure that code can use and
  manipulate.  That is already the case currently, with the exception
  that the structure components are not readable/writable.

  ... In sum, provide alternative, Lisp-readable representations of
  both frame configs and window configs, and update the functions
  that use/create such configs to also use/create the readable form
  (creating a readable config would be optional via an optional
  `WRITABLE parameter)....

  (defun readable-frame (frame)
    "Return a Lisp-readable representation of FRAME.
  Form is (frame . FRAME-PARAMETERS)."
      `(frame . ,(desktop--filter-frame-parms (frame-parameters frame) t)))

  Probably if we did that then we would want to let you specify the
  frame parameters to record via one or more parameters to the function
  rather than using `desktop--filter-frame-parms' inside the function body.

  And for a readable window also, we might want to have a (window...)
  structure (list), which would just involve putting a wrapper around
  what is already provided by `window-state-get' (with non-nil WRITABLE).

This message talks about "workgroups":

https://debbugs.gnu.org/cgi/bugreport.cgi?bug=14964#29

And there's a lot more food for thought in that bug thread.