How to restore the layout?

How to restore the layout?

[Angelo Graziosi]

When we set desktop-save-mode, we can restore all the buffers of 
previous session.. but what about the layout (windows, frames etc.)?

For example, suppose one is working with 4 windows (C-x 3 and then, in 
each window, C-x 2) of different size: one window with a .c buffer, two 
windows with .h buffers, and another with eshell.

It would be useful, the next morning one starts Emacs, not only to 
restore all the buffers of previous session but also all the windows 
(and their size/position) of the previous session..

Is this possible with current (trunk) Emacs?

I would expect that setting(*) desktop-save-mode *does* all this.. After 
all, those windows, frames etc. are what is the Emacs *desktop*...


Ciao,
  Angelo.


---
(*) Really, I would prefer that all this is enabled by default. Only the 
user that doesn't like this should disable it.

Re: How to restore the layout?

[Xue Fuqiao]

On Sat, Jun 22, 2013 at 9:45 PM, Angelo Graziosi
<angelo.graziosi@alice.it> wrote:
> When we set desktop-save-mode, we can restore all the buffers of previous
> session.. but what about the layout (windows, frames etc.)?

There're various related libraries.  See
http://www.emacswiki.org/emacs/SessionManagement

> I would expect that setting(*) desktop-save-mode *does* all this.. After
> all, those windows, frames etc. are what is the Emacs *desktop*...

+1

--
Best regards, Xue Fuqiao.
http://www.gnu.org/software/emacs/

Re: How to restore the layout?

[martin rudalics]

 > When we set desktop-save-mode, we can restore all the buffers of
 > previous session.. but what about the layout (windows, frames etc.)?
 >
 > For example, suppose one is working with 4 windows (C-x 3 and then, in
 > each window, C-x 2) of different size: one window with a .c buffer, two
 > windows with .h buffers, and another with eshell.
 >
 > It would be useful, the next morning one starts Emacs, not only to
 > restore all the buffers of previous session but also all the windows
 > (and their size/position) of the previous session..
 >
 > Is this possible with current (trunk) Emacs?

In Emacs 24.3 there are two functions `window-state-get' and
`window-state-put' which can be used to do that.  The only missing part
is to write an interface to these functions when saving and restoring
the desktop.  I don't know whether anybody has done that.

On trunk `window-state-get' was broken recently, see bug#14527.

martin

Re: How to restore the layout?

[Angelo Graziosi]

Il 23/06/2013 1.01, Xue Fuqiao ha scritto:
> On Sat, Jun 22, 2013 at 9:45 PM, Angelo Graziosi
> <angelo.graziosi@alice.it> wrote:
>> When we set desktop-save-mode, we can restore all the buffers of previous
>> session.. but what about the layout (windows, frames etc.)?
>
> There're various related libraries.  See
> http://www.emacswiki.org/emacs/SessionManagement


Thanks.

Anyway, I think the best way is when desktop-save-mode is enabled, it 
should save *all* the Emacs *desktop*

>> I would expect that setting(*) desktop-save-mode *does* all this.. After
>> all, those windows, frames etc. are what is the Emacs *desktop*...
>
> +1

+1

Ciao,
  Angelo.

Re: How to restore the layout?

[Angelo Graziosi]

Il 23/06/2013 10.26, martin rudalics ha scritto:
>  > When we set desktop-save-mode, we can restore all the buffers of
>  > previous session.. but what about the layout (windows, frames etc.)?
>  >
>  > For example, suppose one is working with 4 windows (C-x 3 and then, in
>  > each window, C-x 2) of different size: one window with a .c buffer, two
>  > windows with .h buffers, and another with eshell.
>  >
>  > It would be useful, the next morning one starts Emacs, not only to
>  > restore all the buffers of previous session but also all the windows
>  > (and their size/position) of the previous session..
>  >
>  > Is this possible with current (trunk) Emacs?
>
> In Emacs 24.3 there are two functions `window-state-get' and
> `window-state-put' which can be used to do that.  The only missing part
> is to write an interface to these functions when saving and restoring
> the desktop.  I don't know whether anybody has done that.

If I understand, at the moment, with those (working) functions, one 
should each time "save" and "restore" manually the *desktop*, instead 
adding the missing part, all this is done when the desktop-saving is 
enabled... I vote for the last solution. Working with emacs would be 
more comfortable..

>
> On trunk `window-state-get' was broken recently, see bug#14527.


:(

Ciao,
  Angelo.

Re: How to restore the layout?

[Juanma Barranquero]

On Sun, Jun 23, 2013 at 10:26 AM, martin rudalics <rudalics@gmx.at> wrote:

> On trunk `window-state-get' was broken recently, see bug#14527.

Perhaps it is time to send a ping to the bug thread, Cc: emacs-devel...

   J

Re: How to restore the layout?

[martin rudalics]

 > If I understand, at the moment, with those (working) functions, one
 > should each time "save" and "restore" manually the *desktop*, instead
 > adding the missing part, all this is done when the desktop-saving is
 > enabled... I vote for the last solution. Working with emacs would be
 > more comfortable..

When I wrote these functions I was told that writing the desktop front
end would be easy.  ISTR that someone started to write it but haven't
heard anything lately.  Maybe you could give it a try?

martin

Re: How to restore the layout?

[Juanma Barranquero]

On Mon, Jun 24, 2013 at 7:05 PM, martin rudalics <rudalics@gmx.at> wrote:

> When I wrote these functions I was told that writing the desktop front
> end would be easy.

BTW, the last paragraph of window-persistent-parameters' docstring
seems to have been caught mid-change:

  Parameters not saved by `current-window-configuration' or
  `window-state-get' are left alone by `set-window-configuration'
  respectively are not installed by `window-state-put'.

J

Re: How to restore the layout?

[Eli Zaretskii]

> From: Juanma Barranquero <lekktu@gmail.com>
> Date: Mon, 24 Jun 2013 19:23:58 +0200
> Cc: emacs <emacs-devel@gnu.org>, Angelo Graziosi <angelo.graziosi@alice.it>
> 
> BTW, the last paragraph of window-persistent-parameters' docstring
> seems to have been caught mid-change:
> 
>   Parameters not saved by `current-window-configuration' or
>   `window-state-get' are left alone by `set-window-configuration'
>   respectively are not installed by `window-state-put'.

No, it's just a style you are not used to.

Re: How to restore the layout?

[martin rudalics]

 > BTW, the last paragraph of window-persistent-parameters' docstring
 > seems to have been caught mid-change:
 >
 >   Parameters not saved by `current-window-configuration' or
 >   `window-state-get' are left alone by `set-window-configuration'
 >   respectively are not installed by `window-state-put'.

What I intended to say is that if a parameter was not saved then

- `set-window-configuration' leaves its value unaltered (which may have
   changed since the last call to `current-window-configuration'), while

- `window-state-put' doesn't set it for the new window.

Do you mean it's badly worded?  Or do you mean that the description
doesn't fit the code?

martin

Re: How to restore the layout?

[Juanma Barranquero]

On Mon, Jun 24, 2013 at 7:30 PM, Eli Zaretskii <eliz@gnu.org> wrote:
-c
>>   Parameters not saved by `current-window-configuration' or
>>   `window-state-get' are left alone by `set-window-configuration'
>>   respectively are not installed by `window-state-put'.
>
> No, it's just a style you are not used to.

Much as I try, I fail to see how to parse that sentence, but I'm
willing to believe it is correct. Still, I'd recommend rewriting it in
an easier-to-parse way.

(After some effort, I suppose "respectively" distributes "parameters
not saved by c-w-c" to "left alone by s-w-c" and "or w-s-g" to "not
installed by w-s-p". If that is a common idiom in English, is not one
I've ever found, so my recommendation still stands.)

   J

Re: How to restore the layout?

[Eli Zaretskii]

> From: Juanma Barranquero <lekktu@gmail.com>
> Date: Mon, 24 Jun 2013 19:52:37 +0200
> Cc: martin rudalics <rudalics@gmx.at>, Angelo Graziosi <angelo.graziosi@alice.it>, 
> 	Emacs developers <emacs-devel@gnu.org>
> 
> (After some effort, I suppose "respectively" distributes "parameters
> not saved by c-w-c" to "left alone by s-w-c" and "or w-s-g" to "not
> installed by w-s-p". If that is a common idiom in English, is not one
> I've ever found, so my recommendation still stands.)

It's something German-speaking people in particular tend to like, I
have no idea why.

Re: How to restore the layout?

[Stephen Berman]

On Mon, 24 Jun 2013 19:52:37 +0200 Juanma Barranquero <lekktu@gmail.com> wrote:

> On Mon, Jun 24, 2013 at 7:30 PM, Eli Zaretskii <eliz@gnu.org> wrote:
> -c
>>>   Parameters not saved by `current-window-configuration' or
>>>   `window-state-get' are left alone by `set-window-configuration'
>>>   respectively are not installed by `window-state-put'.
>>
>> No, it's just a style you are not used to.
>
> Much as I try, I fail to see how to parse that sentence, but I'm
> willing to believe it is correct. Still, I'd recommend rewriting it in
> an easier-to-parse way.
>
> (After some effort, I suppose "respectively" distributes "parameters
> not saved by c-w-c" to "left alone by s-w-c" and "or w-s-g" to "not
> installed by w-s-p". If that is a common idiom in English, is not one
> I've ever found, so my recommendation still stands.)

A more idiomatic, though to my ear still stilted, phasing would be:

   Parameters not saved by `current-window-configuration' or
   `window-state-get' are respectively left alone by
   `set-window-configuration' or not installed by `window-state-put'.

A more straightforward, though wordier formulation is: 

   Parameters not saved by `current-window-configuration' are left alone
   by `set-window-configuration' and parameters not saved by
   `window-state-get' are not installed by `window-state-put'.

Steve Berman

Re: How to restore the layout?

[Stephen Berman]

On Mon, 24 Jun 2013 21:18:35 +0300 Eli Zaretskii <eliz@gnu.org> wrote:

>> From: Juanma Barranquero <lekktu@gmail.com>
>> Date: Mon, 24 Jun 2013 19:52:37 +0200
>> Cc: martin rudalics <rudalics@gmx.at>, Angelo Graziosi <angelo.graziosi@alice.it>, 
>> 	Emacs developers <emacs-devel@gnu.org>
>> 
>> (After some effort, I suppose "respectively" distributes "parameters
>> not saved by c-w-c" to "left alone by s-w-c" and "or w-s-g" to "not
>> installed by w-s-p". If that is a common idiom in English, is not one
>> I've ever found, so my recommendation still stands.)
>
> It's something German-speaking people in particular tend to like, I
> have no idea why.

It's because "beziehungsweise" (translated as "respectively") is
commonly used this way in German.

Steve Berman

Re: How to restore the layout?

[Juanma Barranquero]

On Mon, Jun 24, 2013 at 8:33 PM, Stephen Berman <stephen.berman@gmx.net> wrote:

> A more idiomatic, though to my ear still stilted, phasing would be:
>
>    Parameters not saved by `current-window-configuration' or
>    `window-state-get' are respectively left alone by
>    `set-window-configuration' or not installed by `window-state-put'.

To my Spaniard's ears it would seem better

  Parameters not saved by `current-window-configuration' and
  `window-state-get' are not restored by `set-window-configuration'
  and `window-state-put', respectively.

but I'm not sure how idiomatic that is.

Re: How to restore the layout?

[Juanma Barranquero]

On Mon, Jun 24, 2013 at 10:10 PM, Juanma Barranquero <lekktu@gmail.com> wrote:

>   Parameters not saved by `current-window-configuration' and
>   `window-state-get' are not restored by `set-window-configuration'
>   and `window-state-put', respectively.

are not modified / are left untouched

Re: How to restore the layout?

[Jambunathan K]

Juanma Barranquero <lekktu@gmail.com> writes:

> On Mon, Jun 24, 2013 at 8:33 PM, Stephen Berman <stephen.berman@gmx.net> wrote:
>
>> A more idiomatic, though to my ear still stilted, phasing would be:
>>
>>    Parameters not saved by `current-window-configuration' or
>>    `window-state-get' are respectively left alone by
>>    `set-window-configuration' or not installed by `window-state-put'.
>
> To my Spaniard's ears it would seem better
>
>   Parameters not saved by `current-window-configuration' and
>   `window-state-get' are not restored by `set-window-configuration'
>   and `window-state-put', respectively.
>
> but I'm not sure how idiomatic that is.

I see two "nots".  Avoid two negatives.  

   The only parameter that is restored by ... are those that are saved
   with ...

Another variation would be

   Parameters that are restored by ... must be saved with a prior
   call to ...

You get the drift...

Re: How to restore the layout?

[Juanma Barranquero]

> I see two "nots".  Avoid two negatives.

I don't really believe in prescriptivist rules of good writing. Two
negatives can be confusing, or clearer than the alternative, depending
on the sentence.

>    The only parameter that is restored by ... are those that are saved
>    with ...

>    Parameters that are restored by ... must be saved with a prior
>    call to ...
>

I prefer the second one.

Re: How to restore the layout?

[martin rudalics]

> I prefer the second one.

I think all of your suggestions are considerable improvements.
Thanks.  Please install whatever you prefer.

Now could someone also implement the desktop stuff, pretty please?
(IIUC it's mostly about writing good doc-strings for some trivial
function changes and defcustoms.)

martin

Re: How to restore the layout?

[Juanma Barranquero]

On Mon, Jun 24, 2013 at 10:57 PM, martin rudalics <rudalics@gmx.at> wrote:

> Now could someone also implement the desktop stuff, pretty please?
> (IIUC it's mostly about writing good doc-strings for some trivial
> function changes and defcustoms.)

This is a first cut against 24.3; no docstrings, not tested other than
trivially.

Once window-state-(get|put) do work in the trunk we can try to massage
it into something better.

   J



--- desktop.el.old 2013-01-01 21:37:17.000000000 +0100
+++ desktop.el 2013-06-25 00:45:16.773228800 +0200
@@ -273,6 +273,7 @@

 (defcustom desktop-globals-to-save
   '(desktop-missing-file-warning
+    desktop--window-state
     tags-file-name
     tags-table-list
     search-ring
@@ -358,6 +359,12 @@
   :type '(repeat symbol)
   :group 'desktop)

+(defcustom desktop-save-windows t
+  "When non-nil, save window configuration to desktop file."
+  :type 'boolean
+  :group 'desktop
+  :version "24.4")
+
 (defcustom desktop-file-name-format 'absolute
   "Format in which desktop file names should be saved.
 Possible values are:
@@ -539,6 +546,9 @@
 (defvar desktop-delay-hook nil
   "Hooks run after all buffers are loaded; intended for internal use.")

+(defvar desktop--window-state nil
+  "Internal use only.")
+
 ;; ----------------------------------------------------------------------------
 ;; Desktop file conflict detection
 (defvar desktop-file-modtime nil
@@ -851,8 +861,15 @@
     ((eq desktop-file-name-format 'local) (file-relative-name
filename dirname))
     (t (expand-file-name filename))))

-
 ;; ----------------------------------------------------------------------------
+
+(defun desktop--save-windows ()
+  (setq desktop--window-state
+        (and desktop-save-windows
+             (mapcar (lambda (frame)
+                       (window-state-get (frame-root-window frame) t))
+                     (frame-list)))))
+
 ;;;###autoload
 (defun desktop-save (dirname &optional release)
   "Save the desktop in a desktop file.
@@ -880,6 +897,8 @@
     (desktop-release-lock)
   (unless (and new-modtime (desktop-owner)) (desktop-claim-lock)))

+        (desktop--save-windows)
+
  (with-temp-buffer
   (insert
    ";; -*- mode: emacs-lisp; coding: emacs-mule; -*-\n"
@@ -940,6 +959,13 @@

 (defvar desktop-lazy-timer nil)

+(defun desktop--read-windows ()
+  (when desktop--window-state
+    (window-state-put (car desktop--window-state)
+                      (frame-root-window (selected-frame)))
+    (dolist (state (cdr desktop--window-state))
+      (window-state-put state (frame-root-window (make-frame))))))
+
 ;; ----------------------------------------------------------------------------
 ;;;###autoload
 (defun desktop-read (&optional dirname)
@@ -1009,6 +1035,7 @@
     (switch-to-buffer (car (buffer-list)))
     (run-hooks 'desktop-delay-hook)
     (setq desktop-delay-hook nil)
+            (desktop--read-windows)
     (run-hooks 'desktop-after-read-hook)
     (message "Desktop: %d buffer%s restored%s%s."
      desktop-buffer-ok-count

Re: How to restore the layout?

[Juri Linkov]

>> Now could someone also implement the desktop stuff, pretty please?
>> (IIUC it's mostly about writing good doc-strings for some trivial
>> function changes and defcustoms.)
>
> This is a first cut against 24.3; no docstrings, not tested other than
> trivially.

Please increment the version number of the desktop file in
`desktop-file-version' because the new format will be backward
incompatible with the old one.  What do you think about also
merging it with the patch from Jérémy Compostella at
http://lists.gnu.org/archive/html/emacs-devel/2012-01/msg00600.html
that additionally saves the frame parameters as well.

Re: How to restore the layout?

[Juanma Barranquero]

On Tue, Jun 25, 2013 at 1:38 AM, Juri Linkov <juri@jurta.org> wrote:

> Please increment the version number of the desktop file in
> `desktop-file-version' because the new format will be backward
> incompatible with the old one.

Why? The window configuration is saved as a global variable. An old
desktop.el would load it, but do nothing with it...

>  What do you think about also
> merging it with the patch from Jérémy Compostella at
> http://lists.gnu.org/archive/html/emacs-devel/2012-01/msg00600.html
> that additionally saves the frame parameters as well.

Yes, saving frame parameters is one of the things missing in my sample
code. I haven't looked at Jérémy Compostella's patch, but if it
already saves the frames, why merge both patches? What is lacking in
his?

    J

Re: How to restore the layout?

[Stephen J. Turnbull]

Stephen Berman writes:

 > A more idiomatic, though to my ear still stilted, phasing would be:
 > 
 >    Parameters not saved by `current-window-configuration' or
 >    `window-state-get' are respectively left alone by
 >    `set-window-configuration' or not installed by `window-state-put'.

Idiomatically, in American English, "respectively" normally does not
create sets of correspondences across clauses, it creates analogies
within clauses which bind positionally across clauses:

    `set-window-configuration' (respectively, `window-state-put')
    affects only parameters saved by `current-window-configuration'
    (respectively, `window-state-get').

Typically in technical writing the word "respectively" is often
abbreviated to "resp." or even elided:

    `set-window-configuration' (`window-state-put') affects only
    parameters saved by `current-window-configuration'
    (`window-state-get').

It's very much like an alist of the form (KEY . (VALUE1 VALUE2 ...)),
as the parenthetical phrases can contain sequences of items.

Re: How to restore the layout?

[Juri Linkov]

>> Please increment the version number of the desktop file in
>> `desktop-file-version' because the new format will be backward
>> incompatible with the old one.
>
> Why? The window configuration is saved as a global variable. An old
> desktop.el would load it, but do nothing with it...

It's very good that your approach is backward compatible and
doesn't require changing the format of the desktop file.

>>  What do you think about also
>> merging it with the patch from Jérémy Compostella at
>> http://lists.gnu.org/archive/html/emacs-devel/2012-01/msg00600.html
>> that additionally saves the frame parameters as well.
>
> Yes, saving frame parameters is one of the things missing in my sample
> code. I haven't looked at Jérémy Compostella's patch, but if it
> already saves the frames, why merge both patches? What is lacking in
> his?

The difference is in the format.  His patch changes the format of
the desktop file that logically fits better to the design of desktop.el.
Like the existing function calls `desktop-create-buffer' in the desktop
file, it adds similar function calls `desktop-restore-frame':

  (desktop-restore-frame t   '(frame1-params...) '(window-tree1...))
  (desktop-restore-frame nil '(frame2-params...) '(window-tree2...))
  (desktop-restore-frame nil '(frame3-params...) '(window-tree3...))

The disadvantage is that loading the new format in older Emacs
versions where `desktop-restore-frame' is undefined will fail.
Perhaps it could use something like

  (when (fboundp 'desktop-restore-frame)
    (desktop-restore-frame t   '(frame1-params...) '(window-tree1...))
    (desktop-restore-frame nil '(frame2-params...) '(window-tree2...))
    (desktop-restore-frame nil '(frame3-params...) '(window-tree3...)))

but isn't this too ugly?

OTOH, your patch has the advantage of backward compatibility in that
it uses `setq' to a new variable, and older Emacs versions will just
ignore this setting.

So the main question to decide is what format to use.

Re: How to restore the layout?

[martin rudalics]

 > This is a first cut against 24.3; no docstrings, not tested other than
 > trivially.

Thank you.  Since I never use desktop (I often restart Emacs to get rid
of any history that piled up during a session) I urge anyone using it to
test this.

 > Once window-state-(get|put) do work in the trunk we can try to massage
 > it into something better.

Please try with the remedy I hinted at earlier.  In `window-state-get-1'
replace the entry

             (combination-limit . ,(window-combination-limit window))

by something like

             ,@(unless (window-live-p window)
		`(combination-limit . ,(window-combination-limit window)))


,@s never make an expression more comprehensible to me so please
experiment.  If it doesn't work out easily, simply throw the entire

(combination-limit . ,(window-combination-limit window))

expression away.  Dmitry now uses the combination-limit slot for storing
the window's buffer when producing a window configuration and I don't
have the slightest idea whether and how this would infer with what we do
here :-(

Thanks again, martin

Re: How to restore the layout?

[Juanma Barranquero]

On Tue, Jun 25, 2013 at 8:46 AM, martin rudalics <rudalics@gmx.at> wrote:

> Please try with the remedy I hinted at earlier.  In `window-state-get-1'
> replace the entry
>
>             (combination-limit . ,(window-combination-limit window))
>
> by something like
>
>             ,@(unless (window-live-p window)
>                 `(combination-limit . ,(window-combination-limit window)))

In my admitedly quick test it does not break, so I'm going to install
it as a workaround for bug#14527, but I'll leave it open.

   J

Re: How to restore the layout?

[Juanma Barranquero]

On Tue, Jun 25, 2013 at 8:03 AM, Juri Linkov <juri@jurta.org> wrote:

> The difference is in the format.  His patch changes the format of
> the desktop file that logically fits better to the design of desktop.el.
> Like the existing function calls `desktop-create-buffer' in the desktop
> file, it adds similar function calls `desktop-restore-frame':

I've committed Martin's fix for the window-state-get bug. I'm now
going to integrate Jérémy's and my changes and work out a patch than
can be tested on trunk.

   J

Re: How to restore the layout?

[Stefan Monnier]

>> (combination-limit . ,(window-combination-limit window))
>> 
>> by something like
>> 
>> ,@(unless (window-live-p window)
>>    `(combination-limit . ,(window-combination-limit window)))

I have no idea ab out what the code is supposed to do but the above
change looks suspicious.  If you want to conditionally include the
line, then you want:

 ,@(unless (window-live-p window)
    `((combination-limit . ,(window-combination-limit window))))


-- Stefan

Re: How to restore the layout?

[martin rudalics]

> I have no idea ab out what the code is supposed to do but the above
> change looks suspicious.  If you want to conditionally include the
> line, then you want:
> 
>  ,@(unless (window-live-p window)
>     `((combination-limit . ,(window-combination-limit window))))

Indeed.  Sorry, Juanma.

martin

Re: How to restore the layout?

[Juanma Barranquero]

On Tue, Jun 25, 2013 at 6:38 PM, martin rudalics <rudalics@gmx.at> wrote:

> Indeed.  Sorry, Juanma.

No problem. Installed.

  J

Re: How to restore the layout?

[Angelo Graziosi]

Il 25/06/2013 19.21, Juanma Barranquero ha scritto:
> On Tue, Jun 25, 2013 at 6:38 PM, martin rudalics <rudalics@gmx.at> wrote:
>
>> Indeed.  Sorry, Juanma.
>
> No problem. Installed.

Out of curiosity I tried the patch described here

   http://lists.gnu.org/archive/html/emacs-devel/2013-06/msg01031.html

with trunk r. 113178, and it looks good! It needs only to save also the 
frame size. Indeed if one divides the frame in four "window" of 
different size, usually this is done with a maximized frame size. 
Instead, restarting Emacs, it uses a default frame size in which the 
four "window" are too compressed. Obviously re-maximize the frame is low 
cost... :-)

Thanks! Very good work!


Ciao,
  Angelo.

Re: How to restore the layout?

[Juanma Barranquero]

On Tue, Jun 25, 2013 at 11:36 PM, Angelo Graziosi
<angelo.graziosi@alice.it> wrote:

> Out of curiosity I tried the patch described here
>
>   http://lists.gnu.org/archive/html/emacs-devel/2013-06/msg01031.html
>
> with trunk r. 113178, and it looks good! It needs only to save also the
> frame size.

Yes. That's 10 minutes of coding and even less testing. Obviously
there are many things lacking. I'll come up with something better
ASAP, I hope.

   J

Re: How to restore the layout?

[chad]

Updating emacs since this change, I find that emacs spins forever
after completing my init file. A stack trace:

I won't really be able to look into this until late tonight PDT,
probably ~5 hours from now, but I thought I'd report it here in
case it was obvious to someone. I don't see the problem with emacs
-Q.

Thanks in advance,
~Chad

#1-#544 are all variations on #545 with different line numbers
#545 0x00000001000f9423 in mark_object () at alloc.c:6006
#546 0x00000001000f9589 in mark_vectorlike [inlined] () at /usr/local/src/emacs/working/src/alloc.c:5584
#547 0x00000001000f9589 in mark_buffer () at alloc.c:5635
#548 0x00000001000fe390 in Fgarbage_collect () at alloc.c:5269
#549 0x000000010014df53 in maybe_gc [inlined] () at /usr/local/src/emacs/working/src/lisp.h:4310
#550 0x000000010014df53 in exec_byte_code (bytestr=4300795816, vector=140734799802144, maxdepth=0, args_template=4412961787, nargs=4300792512, args=0x100512c80) at lisp.h:961
#551 0x0000000100116da7 in Ffuncall (nargs=10, args=0x1070c11c2) at eval.c:2839
#552 0x000000010014dc08 in exec_byte_code (bytestr=4300795816, vector=140734799802432, maxdepth=0, args_template=0, nargs=4300792512, args=0x100512c80) at bytecode.c:903
#553 0x0000000100116da7 in Ffuncall (nargs=3, args=0x1070c1192) at eval.c:2839
#554 0x000000010014dc08 in exec_byte_code (bytestr=4300795816, vector=140734799802688, maxdepth=0, args_template=0, nargs=4300792512, args=0x100512c80) at bytecode.c:903
#555 0x0000000100116da7 in Ffuncall (nargs=2, args=0x1070c1162) at eval.c:2839
#556 0x000000010014dc08 in exec_byte_code (bytestr=4300795816, vector=140734799802944, maxdepth=0, args_template=0, nargs=4300792512, args=0x100512c80) at bytecode.c:903
#557 0x0000000100116da7 in Ffuncall (nargs=1, args=0x1018c5bea) at eval.c:2839
#558 0x000000010014dc08 in exec_byte_code (bytestr=4300795816, vector=140734799803296, maxdepth=0, args_template=4296336960, nargs=4300792512, args=0x100512c80) at bytecode.c:903
#559 0x0000000100116da7 in Ffuncall (nargs=1, args=0x1018c572a) at eval.c:2839
#560 0x000000010014dc08 in exec_byte_code (bytestr=4300795816, vector=140734799803584, maxdepth=0, args_template=4300034539, nargs=4300792512, args=0x100512c80) at bytecode.c:903
#561 0x0000000100119e33 in apply_lambda (fun=140734799803680, args=0) at eval.c:2899
#562 0x0000000100119b3b in eval_sub (form=4297609365) at eval.c:2290
#563 0x000000010011649a in Feval (form=4362222598, lexical=4297609445) at eval.c:1993
#564 0x00000001001188db in internal_condition_case (bfun=0x1000a8b70 <top_level_2>, handlers=4320220826, hfun=0x1000b2fa0 <cmd_error>) at eval.c:1289
#565 0x00000001000b31ab in top_level_1 (ignore=4297609365) at keyboard.c:1181
#566 0x00000001001189c7 in internal_catch (tag=4297609365, func=0x1000b3170 <top_level_1>, arg=4297609365) at eval.c:1063
#567 0x00000001000b3512 in command_loop [inlined] () at /usr/local/src/emacs/working/src/keyboard.c:1142
#568 0x00000001000b3512 in recursive_edit_1 () at keyboard.c:776
#569 0x00000001000a49cd in Frecursive_edit () at keyboard.c:840
#570 0x00000001000a189a in main (argc=5825216, argv=0x7fff5fbffa10) at emacs.c:1550

Re: How to restore the layout?

[chad]

On 25 Jun 2013, at 17:52, chad <yandros@mit.edu> wrote:

> Updating emacs since this change, I find that emacs spins forever
> after completing my init file. A stack trace:

Rebuilding this morning, I don't see the problem anymore.

~Chad

Re: How to restore the layout?

[Juanma Barranquero]

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

This is basically the same patch as before, only slightly more
polished. It's surprisingly functional for its tiny size.

Changes:
- Window/frame config is still saved as a global variable, but not
from desktop-globals-to-save, which is a user option.
- Some frame parameters are not saved, mostly those that cannot be
read back or makes no sense to do so.
- Errors while restoring the config do not interrupt the restoring;
there's just a message afterwards.

There are many things still unimplemented, some of which should be
discussed before throwing code at it. From the top of my head:

1) When restoring frames, what to do with the existing ones? They can
be reused, or deleted. Reusing them will cause less "flicker".

2) What to do with frames with a buffer-predicate? Currently I'm
excluding that frame parameter. It could be saved if it is a symbol,
of course.

3) What about maximized / fullscreen frames? Currently they don't
restore too well. It would be possible, but the original
pre-(fullscreen|maximized) size will not be saved. It could be saved
by de-maximizing the frame before saving it and then maximizing it
back again, but if the user is just calling desktop-save in the middle
of a session, that will make the maximized frame flicker.

4) I'm not saving the `minibuffer' parameter, though I should. It's
trivial for t/nil/only, but what about minibuffer . <#window...>?
Should we try to save/restore that somehow?

5) Presumably, for Emacs on X I should make sure that each frame is
restored in the corresponding display. I'm not yet doing that (I don't
have a way to test it).

All in all, the patch is small and non-intrusive. Perhaps I could
install it (with desktop-save-windows defaulting to nil) so people
could experiment and say what works and what doesn't. That would be
particularly useful from people who use multi-frame setups (Stefan and
Drew come to mind).

Comments?

    J



=== modified file 'lisp/desktop.el'
--- lisp/desktop.el 2013-05-02 17:47:39 +0000
+++ lisp/desktop.el 2013-06-26 17:15:07 +0000
@@ -371,6 +371,12 @@
   :type '(repeat symbol)
   :group 'desktop)

+(defcustom desktop-save-windows t
+  "When non-nil, save window/frame configuration to desktop file."
+  :type 'boolean
+  :group 'desktop
+  :version "24.4")
+
 (defcustom desktop-file-name-format 'absolute
   "Format in which desktop file names should be saved.
 Possible values are:
@@ -556,6 +562,9 @@
   "Checksum of the last auto-saved contents of the desktop file.
 Used to avoid writing contents unchanged between auto-saves.")

+(defvar desktop--window-state nil
+  "Internal use only.")
+
 ;; ----------------------------------------------------------------------------
 ;; Desktop file conflict detection
 (defvar desktop-file-modtime nil
@@ -858,6 +867,37 @@


 ;; ----------------------------------------------------------------------------
+(defconst desktop--excluded-frame-parameters
+  '(minibuffer-predicate
+    minibuffer
+    buffer-list
+    buried-buffer-list
+    window-id
+    outer-window-id)
+  "Frame parameters not saved or restored.")
+
+(defun desktop--filter-frame-parms (frame)
+  "Return frame parameters of FRAME.
+Parameters in `desktop--excluded-frame-parameters' are excluded.
+Internal use only."
+  (let (params)
+    (dolist (param (frame-parameters frame))
+      (unless (memq param desktop--excluded-frame-parameters)
+ (push param params)))
+    params))
+
+(defun desktop--save-windows ()
+  "Save window/frame state, as a global variable.
+Intended to be called from `desktop-save'.
+Internal use only."
+  (setq desktop--window-state
+ (and desktop-save-windows
+     (mapcar (lambda (frame)
+       (cons (desktop--filter-frame-parms frame)
+     (window-state-get (frame-root-window frame) t)))
+     (frame-list))))
+  (desktop-outvar 'desktop--window-state))
+
 ;;;###autoload
 (defun desktop-save (dirname &optional release auto-save)
   "Save the desktop in a desktop file.
@@ -896,6 +936,9 @@
   (save-excursion (run-hooks 'desktop-save-hook))
   (goto-char (point-max))
   (insert "\n;; Global section:\n")
+  ;; Called here because we save the window/frame state as a global
+  ;; variable for compatibility with previous Emacsen.
+  (desktop--save-windows)
   (mapc (function desktop-outvar) desktop-globals-to-save)
   (when (memq 'kill-ring desktop-globals-to-save)
     (insert
@@ -954,6 +997,20 @@
 (defvar desktop-lazy-timer nil)

 ;; ----------------------------------------------------------------------------
+(defun desktop--restore-windows ()
+  "Restore window/frame configuration.
+Internal use only."
+  (when (and desktop-save-windows desktop--window-state)
+    (let ((current (frame-list))
+  (failure nil))
+      (dolist (state desktop--window-state)
+ (condition-case nil
+    (window-state-put (cdr state) (frame-root-window (make-frame (car state))))
+  (error (setq failure t))))
+      (if failure
+  (message "Error loading window configuration from desktop file")
+ (mapc #'delete-frame current)))))
+
 ;;;###autoload
 (defun desktop-read (&optional dirname)
   "Read and process the desktop file in directory DIRNAME.
@@ -1022,6 +1079,7 @@
     (switch-to-buffer (car (buffer-list)))
     (run-hooks 'desktop-delay-hook)
     (setq desktop-delay-hook nil)
+    (desktop--restore-windows)
     (run-hooks 'desktop-after-read-hook)
     (message "Desktop: %d buffer%s restored%s%s."
      desktop-buffer-ok-count

[-- Attachment #2: desktop.patch --]
[-- Type: application/octet-stream, Size: 3632 bytes --]

=== modified file 'lisp/desktop.el'
--- lisp/desktop.el	2013-05-02 17:47:39 +0000
+++ lisp/desktop.el	2013-06-26 17:15:07 +0000
@@ -371,6 +371,12 @@
   :type '(repeat symbol)
   :group 'desktop)
 
+(defcustom desktop-save-windows t
+  "When non-nil, save window/frame configuration to desktop file."
+  :type 'boolean
+  :group 'desktop
+  :version "24.4")
+
 (defcustom desktop-file-name-format 'absolute
   "Format in which desktop file names should be saved.
 Possible values are:
@@ -556,6 +562,9 @@
   "Checksum of the last auto-saved contents of the desktop file.
 Used to avoid writing contents unchanged between auto-saves.")
 
+(defvar desktop--window-state nil
+  "Internal use only.")
+
 ;; ----------------------------------------------------------------------------
 ;; Desktop file conflict detection
 (defvar desktop-file-modtime nil
@@ -858,6 +867,37 @@
 
 
 ;; ----------------------------------------------------------------------------
+(defconst desktop--excluded-frame-parameters
+  '(minibuffer-predicate
+    minibuffer
+    buffer-list
+    buried-buffer-list
+    window-id
+    outer-window-id)
+  "Frame parameters not saved or restored.")
+
+(defun desktop--filter-frame-parms (frame)
+  "Return frame parameters of FRAME.
+Parameters in `desktop--excluded-frame-parameters' are excluded.
+Internal use only."
+  (let (params)
+    (dolist (param (frame-parameters frame))
+      (unless (memq param desktop--excluded-frame-parameters)
+	(push param params)))
+    params))
+
+(defun desktop--save-windows ()
+  "Save window/frame state, as a global variable.
+Intended to be called from `desktop-save'.
+Internal use only."
+  (setq desktop--window-state
+	(and desktop-save-windows
+	     (mapcar (lambda (frame)
+		       (cons (desktop--filter-frame-parms frame)
+			     (window-state-get (frame-root-window frame) t)))
+		     (frame-list))))
+  (desktop-outvar 'desktop--window-state))
+
 ;;;###autoload
 (defun desktop-save (dirname &optional release auto-save)
   "Save the desktop in a desktop file.
@@ -896,6 +936,9 @@
 	  (save-excursion (run-hooks 'desktop-save-hook))
 	  (goto-char (point-max))
 	  (insert "\n;; Global section:\n")
+	  ;; Called here because we save the window/frame state as a global
+	  ;; variable for compatibility with previous Emacsen.
+	  (desktop--save-windows)
 	  (mapc (function desktop-outvar) desktop-globals-to-save)
 	  (when (memq 'kill-ring desktop-globals-to-save)
 	    (insert
@@ -954,6 +997,20 @@
 (defvar desktop-lazy-timer nil)
 
 ;; ----------------------------------------------------------------------------
+(defun desktop--restore-windows ()
+  "Restore window/frame configuration.
+Internal use only."
+  (when (and desktop-save-windows desktop--window-state)
+    (let ((current (frame-list))
+	  (failure nil))
+      (dolist (state desktop--window-state)
+	(condition-case nil
+	    (window-state-put (cdr state) (frame-root-window (make-frame (car state))))
+	  (error (setq failure t))))
+      (if failure
+	  (message "Error loading window configuration from desktop file")
+	(mapc #'delete-frame current)))))
+
 ;;;###autoload
 (defun desktop-read (&optional dirname)
   "Read and process the desktop file in directory DIRNAME.
@@ -1022,6 +1079,7 @@
 	    (switch-to-buffer (car (buffer-list)))
 	    (run-hooks 'desktop-delay-hook)
 	    (setq desktop-delay-hook nil)
+	    (desktop--restore-windows)
 	    (run-hooks 'desktop-after-read-hook)
 	    (message "Desktop: %d buffer%s restored%s%s."
 		     desktop-buffer-ok-count

Re: How to restore the layout?

[martin rudalics]

 > 1) When restoring frames, what to do with the existing ones? They can
 > be reused, or deleted. Reusing them will cause less "flicker".

The main application is to _restore_ the layout at the _beginning_ of a
session.  This means that the one initial frame would get reused.  And
this will conflict with restoring the layout in the middle of a session
so I wouldn't care too much about this issue.

Let's ignore the next issues for the moment.  Currently, I am too silly
to understand whether and where you set frame parameters and how this
interacts with the setting of window parameters (like margin or fringe
widths).

 > All in all, the patch is small and non-intrusive. Perhaps I could
 > install it (with desktop-save-windows defaulting to nil) so people
 > could experiment and say what works and what doesn't. That would be
 > particularly useful from people who use multi-frame setups (Stefan and
 > Drew come to mind).

Please do that.

Thanks, martin

Re: How to restore the layout?

[Juanma Barranquero]

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

On Wed, Jun 26, 2013 at 8:27 PM, martin rudalics <rudalics@gmx.at> wrote:

> The main application is to _restore_ the layout at the _beginning_ of a
> session.  This means that the one initial frame would get reused.

I've implemented reusing all frames according to their displays (that
is, if desktop wants to restore a frame, it will first look on the
list of yet-unused frames for one on the right display; if found, it
will reuse it and delete it from the list; otherwise it will create a
new frame).

It's a pity that, AFAIK, there's no way to delay creating the initial
frame; initial-frame-alist is set after running .emacs, so you cannot
really avoid the resizing / flickering. Other than setting X resources
/ Win32 registry settings just right for the initial frame (which will
backfire as soon as you exit & save the initial frame at another
position / size), the only way to make it more palatable is starting
emacs with --iconic (or perhaps --daemon on POSIX systems?).

> Let's ignore the next issues for the moment.

Well, some of them are hardly ignorable, at least for users with many
frames, minibuffer-only frames, etc. Also the maximized/fullscreen
issue will bother people who usually works with maximized Emacs
windows (assuming such people does exist).

Another issue is at which point in the restore sequence should
windows/frames be restored. Currently I'm doing it between
desktop-delay-hook (which runs when all buffers are loaded) and
desktop-after-read-hook (which happens after a "successful
`desktop-read'"). That would allow the user to intercept the
restoring, though desktop-delay-hook is for internal use. I can of
course add hooks at some points in the save & restore sequences, but
perhaps that's better left until the need arises.

> Please do that.

Let's hear from Stefan & Glenn. Meanwhile, here's the new patch.

   J


=== modified file 'lisp/desktop.el'
--- lisp/desktop.el 2013-05-02 17:47:39 +0000
+++ lisp/desktop.el 2013-06-26 23:03:43 +0000
@@ -371,6 +371,12 @@
   :type '(repeat symbol)
   :group 'desktop)

+(defcustom desktop-save-windows t
+  "When non-nil, save window/frame configuration to desktop file."
+  :type 'boolean
+  :group 'desktop
+  :version "24.4")
+
 (defcustom desktop-file-name-format 'absolute
   "Format in which desktop file names should be saved.
 Possible values are:
@@ -556,6 +562,9 @@
   "Checksum of the last auto-saved contents of the desktop file.
 Used to avoid writing contents unchanged between auto-saves.")

+(defvar desktop--saved-states nil
+  "Internal use only.")
+
 ;; ----------------------------------------------------------------------------
 ;; Desktop file conflict detection
 (defvar desktop-file-modtime nil
@@ -858,6 +867,42 @@


 ;; ----------------------------------------------------------------------------
+(defconst desktop--excluded-frame-parameters
+  '(buffer-list
+    buffer-predicate
+    buried-buffer-list
+    explicit-name
+    font-backend
+    minibuffer
+    name
+    outer-window-id
+    parent-id
+    window-id
+    window-system)
+  "Frame parameters not saved or restored.")
+
+(defun desktop--filter-frame-parms (frame)
+  "Return frame parameters of FRAME.
+Parameters in `desktop--excluded-frame-parameters' are excluded.
+Internal use only."
+  (let (params)
+    (dolist (param (frame-parameters frame))
+      (unless (memq (car param) desktop--excluded-frame-parameters)
+ (push param params)))
+    params))
+
+(defun desktop--save-windows ()
+  "Save window/frame state, as a global variable.
+Intended to be called from `desktop-save'.
+Internal use only."
+  (setq desktop--saved-states
+ (and desktop-save-windows
+     (mapcar (lambda (frame)
+       (cons (desktop--filter-frame-parms frame)
+     (window-state-get (frame-root-window frame) t)))
+     (frame-list))))
+  (desktop-outvar 'desktop--saved-states))
+
 ;;;###autoload
 (defun desktop-save (dirname &optional release auto-save)
   "Save the desktop in a desktop file.
@@ -896,6 +941,9 @@
   (save-excursion (run-hooks 'desktop-save-hook))
   (goto-char (point-max))
   (insert "\n;; Global section:\n")
+  ;; Called here because we save the window/frame state as a global
+  ;; variable for compatibility with previous Emacsen.
+  (desktop--save-windows)
   (mapc (function desktop-outvar) desktop-globals-to-save)
   (when (memq 'kill-ring desktop-globals-to-save)
     (insert
@@ -954,6 +1002,37 @@
 (defvar desktop-lazy-timer nil)

 ;; ----------------------------------------------------------------------------
+(defun desktop--find-frame-in-display (frames display)
+  (let (result)
+    (while (and frames (not result))
+      (if (equal display (frame-parameter (car frames) 'display))
+  (setq result (car frames))
+ (setq frames (cdr frames))))
+    result))
+
+(defun desktop--restore-windows ()
+  "Restore window/frame configuration.
+Internal use only."
+  (when (and desktop-save-windows desktop--saved-states)
+    (condition-case nil
+ (let ((frames (frame-list)))
+  (dolist (state desktop--saved-states)
+    (let* ((fconfig (car state))
+   (display (cdr (assq 'display fconfig)))
+   (frame (desktop--find-frame-in-display frames display)))
+      (if (not frame)
+  ;; no frames in the display -- make a new one
+  (setq frame (make-frame-on-display display fconfig))
+ ;; found one -- reuse and remove from list
+ (setq frames (delq frame frames))
+ (modify-frame-parameters frame fconfig))
+      ;; restore windows
+      (window-state-put (cdr state) (frame-root-window frame) 'safe)))
+  ;; delete any remaining frames
+  (mapc #'delete-frame frames))
+      (error
+       (message "Error loading window configuration from desktop file")))))
+
 ;;;###autoload
 (defun desktop-read (&optional dirname)
   "Read and process the desktop file in directory DIRNAME.
@@ -1022,6 +1101,7 @@
     (switch-to-buffer (car (buffer-list)))
     (run-hooks 'desktop-delay-hook)
     (setq desktop-delay-hook nil)
+    (desktop--restore-windows)
     (run-hooks 'desktop-after-read-hook)
     (message "Desktop: %d buffer%s restored%s%s."
      desktop-buffer-ok-count

[-- Attachment #2: desktop.patch --]
[-- Type: application/octet-stream, Size: 4399 bytes --]

=== modified file 'lisp/desktop.el'
--- lisp/desktop.el	2013-05-02 17:47:39 +0000
+++ lisp/desktop.el	2013-06-26 23:03:43 +0000
@@ -371,6 +371,12 @@
   :type '(repeat symbol)
   :group 'desktop)
 
+(defcustom desktop-save-windows t
+  "When non-nil, save window/frame configuration to desktop file."
+  :type 'boolean
+  :group 'desktop
+  :version "24.4")
+
 (defcustom desktop-file-name-format 'absolute
   "Format in which desktop file names should be saved.
 Possible values are:
@@ -556,6 +562,9 @@
   "Checksum of the last auto-saved contents of the desktop file.
 Used to avoid writing contents unchanged between auto-saves.")
 
+(defvar desktop--saved-states nil
+  "Internal use only.")
+
 ;; ----------------------------------------------------------------------------
 ;; Desktop file conflict detection
 (defvar desktop-file-modtime nil
@@ -858,6 +867,42 @@
 
 
 ;; ----------------------------------------------------------------------------
+(defconst desktop--excluded-frame-parameters
+  '(buffer-list
+    buffer-predicate
+    buried-buffer-list
+    explicit-name
+    font-backend
+    minibuffer
+    name
+    outer-window-id
+    parent-id
+    window-id
+    window-system)
+  "Frame parameters not saved or restored.")
+
+(defun desktop--filter-frame-parms (frame)
+  "Return frame parameters of FRAME.
+Parameters in `desktop--excluded-frame-parameters' are excluded.
+Internal use only."
+  (let (params)
+    (dolist (param (frame-parameters frame))
+      (unless (memq (car param) desktop--excluded-frame-parameters)
+	(push param params)))
+    params))
+
+(defun desktop--save-windows ()
+  "Save window/frame state, as a global variable.
+Intended to be called from `desktop-save'.
+Internal use only."
+  (setq desktop--saved-states
+	(and desktop-save-windows
+	     (mapcar (lambda (frame)
+		       (cons (desktop--filter-frame-parms frame)
+			     (window-state-get (frame-root-window frame) t)))
+		     (frame-list))))
+  (desktop-outvar 'desktop--saved-states))
+
 ;;;###autoload
 (defun desktop-save (dirname &optional release auto-save)
   "Save the desktop in a desktop file.
@@ -896,6 +941,9 @@
 	  (save-excursion (run-hooks 'desktop-save-hook))
 	  (goto-char (point-max))
 	  (insert "\n;; Global section:\n")
+	  ;; Called here because we save the window/frame state as a global
+	  ;; variable for compatibility with previous Emacsen.
+	  (desktop--save-windows)
 	  (mapc (function desktop-outvar) desktop-globals-to-save)
 	  (when (memq 'kill-ring desktop-globals-to-save)
 	    (insert
@@ -954,6 +1002,37 @@
 (defvar desktop-lazy-timer nil)
 
 ;; ----------------------------------------------------------------------------
+(defun desktop--find-frame-in-display (frames display)
+  (let (result)
+    (while (and frames (not result))
+      (if (equal display (frame-parameter (car frames) 'display))
+	  (setq result (car frames))
+	(setq frames (cdr frames))))
+    result))
+
+(defun desktop--restore-windows ()
+  "Restore window/frame configuration.
+Internal use only."
+  (when (and desktop-save-windows desktop--saved-states)
+    (condition-case nil
+	(let ((frames (frame-list)))
+	  (dolist (state desktop--saved-states)
+	    (let* ((fconfig (car state))
+		   (display (cdr (assq 'display fconfig)))
+		   (frame (desktop--find-frame-in-display frames display)))
+	      (if (not frame)
+		  ;; no frames in the display -- make a new one
+		  (setq frame (make-frame-on-display display fconfig))
+		;; found one -- reuse and remove from list
+		(setq frames (delq frame frames))
+		(modify-frame-parameters frame fconfig))
+	      ;; restore windows
+	      (window-state-put (cdr state) (frame-root-window frame) 'safe)))
+	  ;; delete any remaining frames
+	  (mapc #'delete-frame frames))
+      (error
+       (message "Error loading window configuration from desktop file")))))
+
 ;;;###autoload
 (defun desktop-read (&optional dirname)
   "Read and process the desktop file in directory DIRNAME.
@@ -1022,6 +1101,7 @@
 	    (switch-to-buffer (car (buffer-list)))
 	    (run-hooks 'desktop-delay-hook)
 	    (setq desktop-delay-hook nil)
+	    (desktop--restore-windows)
 	    (run-hooks 'desktop-after-read-hook)
 	    (message "Desktop: %d buffer%s restored%s%s."
 		     desktop-buffer-ok-count

Re: How to restore the layout?

[Stefan Monnier]

> It's a pity that, AFAIK, there's no way to delay creating the initial
> frame; initial-frame-alist is set after running .emacs, so you cannot

We could add a cmdline flag to delay creation of the initial frame after
reading the .emacs.

> Let's hear from Stefan & Glenn. Meanwhile, here's the new patch.

Not sure what you want to hear from me.


        Stefan

Re: How to restore the layout?

[Juanma Barranquero]

On Thu, Jun 27, 2013 at 4:35 AM, Stefan Monnier
<monnier@iro.umontreal.ca> wrote:

> We could add a cmdline flag to delay creation of the initial frame after
> reading the .emacs.

ISTR the initial frame must be created relatively soon because some
low-level code depends on it existing. But we could allow it being
invisible or something like that.

>> Let's hear from Stefan & Glenn. Meanwhile, here's the new patch.
>
> Not sure what you want to hear from me.

About installing my patch (disabled by default).

   J

Re: How to restore the layout?

[Stefan Monnier]

>> We could add a cmdline flag to delay creation of the initial frame after
>> reading the .emacs.
> ISTR the initial frame must be created relatively soon because some
> low-level code depends on it existing.

That's not my experience (running a local patch which delays creation
of the initial frame until after loading the .emacs, tho not if the
initial frame is on a tty).

>>> Let's hear from Stefan & Glenn. Meanwhile, here's the new patch.
>> Not sure what you want to hear from me.
> About installing my patch (disabled by default).

Fine by me.  Maybe we should enable it by default, even.


        Stefan

Re: How to restore the layout?

[martin rudalics]

 > Well, some of them are hardly ignorable, at least for users with many
 > frames, minibuffer-only frames, etc. Also the maximized/fullscreen
 > issue will bother people who usually works with maximized Emacs
 > windows (assuming such people does exist).

I suppose that the set of people using multiple maximized frames is
small so we can ignore the flickering issues in this particular case.

Handling the minibuffer parameter associations OTOH seems tedious: IIUC
we'd have to give each saved window an identity, assign that identity in
`window-state-get', and have the saved frame minibuffer parameters
reference that identity if necessary.  Then we'd have to do a
`set-frame-parameter' to restore the original relationship from saved
identities in `window-state-put'.

martin

Re: How to restore the layout?

[Juanma Barranquero]

On Thu, Jun 27, 2013 at 6:30 AM, Stefan Monnier
<monnier@iro.umontreal.ca> wrote:

> That's not my experience (running a local patch which delays creation
> of the initial frame until after loading the .emacs, tho not if the
> initial frame is on a tty).

In that case, I'd suggest installing that patch.

> Fine by me.  Maybe we should enable it by default, even.

It's a bit rough, let's try with it disabled so volunteers can experiment.

    J

Re: How to restore the layout?

[Juanma Barranquero]

On Thu, Jun 27, 2013 at 10:05 AM, martin rudalics <rudalics@gmx.at> wrote:

> Handling the minibuffer parameter associations OTOH seems tedious: IIUC
> we'd have to give each saved window an identity, assign that identity in
> `window-state-get', and have the saved frame minibuffer parameters
> reference that identity if necessary.  Then we'd have to do a
> `set-frame-parameter' to restore the original relationship from saved
> identities in `window-state-put'.

Yes, it is tedious, but whether it is worth it depends on the users of
unusual minibuffer setups. We want the window save/restore feature to
be as useful and less disruptive as possible.

For example, I think it would be good to also save&restore the
buffer-list (and perhaps buried-buffer-list) parameter(s), to make the
post-restore experience as similar to the pre-save one as possible.
That would be quite tedious, but it is doable.

    J

Re: How to restore the layout?

[martin rudalics]

 > Yes, it is tedious, but whether it is worth it depends on the users of
 > unusual minibuffer setups. We want the window save/restore feature to
 > be as useful and less disruptive as possible.

We'd have to recreate the old window sequence numbers first and make
windows and saved minibuffer frame parameters store these numbers.  The
minibuffer frame parameters would have to be restored after all frames
have been created, from a list associating each new window with its old
sequence number.

 > For example, I think it would be good to also save&restore the
 > buffer-list (and perhaps buried-buffer-list) parameter(s), to make the
 > post-restore experience as similar to the pre-save one as possible.
 > That would be quite tedious, but it is doable.

Here we'd have for each frame/window store the names of the buffers on
these lists and reassign them after the buffers have been recreated.

martin

Re: How to restore the layout?

[Angelo Graziosi]

Juanma Barranquero wrote:
> This is basically the same patch as before, only slightly more
> polished. It's surprisingly functional for its tiny size.
[...]
> All in all, the patch is small and non-intrusive. Perhaps I could
> install it (with desktop-save-windows defaulting to nil) so people
> could experiment and say what works and what doesn't. That would be
> particularly useful from people who use multi-frame setups (Stefan and
> Drew come to mind).
>
> Comments?

I have just bootstrapped Emacs r.113205 and it *does not* restore 
anything... :-( only a single frame and a single window...

Instead your original patch,

> Yes. That's 10 minutes of coding and even less testing. Obviously
> there are many things lacking. I'll come up with something better
> ASAP, I hope.

worked just fine.. it restored all windows of previous session..

So what am I missing? In .emacs.d/init.el I have desktop-save true.. 
what else I need?

BTW, C-h f desktop-save-wi TAB completes in desktop--save-windows, with 
two hyphen between "desktop" and "save"..

TIA,
  Angelo.

Re: How to restore the layout?

[Juanma Barranquero]

On Thu, Jun 27, 2013 at 3:29 PM, Angelo Graziosi
<angelo.graziosi@alice.it> wrote:

> I have just bootstrapped Emacs r.113205 and it *does not* restore
> anything... :-( only a single frame and a single window...

etc/NEWS says:

*** `desktop-save-windows' enables saving and restoring the window/frame
configuration.

so try setting (or customizing) it to t.

> So what am I missing? In .emacs.d/init.el I have desktop-save true.. what
> else I need?

I'd recommend editing the desktop save file and removing by hand the
old window-save variable. In fact it shouldn't cause a problem,
because I renamed it, but the old var is now just cruft.

> BTW, C-h f desktop-save-wi TAB completes in desktop--save-windows, with two
> hyphen between "desktop" and "save"..

Yes. The function desktop--save-windows is internal, hence the two hyphens.

   J

Re: How to restore the layout?

[Angelo Graziosi]

Il 27/06/2013 16.05, Juanma Barranquero ha scritto:
> On Thu, Jun 27, 2013 at 3:29 PM, Angelo Graziosi
> <angelo.graziosi@alice.it> wrote:
>
>> I have just bootstrapped Emacs r.113205 and it *does not* restore
>> anything... :-( only a single frame and a single window...
>
> etc/NEWS says:
>
> *** `desktop-save-windows' enables saving and restoring the window/frame
> configuration.
>
> so try setting (or customizing) it to t.
>
>> So what am I missing? In .emacs.d/init.el I have desktop-save true.. what
>> else I need?
>
> I'd recommend editing the desktop save file and removing by hand the
> old window-save variable. In fact it shouldn't cause a problem,
> because I renamed it, but the old var is now just cruft.

I don't understand here.. In my /~/.emacs.d/init.el I have

;; Instead to save in ~/.emacs.desktop
(setq desktop-base-file-name "~/.emacs.d/desktop")

;; Instead to save in ~/.emacs.desktop.lock
(setq desktop-base-lock-name "~/.emacs.d/desktop.lock")

;; For the moment in Emacs there is an 'illogic'
;; it saves, on desktop file, the flyspell-mode
;; BUT NOT the dictionary with which the buffer
;; is spelled. We have added 'ispell-local-dictionary',
;; as suggested by emacs-devel list, hoping the things
;; is reguralized in the future.
(setq desktop-locals-to-save
       (cons 'ispell-local-dictionary desktop-locals-to-save))

;; Save desktop
(desktop-save-mode t)

and now I have added

(setq desktop-save-windows t)


Which "desktop save file" are you talking about? Perhaps 
"~/.emacs.d/desktop"?

I have tried

$ grep window .emacs.d/desktop

but found anything called "window-save"...

So I am a little confused.

Any way, adding "setq desktop-save-windows t" in my init file seem to work.

I notice only that if I close Emacs (the session) with the frame full 
maximized (the button of the system window activated), the next time I 
restart Emacs (the next session), the frame has almost the same size of 
previous session (just the height one line sorter) but the maximized 
button not active. If I have read correctly this, at the moment, is to 
be expected.

Many thanks for having added this to Emacs!


Ciao,
   Angelo.

Re: How to restore the layout?

[Juanma Barranquero]

On Thu, Jun 27, 2013 at 4:31 PM, Angelo Graziosi
<angelo.graziosi@alice.it> wrote:

> I don't understand here.. In my /~/.emacs.d/init.el I have
>
> ;; Instead to save in ~/.emacs.desktop
> (setq desktop-base-file-name "~/.emacs.d/desktop")
>
> ;; Instead to save in ~/.emacs.desktop.lock
> (setq desktop-base-lock-name "~/.emacs.d/desktop.lock")

OK.

> Which "desktop save file" are you talking about? Perhaps
> "~/.emacs.d/desktop"?

According to your code above, yes.

> I have tried
>
> $ grep window .emacs.d/desktop
>
> but found anything called "window-save"...
>
> So I am a little confused.

It's not really important. If you edit that file, below ;;Global
section: if you see any variable whose name starts with "desktop--"
and it's not "desktop--saved-states" (which is its name now), just
delete it.

> Any way, adding "setq desktop-save-windows t" in my init file seem to work.

I sure hoped so :-)

> I notice only that if I close Emacs (the session) with the frame full
> maximized (the button of the system window activated), the next time I
> restart Emacs (the next session), the frame has almost the same size of
> previous session (just the height one line sorter) but the maximized button
> not active. If I have read correctly this, at the moment, is to be expected.

Yes. I plan to fix it, but I first want advice about getting the
pre-maximized frame size without having to de-maximize and re-maximite
it. For the moment being, saving&restoring maximized/fullscreen frames
is not really supported.

> Many thanks for having added this to Emacs!

Thanks for testing. If you find any other bug or unwanted behavior (as
I'm sure you will), please file a bug report. It's less messy than
endlessly adding to this thread.

    J

Re: How to restore the layout?

[Stefan Monnier]

>> That's not my experience (running a local patch which delays creation
>> of the initial frame until after loading the .emacs, tho not if the
>> initial frame is on a tty).
> In that case, I'd suggest installing that patch.

But that will break many people's .emacs since things like frame-width
won't do the same as before (admittedly, some of those people have already
fixed their .emacs in order to use the daemon, but I still suspect that
many users would be affected).
OTOH we could make it conditional on a cmdline argument or an env-var.

>> Fine by me.  Maybe we should enable it by default, even.
> It's a bit rough, let's try with it disabled so volunteers can experiment.

OK.


        Stefan

Re: How to restore the layout?

[Juanma Barranquero]

On Thu, Jun 27, 2013 at 5:20 PM, Stefan Monnier
<monnier@iro.umontreal.ca> wrote:

> But that will break many people's .emacs since things like frame-width
> won't do the same as before (admittedly, some of those people have already
> fixed their .emacs in order to use the daemon, but I still suspect that
> many users would be affected).

I assumed...

> OTOH we could make it conditional on a cmdline argument or an env-var.

...this (a command line argument).

   J

Re: How to restore the layout?

[martin rudalics]

 > Yes. I plan to fix it, but I first want advice about getting the
 > pre-maximized frame size without having to de-maximize and re-maximite
 > it.

This means one slot for each frame edge ;-)

 > For the moment being, saving&restoring maximized/fullscreen frames
 > is not really supported.

martin

Re: How to restore the layout?

[Juanma Barranquero]

On Thu, Jun 27, 2013 at 8:27 PM, martin rudalics <rudalics@gmx.at> wrote:

> This means one slot for each frame edge ;-)

Is that price too high? :-)

Re: How to restore the layout?

[martin rudalics]

 >> This means one slot for each frame edge ;-)
 >
 > Is that price too high? :-)

On Windows we could use GetWindowPlacement which IIUC reliably gives us
the coordiantes of the normal window.  But Jan will almost certainly
tell us that with some window managers size hints are not trustworthy,
so we'd have to, before each maximize / minimize / fullscreen command,
record the normal coordinates which is also tedious because we'd have
to know for sure that the window _is_ maximized / minimized /
fullscreen.  We could use a frame parameter for systems where we can't
get sizes / positions realiably but all this will likely get tedious.

martin

Re: How to restore the layout?

[Juanma Barranquero]

On Thu, Jun 27, 2013 at 10:49 PM, martin rudalics <rudalics@gmx.at> wrote:

> We could use a frame parameter for systems where we can't
> get sizes / positions realiably but all this will likely get tedious.

Or, we can just document that maximized/fullscreen frames, once
restored via desktop.el, will be created/resized to their default
dimension and then maximized. The user loses their initial size, but
at least gets a non-hostile behavior.

   J

Re: How to restore the layout?

[martin rudalics]

> Or, we can just document that maximized/fullscreen frames, once
> restored via desktop.el, will be created/resized to their default
> dimension and then maximized. The user loses their initial size, but
> at least gets a non-hostile behavior.

I'd obviously prefer such a solution.

martin

Re: How to restore the layout?

[Juanma Barranquero]

On Thu, Jun 27, 2013 at 11:38 AM, martin rudalics <rudalics@gmx.at> wrote:

> We'd have to recreate the old window sequence numbers first and make
> windows and saved minibuffer frame parameters store these numbers.  The
> minibuffer frame parameters would have to be restored after all frames
> have been created, from a list associating each new window with its old
> sequence number.

Seems messy.

> Here we'd have for each frame/window store the names of the buffers on
> these lists and reassign them after the buffers have been recreated.

Why frame/window? Isn't that a frame parameter?

Restoring the frame's buffer-list could be done right now without
really having to change much, other than the format of
desktop--saved-states.

    J

Re: How to restore the layout?

[Juanma Barranquero]

On Thu, Jun 27, 2013 at 11:00 PM, martin rudalics <rudalics@gmx.at> wrote:

> I'd obviously prefer such a solution.

I'm OK with it, too.

   J

Re: How to restore the layout?

[Juanma Barranquero]

A few questions for the experts.

Currently I'm restoring frames in the display they were created.

1.- Is there a way to check from Emacs wheter a given DISPLAY is accessible?

2.- It is acceptable on POSIX systems to try to create X frames if
emacs was started with -nw?

3.- On Windows, after "emacs -nw", creating w32 frames is a no-no.
What is the "correct" or "elegant" way to detect that? Is there
something better than

    (and (eq system-type 'windows-nt) (not window-system))

4.- What about the MS-DOS port? Does it support more than one frame?

   J

Re: How to restore the layout?

[Eli Zaretskii]

> From: Juanma Barranquero <lekktu@gmail.com>
> Date: Fri, 28 Jun 2013 01:33:17 +0200
> Cc: Angelo Graziosi <angelo.graziosi@alice.it>, Emacs developers <emacs-devel@gnu.org>, 
> 	Stefan Monnier <monnier@iro.umontreal.ca>, Eli Zaretskii <eliz@gnu.org>, 
> 	Stephen Berman <stephen.berman@gmx.net>, Jambunathan K <kjambunathan@gmail.com>
> 
> 1.- Is there a way to check from Emacs wheter a given DISPLAY is accessible?

If the experts say there isn't, I'd say catch errors from
make-frame-on-display, display a warning, and be done.

> 2.- It is acceptable on POSIX systems to try to create X frames if
> emacs was started with -nw?

I won't like that, FWIW.

> 3.- On Windows, after "emacs -nw", creating w32 frames is a no-no.
> What is the "correct" or "elegant" way to detect that? Is there
> something better than
> 
>     (and (eq system-type 'windows-nt) (not window-system))

You could use display-graphic-p, of course.

> 4.- What about the MS-DOS port? Does it support more than one frame?

Yes, it does, like any TTY session: all the frames occupy the same
screen space, and only one of them is visible at any given time.

Re: How to restore the layout?

[martin rudalics]

 >> We'd have to recreate the old window sequence numbers first and make
 >> windows and saved minibuffer frame parameters store these numbers.  The
 >> minibuffer frame parameters would have to be restored after all frames
 >> have been created, from a list associating each new window with its old
 >> sequence number.
 >
 > Seems messy.

I'm afraid there's no other way round.  We could save a pointer to a
frame instead which then must either be or have a minibuffer window and
reconstruct the value from that which would be yet a bit more messy.

 >> Here we'd have for each frame/window store the names of the buffers on
 >> these lists and reassign them after the buffers have been recreated.
 >
 > Why frame/window? Isn't that a frame parameter?

Windows have buffer lists too.

 > Restoring the frame's buffer-list could be done right now without
 > really having to change much, other than the format of
 > desktop--saved-states.

We'd still have to translate buffer objects to buffer names when saving
and convert them back when restoring states plus remove any buffers
found dead by `desktop-restore-file-buffer'.

martin

Re: How to restore the layout?

[Jan Djärv]

Hello.

27 jun 2013 kl. 22:49 skrev martin rudalics <rudalics@gmx.at>:

> >> This means one slot for each frame edge ;-)
> >
> > Is that price too high? :-)
> 
> On Windows we could use GetWindowPlacement which IIUC reliably gives us
> the coordiantes of the normal window.  But Jan will almost certainly
> tell us that with some window managers size hints are not trustworthy,
> so we'd have to, before each maximize / minimize / fullscreen command,
> record the normal coordinates which is also tedious because we'd have
> to know for sure that the window _is_ maximized / minimized /
> fullscreen.  We could use a frame parameter for systems where we can't
> get sizes / positions realiably but all this will likely get tedious.
> 

If you are looking for the size/position a window had before i was maximized/fullscreen, there is no such hint.  Hints reflect the current state only.  Hints in general are reliable, as they are well specified.

	Jan D.

Re: How to restore the layout?

[Jan Djärv]

Hello.

28 jun 2013 kl. 08:07 skrev Eli Zaretskii <eliz@gnu.org>:

>> From: Juanma Barranquero <lekktu@gmail.com>
>> Date: Fri, 28 Jun 2013 01:33:17 +0200
>> Cc: Angelo Graziosi <angelo.graziosi@alice.it>, Emacs developers <emacs-devel@gnu.org>, 
>> 	Stefan Monnier <monnier@iro.umontreal.ca>, Eli Zaretskii <eliz@gnu.org>, 
>> 	Stephen Berman <stephen.berman@gmx.net>, Jambunathan K <kjambunathan@gmail.com>
>> 
>> 1.- Is there a way to check from Emacs wheter a given DISPLAY is accessible?
> 
> If the experts say there isn't, I'd say catch errors from
> make-frame-on-display, display a warning, and be done.
> 

XOpenDisplay, but it might take a while to timeout.  From lisp, I guess you have to create a frame, so Eli:s error handling strategy is best.

	Jan D.

Re: How to restore the layout?

[martin rudalics]

 > If you are looking for the size/position a window had before i was
 > maximized/fullscreen, there is no such hint.  Hints reflect the
 > current state only.

Strictly spoken the size/position a window had before
maximizing/minimizing are part of the current state.  At least the
window manager has to remember them somewhere.  Is there a way to get
them otherwise?

 > Hints in general are reliable, as they are well
 > specified.

martin

Re: How to restore the layout?

[Jan Djärv]

Hello.

28 jun 2013 kl. 10:31 skrev martin rudalics <rudalics@gmx.at>:

> > If you are looking for the size/position a window had before i was
> > maximized/fullscreen, there is no such hint.  Hints reflect the
> > current state only.
> 
> Strictly spoken the size/position a window had before
> maximizing/minimizing are part of the current state.  At least the
> window manager has to remember them somewhere.  Is there a way to get
> them otherwise?

Strictly speaking they are not part of the current state, but of some previous state.  X does not differ between maximized, fullscreen or normal windows, they are all just windows.  The window manager makes that distinction, and probably holds that data, but it is private and unacessable.

	Jan D.

Re: How to restore the layout?

[martin rudalics]

 > Strictly speaking they are not part of the current state, but of some
 > previous state.  X does not differ between maximized, fullscreen or
 > normal windows, they are all just windows.  The window manager makes
 > that distinction, and probably holds that data, but it is private and
 > unacessable.

So this means that, as stated earlier, we'd have to remember the
pre-maximize/minimize coordinates ourselves in the frame structure and
update them whenever we minimize/maximize a frame.

martin

Re: How to restore the layout?

[Jan Djärv]

Hello.

28 jun 2013 kl. 11:16 skrev martin rudalics <rudalics@gmx.at>:

> > Strictly speaking they are not part of the current state, but of some
> > previous state.  X does not differ between maximized, fullscreen or
> > normal windows, they are all just windows.  The window manager makes
> > that distinction, and probably holds that data, but it is private and
> > unacessable.
> 
> So this means that, as stated earlier, we'd have to remember the
> pre-maximize/minimize coordinates ourselves in the frame structure and
> update them whenever we minimize/maximize a frame.
> 

It is overkill to to that, just make the frames and maximize/fullscreen them as they where when the desktop was saved.  It is a mistake to try to be a window manager and force frames to exact positions.
For example, a common use case for me is to have multiple monitors at work.  I have some Emacs frames at these monitors.  When I get home, I don't have these monitors, just the laptop screen.  Where does my Emacs frames end up in your scheme when I'm at home?
Offscreen at some unaccessable coordinate?  Better let the window manager deal with this, in most cases it will make these frames visible, which is what I want.

	Jan D.

Re: How to restore the layout?

[martin rudalics]

 > It is overkill to to that, just make the frames and
 > maximize/fullscreen them as they where when the desktop was saved.

Juanma already proposed to use just the default value before maximizing
the frame.

 > It
 > is a mistake to try to be a window manager and force frames to exact
 > positions.  For example, a common use case for me is to have multiple
 > monitors at work.  I have some Emacs frames at these monitors.  When I
 > get home, I don't have these monitors, just the laptop screen.  Where
 > does my Emacs frames end up in your scheme when I'm at home?
 > Offscreen at some unaccessable coordinate?  Better let the window
 > manager deal with this, in most cases it will make these frames
 > visible, which is what I want.

This problem exists independently from whether we want to save prior
positions/sizes since usually we do want to at least restore the sizes
of non-maximized frames.  And in some cases we probably should restore
the positions too - think of an attached speedbar frame.

martin

Re: How to restore the layout?

[Eli Zaretskii]

> From: Jan Djärv <jan.h.d@swipnet.se>
> Date: Fri, 28 Jun 2013 12:01:30 +0200
> Cc: Angelo Graziosi <angelo.graziosi@alice.it>,
>  Juanma Barranquero <lekktu@gmail.com>,
>  Emacs developers <emacs-devel@gnu.org>,
>  Stefan Monnier <monnier@iro.umontreal.ca>,
>  Eli Zaretskii <eliz@gnu.org>,
>  Stephen Berman <stephen.berman@gmx.net>,
>  Jambunathan K <kjambunathan@gmail.com>
> 
> > So this means that, as stated earlier, we'd have to remember the
> > pre-maximize/minimize coordinates ourselves in the frame structure and
> > update them whenever we minimize/maximize a frame.
> > 
> 
> It is overkill to to that, just make the frames and maximize/fullscreen them as they where when the desktop was saved.  It is a mistake to try to be a window manager and force frames to exact positions.

FWIW, I agree.  Maximizing a frame is just one mouse click away, so
going to great length just to restore that is not a good idea,
especially, as Jan points out, it will not be 100% correct anyway.

Just make sure we re-create all those frames, and if they need to be
resized or moved, be it by the window manager or manually, so be it.
It will already be a great improvement from what we had before,
whereby users would have manually recreate every frame.

Re: How to restore the layout?

[Jan Djärv]

Hello.

28 jun 2013 kl. 12:19 skrev martin rudalics <rudalics@gmx.at>:

> > It is overkill to to that, just make the frames and
> > maximize/fullscreen them as they where when the desktop was saved.
> 
> Juanma already proposed to use just the default value before maximizing
> the frame.
> 
> > It
> > is a mistake to try to be a window manager and force frames to exact
> > positions.  For example, a common use case for me is to have multiple
> > monitors at work.  I have some Emacs frames at these monitors.  When I
> > get home, I don't have these monitors, just the laptop screen.  Where
> > does my Emacs frames end up in your scheme when I'm at home?
> > Offscreen at some unaccessable coordinate?  Better let the window
> > manager deal with this, in most cases it will make these frames
> > visible, which is what I want.
> 
> This problem exists independently from whether we want to save prior
> positions/sizes since usually we do want to at least restore the sizes
> of non-maximized frames.  And in some cases we probably should restore
> the positions too - think of an attached speedbar frame.


Yes.  So I guess you have to implement a smallish window manager to get this right, i.e. handle resolution that differs from the one saved, when previous visible frames vould now be invisible, handle frames that spanned multiple monitors, but those monitors anre no longer available, and so on.  This is a hard problem.

	Jan D.

Re: How to restore the layout?

[Juanma Barranquero]

On Fri, Jun 28, 2013 at 8:07 AM, Eli Zaretskii <eliz@gnu.org> wrote:

> If the experts say there isn't, I'd say catch errors from
> make-frame-on-display, display a warning, and be done.

Agreed, that's good enough.

>> 2.- It is acceptable on POSIX systems to try to create X frames if
>> emacs was started with -nw?
>
> I won't like that, FWIW.

Isn't the POSIX Emacs already able to create both kinds of frames? I
mean, leaving aside the current issue with desktop.el, if you do this:

   emacs -nw
   M-: (make-frame-on-display ":0.0") <RET>

on a POSIX Emacs, does it create an X frame?

>>     (and (eq system-type 'windows-nt) (not window-system))
>
> You could use display-graphic-p, of course.

Yes, I thought of that, but I'm trying to distinguish between the
Windows port (where creating a w32 frame in a non-windowed Emacs is A
Really Bad Idea, see bug#14739), and the POSIX one (where both kinds
of frames are simultaneously supported). Currently we discourage
checking for window-system, and system-type does not tell you whether
you're running in -nw mode.

>> 4.- What about the MS-DOS port? Does it support more than one frame?
>
> Yes, it does, like any TTY session: all the frames occupy the same
> screen space, and only one of them is visible at any given time.

OK. At some point, once the dust is settled, we'll have to test this
desktop stuff to make sure it does the right thing.

   J

Re: How to restore the layout?

[martin rudalics]

 > FWIW, I agree.  Maximizing a frame is just one mouse click away, so
 > going to great length just to restore that is not a good idea,
 > especially, as Jan points out, it will not be 100% correct anyway.

This is not about maximizing but about demaximizing a maximized frame
after it has been maximized by desktop.  The question was whether this
could/should restore the normal frame size of the previous session.  We
already earlier agreed with Juanma that this will only restore the
default frame size of the present session.

 > Just make sure we re-create all those frames, and if they need to be
 > resized or moved, be it by the window manager or manually, so be it.
 > It will already be a great improvement from what we had before,
 > whereby users would have manually recreate every frame.

I think we should do what can be done easily, like restoring the last
previous sizes (as Juanma does already).

martin

Re: How to restore the layout?

[martin rudalics]

 > Yes.  So I guess you have to implement a smallish window manager to
 > get this right, i.e. handle resolution that differs from the one
 > saved, when previous visible frames vould now be invisible, handle
 > frames that spanned multiple monitors, but those monitors anre no
 > longer available, and so on.  This is a hard problem.

Indeed.  In a first step, the desktop changes will mostly address people
who resume a session on one and the same machine.  When machines differ,
all sort of things may have to be adapted.

martin

Re: How to restore the layout?

[Juanma Barranquero]

On Fri, Jun 28, 2013 at 8:34 AM, martin rudalics <rudalics@gmx.at> wrote:

> I'm afraid there's no other way round.  We could save a pointer to a
> frame instead which then must either be or have a minibuffer window and
> reconstruct the value from that which would be yet a bit more messy.

Let's wait and see whether that's really necessary.

> We'd still have to translate buffer objects to buffer names when saving
> and convert them back when restoring states plus remove any buffers
> found dead by `desktop-restore-file-buffer'.

For frames buffer-lists, I can do that quite easily. For windows
buffer-lists, you'd have to do that in the window-store-(get|put) or
provide some kind of hook to do it afterwards. It is really worth it?
All this save&restore does not really restore the full Emacs session
you were before. Hmm.

    J

Re: How to restore the layout?

[Juanma Barranquero]

On Fri, Jun 28, 2013 at 10:17 AM, Jan Djärv <jan.h.d@swipnet.se> wrote:

> From lisp, I guess you have to create a frame, so Eli:s error handling strategy is best.

Understood. Thanks.

   J

Re: How to restore the layout?

[Juanma Barranquero]

On Fri, Jun 28, 2013 at 12:01 PM, Jan Djärv <jan.h.d@swipnet.se> wrote:

> It is overkill to to that, just make the frames and maximize/fullscreen them
> as they where when the desktop was saved.  It is a mistake to try to be a
> window manager and force frames to exact positions.

What you call a mistake, I call the main thing that would make the
save&restore feature worth using for me. I don't want frames restored
if they are not at the same place they were before.

> For example, a common use case for me is to have multiple monitors at work.
> I have some Emacs frames at these monitors.  When I get home, I don't have
> these monitors, just the laptop screen.  Where does my Emacs frames end
> up in your scheme when I'm at home? Offscreen at some unaccessable coordinate?

This is an interesting use case which we will have to deal with at
some point. But I'm sure the more common use case will be people using
s&r in the same computer with the same setup. If we don't save the
frame sizes and positions (and, if posible, max/full state) you can
bet we'll get an endless stream of bug reports (not wishlist
enhancements, but bug reports) about that behavior. I would personally
file the first one.

    J

Re: How to restore the layout?

[Juanma Barranquero]

On Fri, Jun 28, 2013 at 12:19 PM, martin rudalics <rudalics@gmx.at> wrote:

> Juanma already proposed to use just the default value before maximizing
> the frame.

Yes, I think that's the easiest way to offer a reasonable behavior.

> This problem exists independently from whether we want to save prior
> positions/sizes since usually we do want to at least restore the sizes
> of non-maximized frames.

We do not *want* to restore the sizes, we *must* restore the sizes.
Otherwise, if I have a frame with lots & lots of tiny windows and I
try to restore it in a default-sized frame, restoring will fail for
lack of space or for trying to bypass the safe minimum width/height.
And that's exactly the kind of frame I would be pretty pissed off to
have to rebuild by hand because s&r failed...

>  And in some cases we probably should restore
> the positions too - think of an attached speedbar frame.

As I said in a previous message, "some cases" = "all cases" for me. If
people wants to allow that to be customizable, fine, we can add such
an option.

   J

Re: How to restore the layout?

[Juanma Barranquero]

On Fri, Jun 28, 2013 at 12:22 PM, Eli Zaretskii <eliz@gnu.org> wrote:

> FWIW, I agree.  Maximizing a frame is just one mouse click away, so
> going to great length just to restore that is not a good idea,
> especially, as Jan points out, it will not be 100% correct anyway.

If we can get it to be correct 95% of time, that's a net gain. I
certainly don't want to throw the towel without trying to make it work
first.

> Just make sure we re-create all those frames, and if they need to be
> resized or moved, be it by the window manager or manually, so be it.
> It will already be a great improvement from what we had before,
> whereby users would have manually recreate every frame.

For some users/use cases, not for others. We can add an option, and
even make it default if people insists, but not as the only behavior.

   J

Re: How to restore the layout?

[Juanma Barranquero]

On Fri, Jun 28, 2013 at 1:50 PM, martin rudalics <rudalics@gmx.at> wrote:

> This is not about maximizing but about demaximizing a maximized frame
> after it has been maximized by desktop.  The question was whether this
> could/should restore the normal frame size of the previous session.  We
> already earlier agreed with Juanma that this will only restore the
> default frame size of the present session.

Yes.

There's also the issue that, if we don't put the frame at the previous
position, maximized frames (not fullscreen ones, I think) can be
positioned so they are not fully visible.

> I think we should do what can be done easily, like restoring the last
> previous sizes (as Juanma does already).

Sizes & positions are equally easy, full/max frames aside.

   J

Re: How to restore the layout?

[Angelo Graziosi]

Juanma, martin, Eli, Jan D., etc. wrote
 > a lot of discussion...

I am testing this new desktop.el (r. 113206 on Cygwin, r. 113207 on 
Kubuntu) and the behavior of frame restoring, even if not perfect, is 
very very good. Usually it is restored almost full screen, just a line 
shorter in height (the width is full screen). I would not spent much 
work to re-gain a line that the user can do with just a click on 
maximizing button.

Perhaps in a second time, one could consider how to restore the frames 
perfectly... :-)


Anyway, thanks a lot for this new desktop.el..

Ciao,
  Angelo.

Re: How to restore the layout?

[Jan Djärv]

28 jun 2013 kl. 14:00 skrev Juanma Barranquero <lekktu@gmail.com>:

> On Fri, Jun 28, 2013 at 12:01 PM, Jan Djärv <jan.h.d@swipnet.se> wrote:
> 
>> It is overkill to to that, just make the frames and maximize/fullscreen them
>> as they where when the desktop was saved.  It is a mistake to try to be a
>> window manager and force frames to exact positions.
> 
> What you call a mistake, I call the main thing that would make the
> save&restore feature worth using for me. I don't want frames restored
> if they are not at the same place they were before.

This pertains just to maximized/fullscreen/minimized frames.  The best strategy (for X anyway) is to create non-maximized/non-fullscreen frames where there where saved and let the window manager move them if it so wishes.  

Maximized/fullscreen frames should be created with the corresponding frame parameter, and don't try to first create them where there where in their un-maximized/un-fullscreen state and then make them maximized/fullscreen.  I don't know if it is different on W32, but maximized/fullscreen is not about setting some size, it is about setting a state.  The window manager sets the size.  So if I saved a maximized frame on a small monitor, it will be maximized when i restore the desktop on a larger monitor.  The window manager takes care of it, Emacs does not need to emulate a window manager.

	Jan D.

Re: How to restore the layout?

[Eli Zaretskii]

> From: Jan Djärv <jan.h.d@swipnet.se>
> Date: Fri, 28 Jun 2013 12:26:47 +0200
> Cc: Angelo Graziosi <angelo.graziosi@alice.it>,
>  Juanma Barranquero <lekktu@gmail.com>,
>  Emacs developers <emacs-devel@gnu.org>,
>  Stefan Monnier <monnier@iro.umontreal.ca>,
>  Eli Zaretskii <eliz@gnu.org>,
>  Stephen Berman <stephen.berman@gmx.net>,
>  Jambunathan K <kjambunathan@gmail.com>
> 
> So I guess you have to implement a smallish window manager to get this right, i.e. handle resolution that differs from the one saved, when previous visible frames vould now be invisible, handle frames that spanned multiple monitors, but those monitors anre no longer available, and so on.  This is a hard problem.

I see no need for anything as complicated as this.  Just restore each
frame to their recorder size if possible, and let it have some other
size (determined by the window manager) if not.

Re: How to restore the layout?

[Eli Zaretskii]

> Date: Fri, 28 Jun 2013 13:50:17 +0200
> From: martin rudalics <rudalics@gmx.at>
> CC: Jan Djärv <jan.h.d@swipnet.se>, 
>  angelo.graziosi@alice.it, lekktu@gmail.com, emacs-devel@gnu.org, 
>  monnier@iro.umontreal.ca, stephen.berman@gmx.net, 
>  kjambunathan@gmail.com
> 
> We already earlier agreed with Juanma that this will only restore
> the default frame size of the present session.

Then there are no more problems (and I don't understand what was that
discussion about, but I don't have to).

>  > Just make sure we re-create all those frames, and if they need to be
>  > resized or moved, be it by the window manager or manually, so be it.
>  > It will already be a great improvement from what we had before,
>  > whereby users would have manually recreate every frame.
> 
> I think we should do what can be done easily, like restoring the last
> previous sizes (as Juanma does already).

If they can be restored, yes.  If they can't, leave them at the size
the window manager manages to produce.

Re: How to restore the layout?

[Eli Zaretskii]

> From: Juanma Barranquero <lekktu@gmail.com>
> Date: Fri, 28 Jun 2013 14:05:32 +0200
> Cc: Jan Djärv <jan.h.d@swipnet.se>, 
> 	Angelo Graziosi <angelo.graziosi@alice.it>, Emacs developers <emacs-devel@gnu.org>, 
> 	Stefan Monnier <monnier@iro.umontreal.ca>, Eli Zaretskii <eliz@gnu.org>, 
> 	Stephen Berman <stephen.berman@gmx.net>, Jambunathan K <kjambunathan@gmail.com>
> 
> We do not *want* to restore the sizes, we *must* restore the sizes.
> Otherwise, if I have a frame with lots & lots of tiny windows and I
> try to restore it in a default-sized frame, restoring will fail for
> lack of space or for trying to bypass the safe minimum width/height.
> And that's exactly the kind of frame I would be pretty pissed off to
> have to rebuild by hand because s&r failed...

Restoring the session is not supposed to be 100% reliable.  It can't.
The existing code already fails to restore some buffers, if their
files disappeared, for example.  You should do the same with windows
and frames: make a good-faith effort to restore them, and if you
can't, display a message and move on.

> As I said in a previous message, "some cases" = "all cases" for me. If
> people wants to allow that to be customizable, fine, we can add such
> an option.

It's not about being customizable, it's about avoiding the "perfect"
solution (which doesn't exist).

Re: How to restore the layout?

[Eli Zaretskii]

> From: Juanma Barranquero <lekktu@gmail.com>
> Date: Fri, 28 Jun 2013 14:08:57 +0200
> Cc: Jan Djärv <jan.h.d@swipnet.se>, 
> 	martin rudalics <rudalics@gmx.at>, Angelo Graziosi <angelo.graziosi@alice.it>, 
> 	Emacs developers <emacs-devel@gnu.org>, Stefan Monnier <monnier@iro.umontreal.ca>, 
> 	Stephen Berman <stephen.berman@gmx.net>, Jambunathan K <kjambunathan@gmail.com>
> 
> > Just make sure we re-create all those frames, and if they need to be
> > resized or moved, be it by the window manager or manually, so be it.
> > It will already be a great improvement from what we had before,
> > whereby users would have manually recreate every frame.
> 
> For some users/use cases, not for others.

Please give examples of uses where what I suggest would be profoundly
wrong or nonsensical.

Re: How to restore the layout?

[Juanma Barranquero]

On Fri, Jun 28, 2013 at 2:31 PM, Jan Djärv <jan.h.d@swipnet.se> wrote:

> So if I saved a maximized frame on a small monitor, it will be maximized when
> i restore the desktop on a larger monitor.  The window manager takes care of it,
> Emacs does not need to emulate a window manager.

As Martin already said, this is about what to do when de-maximized.
The current code doe not remove the fullscreen parameter from the
frame parameters' list, so when restoring the frame, it does not
decide its size or position. The window manager does.

There's also the issue that you can have fullwidth or fullheight
frames. For these, keeping the height or width, respectively, is
important because you want to restore them to the full widht or height
(the window manager should take care of it), but to the height / width
they had before.

    J

Re: How to restore the layout?

[Juanma Barranquero]

On Fri, Jun 28, 2013 at 3:06 PM, Eli Zaretskii <eliz@gnu.org> wrote:

> Restoring the session is not supposed to be 100% reliable.  It can't.

Of course.

> You should do the same with windows
> and frames: make a good-faith effort to restore them, and if you
> can't, display a message and move on.

Agreed. And trying to make them the same width / height / position is
a good-faith effort. Trying to do less is not good-faith, it's just
sloppy.

> It's not about being customizable, it's about avoiding the "perfect"
> solution (which doesn't exist).

Sorry, no. I'm not trying to find the perfect solution; if I were, I
wouldn't have committed the current code, which is far from perfect.
It's about trying to find ways to satisfy most users, for some value
of "most" preferably >= 90%. So in the end, whether you think that
restoring the size *and* position is necessary or not (to the extent
that is is *possible* in the first place, of course) is really a
matter of opinion and taste, and so, customization.

    J

RE: How to restore the layout?

[Drew Adams]

>  > Strictly speaking they are not part of the current state, but of some
>  > previous state.  X does not differ between maximized, fullscreen or
>  > normal windows, they are all just windows.  The window manager makes
>  > that distinction, and probably holds that data, but it is private and
>  > unacessable.
> 
> So this means that, as stated earlier, we'd have to remember the
> pre-maximize/minimize coordinates ourselves in the frame structure and
> update them whenever we minimize/maximize a frame.

FWIW, that is what I do in frame-cmds.el.  The frame maximization there
is not a real maximization (it just fills the available screen, keeping
borders, title etc.).  But it does record the current parameters before
doing that, so toggling it restores the original size, position, etc.

Of course, such recording is done only by the (my) Emacs maximize-frame
function; it is not done if the frame is maximized in another way, 
outside Emacs.

But yes, it would be good to be able to capture the window mgr info
for restoring.

http://www.emacswiki.org/emacs-en/download/frame-cmds.el

Re: How to restore the layout?

[Juanma Barranquero]

On Fri, Jun 28, 2013 at 3:07 PM, Eli Zaretskii <eliz@gnu.org> wrote:

> Please give examples of uses where what I suggest would be profoundly
> wrong or nonsensical.

I cannot give examples where it would be nonsensical. As for wrong,
perhaps a video of me throwing the computer out the window in a fit of
screaming murdering rage when the frames fail to restore to their
intended positions would give you and idea of how some people would
take your suggestion of "if they need to be resized or moved, so be
it". Again, tastes, everyone has theirs. I do not, very strong
emphasis on "not", want an Emacs that restores frames to whatever
place/size the Windows window manager fancies to put them.

If you think I'm being overly dramatic, well... Yes. I'm trying to get
across my point that I do not find the "just restore and let defaults
be defaults" attitude useful in this case, as the ONLY option. As ONE
option, sure, why not.

    J

Re: How to restore the layout?

[martin rudalics]

 >> I'm afraid there's no other way round.  We could save a pointer to a
 >> frame instead which then must either be or have a minibuffer window and
 >> reconstruct the value from that which would be yet a bit more messy.
 >
 > Let's wait and see whether that's really necessary.

Good.  We can always add that later on.

 >> We'd still have to translate buffer objects to buffer names when saving
 >> and convert them back when restoring states plus remove any buffers
 >> found dead by `desktop-restore-file-buffer'.
 >
 > For frames buffer-lists, I can do that quite easily. For windows
 > buffer-lists, you'd have to do that in the window-store-(get|put) or
 > provide some kind of hook to do it afterwards. It is really worth it?
 > All this save&restore does not really restore the full Emacs session
 > you were before. Hmm.

That's why so far I didn't consider buffer lists in `window-state-get'.
I hope we can disregard them.

martin

Re: How to restore the layout?

[martin rudalics]

 >> It is overkill to to that, just make the frames and maximize/fullscreen them
 >> as they where when the desktop was saved.  It is a mistake to try to be a
 >> window manager and force frames to exact positions.
 >
 > What you call a mistake, I call the main thing that would make the
 > save&restore feature worth using for me. I don't want frames restored
 > if they are not at the same place they were before.

While I agree with you, Jan has a point: Forcing an exact position might
move the Emacs window to a place occupied by another application.

 >> For example, a common use case for me is to have multiple monitors at work.
 >> I have some Emacs frames at these monitors.  When I get home, I don't have
 >> these monitors, just the laptop screen.  Where does my Emacs frames end
 >> up in your scheme when I'm at home? Offscreen at some unaccessable coordinate?
 >
 > This is an interesting use case which we will have to deal with at
 > some point. But I'm sure the more common use case will be people using
 > s&r in the same computer with the same setup. If we don't save the
 > frame sizes and positions (and, if posible, max/full state) you can
 > bet we'll get an endless stream of bug reports (not wishlist
 > enhancements, but bug reports) about that behavior.

I think so too.

 > I would personally
 > file the first one.

martin

Re: How to restore the layout?

[martin rudalics]

 > We do not *want* to restore the sizes, we *must* restore the sizes.
 > Otherwise, if I have a frame with lots & lots of tiny windows and I
 > try to restore it in a default-sized frame, restoring will fail for
 > lack of space or for trying to bypass the safe minimum width/height.

Indeed.  I wanted to mention that in my reply but forgot.

 > And that's exactly the kind of frame I would be pretty pissed off to
 > have to rebuild by hand because s&r failed...
 >
 >>  And in some cases we probably should restore
 >> the positions too - think of an attached speedbar frame.
 >
 > As I said in a previous message, "some cases" = "all cases" for me. If
 > people wants to allow that to be customizable, fine, we can add such
 > an option.

We probably can't restore them with a tiling window manager.  But such
cases are special.

martin

Re: How to restore the layout?

[martin rudalics]

 > Maximized/fullscreen frames should be created with the corresponding
 > frame parameter, and don't try to first create them where there where
 > in their un-maximized/un-fullscreen state and then make them
 > maximized/fullscreen.  I don't know if it is different on W32, but
 > maximized/fullscreen is not about setting some size, it is about
 > setting a state.  The window manager sets the size.  So if I saved a
 > maximized frame on a small monitor, it will be maximized when i
 > restore the desktop on a larger monitor.  The window manager takes
 > care of it, Emacs does not need to emulate a window manager.

Let me try to recapitulate: The problem is what to do when saving and
restoring a maximized frame.  We can't get the location/size it had
before maximizing it easily, so Juanma's proposal goes as follows.

(1) Create the frame _ignoring_ the saved size/location related frame
     parameters.

(2) Ask the window manager to maximize the frame.

When the user now demaximizes the frame, it will appear at its default
location with a default size.  Does this match what you stated above?

martin

Re: How to restore the layout?

[martin rudalics]

 > I see no need for anything as complicated as this.  Just restore each
 > frame to their recorder size if possible, and let it have some other
 > size (determined by the window manager) if not.

This would mean that a maximized frame occupies the entire screen after
it has been demaximized.

martin

Re: How to restore the layout?

[martin rudalics]

 >> We already earlier agreed with Juanma that this will only restore
 >> the default frame size of the present session.
 >
 > Then there are no more problems (and I don't understand what was that
 > discussion about, but I don't have to).

We discussed whether we could do any better without too much overhead.

 >> I think we should do what can be done easily, like restoring the last
 >> previous sizes (as Juanma does already).
 >
 > If they can be restored, yes.  If they can't, leave them at the size
 > the window manager manages to produce.

Restoring the "size" is not overly difficult.  With pixelwise resizing
it should be even precise.  What we cannot do easily is restoring the
"state" as Jan calls it.  In particular, the state where the window
manager remembers (and subsequently can restore) the normal size of a
maximized frame.

martin

Re: How to restore the layout?

[Jan Djärv]

Hello.

28 jun 2013 kl. 15:18 skrev Juanma Barranquero <lekktu@gmail.com>:

> There's also the issue that you can have fullwidth or fullheight
> frames. For these, keeping the height or width, respectively, is
> important because you want to restore them to the full widht or height
> (the window manager should take care of it), but to the height / width
> they had before.

Your sentence is not clear to me.  Do you mean that fullwidth/height should not be restored to fullwidth/height if restored on a different monitor, or do you mean that they should be restored to fullwidth/height?  
If the former, I disagree.  If I said fullheight, I expect fullheight, not the amount of pixels fullheight just happend to be on one monitor.
If the latter, we agree.

	Jan D.

Re: How to restore the layout?

[Eli Zaretskii]

> From: Juanma Barranquero <lekktu@gmail.com>
> Date: Fri, 28 Jun 2013 15:22:38 +0200
> Cc: martin rudalics <rudalics@gmx.at>, jan.h.d@swipnet.se, 
> 	Angelo Graziosi <angelo.graziosi@alice.it>, Emacs developers <emacs-devel@gnu.org>, 
> 	Stefan Monnier <monnier@iro.umontreal.ca>, Stephen Berman <stephen.berman@gmx.net>, 
> 	Jambunathan K <kjambunathan@gmail.com>
> 
> On Fri, Jun 28, 2013 at 3:06 PM, Eli Zaretskii <eliz@gnu.org> wrote:
> 
> > It's not about being customizable, it's about avoiding the "perfect"
> > solution (which doesn't exist).
> 
> Sorry, no. I'm not trying to find the perfect solution; if I were, I
> wouldn't have committed the current code, which is far from perfect.
> It's about trying to find ways to satisfy most users, for some value
> of "most" preferably >= 90%. So in the end, whether you think that
> restoring the size *and* position is necessary or not (to the extent
> that is is *possible* in the first place, of course) is really a
> matter of opinion and taste, and so, customization.

It is not necessary, although it is desirable.  Which means if it's
too damn hard, don't bother, just punt and display a message.
Therefore, customization will not help here, because what's it gonna
tell you? "try harder"?

Re: How to restore the layout?

[Eli Zaretskii]

> From: Juanma Barranquero <lekktu@gmail.com>
> Date: Fri, 28 Jun 2013 15:29:32 +0200
> Cc: jan.h.d@swipnet.se, martin rudalics <rudalics@gmx.at>, 
> 	Angelo Graziosi <angelo.graziosi@alice.it>, Emacs developers <emacs-devel@gnu.org>, 
> 	Stefan Monnier <monnier@iro.umontreal.ca>, Stephen Berman <stephen.berman@gmx.net>, 
> 	Jambunathan K <kjambunathan@gmail.com>
> 
> I'm trying to get across my point that I do not find the "just
> restore and let defaults be defaults" attitude useful in this case,

That's not what I said.  I said try restoring it, but don't go to too
great lengths if it fails; in the latter case, just let the defaults
do their job.

Re: How to restore the layout?

[Eli Zaretskii]

> Date: Fri, 28 Jun 2013 16:03:49 +0200
> From: martin rudalics <rudalics@gmx.at>
> CC: Jan Djärv <jan.h.d@swipnet.se>, 
>  angelo.graziosi@alice.it, lekktu@gmail.com, emacs-devel@gnu.org, 
>  monnier@iro.umontreal.ca, stephen.berman@gmx.net, 
>  kjambunathan@gmail.com
> 
>  > I see no need for anything as complicated as this.  Just restore each
>  > frame to their recorder size if possible, and let it have some other
>  > size (determined by the window manager) if not.
> 
> This would mean that a maximized frame occupies the entire screen after
> it has been demaximized.

Sorry, I cannot parse this.  If the frame is maximized, it _should_
occupy the entire screen.  If it is not, then where's the problem?

Are we still talking about how frames will look after desktop-read
does its thing?

Re: How to restore the layout?

[Eli Zaretskii]

> Date: Fri, 28 Jun 2013 16:07:52 +0200
> From: martin rudalics <rudalics@gmx.at>
> Cc: jan.h.d@swipnet.se, angelo.graziosi@alice.it, lekktu@gmail.com,
> 	emacs-devel@gnu.org, monnier@iro.umontreal.ca,
> 	stephen.berman@gmx.net, kjambunathan@gmail.com
> 
> Restoring the "size" is not overly difficult.  With pixelwise resizing
> it should be even precise.  What we cannot do easily is restoring the
> "state" as Jan calls it.

Then don't.

Re: How to restore the layout?

[Juanma Barranquero]

On Fri, Jun 28, 2013 at 4:58 PM, Eli Zaretskii <eliz@gnu.org> wrote:

>> This would mean that a maximized frame occupies the entire screen after
>> it has been demaximized.
>
> Sorry, I cannot parse this.  If the frame is maximized, it _should_
> occupy the entire screen.  If it is not, then where's the problem?

Read again: "after it has been demaximized".

You start with a 80x35 frame, maximize (let's say, 250x50 is the max
size), save, restore. The frame is now 250x50 maximized, and 250x50
de-maximized. That's ugly. If we cannot get back to 80x35, at the very
least let's get default width/height.

> Are we still talking about how frames will look after desktop-read
> does its thing?

Yes.

   J

Re: How to restore the layout?

[Juanma Barranquero]

On Fri, Jun 28, 2013 at 4:02 PM, martin rudalics <rudalics@gmx.at> wrote:

> While I agree with you, Jan has a point: Forcing an exact position might
> move the Emacs window to a place occupied by another application.

Why is that a problem? Do you mean that letting the window manager
create & size the frame wouldn't ever put it in a place occupied by
another application?

   J

Re: How to restore the layout?

[Juanma Barranquero]

On Fri, Jun 28, 2013 at 4:03 PM, martin rudalics <rudalics@gmx.at> wrote:

> We probably can't restore them with a tiling window manager.  But such
> cases are special.

Yes, we know we won't get a 100% succesful answer. Some cases will
have to be left for the user to deal with (via hooks or whatever).

   J

Re: How to restore the layout?

[Jan Djärv]

Hi.

28 jun 2013 kl. 16:03 skrev martin rudalics <rudalics@gmx.at>:

> Let me try to recapitulate: The problem is what to do when saving and
> restoring a maximized frame.  We can't get the location/size it had
> before maximizing it easily, so Juanma's proposal goes as follows.
> 
> (1) Create the frame _ignoring_ the saved size/location related frame
>    parameters.
> 
> (2) Ask the window manager to maximize the frame.
> 
> When the user now demaximizes the frame, it will appear at its default
> location with a default size.  Does this match what you stated above?

Yes, except 1 and 2 are the same operation if the frame is created with the appropriate frame parameter.  The size/location info for the frame is ignored, so you don't really have to special case it so as not to set it.

	Jan D.

Re: How to restore the layout?

[Juanma Barranquero]

On Fri, Jun 28, 2013 at 4:03 PM, martin rudalics <rudalics@gmx.at> wrote:

> (1) Create the frame _ignoring_ the saved size/location related frame
>     parameters.

With the caveat that for fullwidth frames we don't want to ignore the
height, and for fullheight frames we don't want to ignore the width.
Else the s&r process will not respect sizes for these frames.

   J

Re: How to restore the layout?

[Juanma Barranquero]

On Fri, Jun 28, 2013 at 4:26 PM, Jan Djärv <jan.h.d@swipnet.se> wrote:

> Your sentence is not clear to me.

Sometimes they're not clear even to me. After such barrage of
messages, all dealing with the same issue, I've typed "fullscreen" and
"frame" so many times that I'm starting to suffer semantic
satiation...

> do you mean that they should be restored to fullwidth/height?

I do mean that they should be restored to fullwidth/height, and that
their recorded height/width, respectively, must also be restored. In
fact, I think that's how it works right now.

    J

Re: How to restore the layout?

[Juanma Barranquero]

On Fri, Jun 28, 2013 at 4:51 PM, Eli Zaretskii <eliz@gnu.org> wrote:

> It is not necessary, although it is desirable.

I clearly disagree.

> Which means if it's too damn hard, don't bother, just punt and display
> a message. Therefore, customization will not help here, because what's
> it gonna tell you? "try harder"?

If you assume that it won't work, of course customization doesn't make
sense. As I assume that it will work in many cases, the option I'm
suggesting to offer is "Do you want to try to restore frame sizes &
positions, even if not guaranteed to work on 100% of cases, or are you
happy with letting the window manager destr... rearrange things for
you?".

    J

Re: How to restore the layout?

[Jan Djärv]

Hi.

28 jun 2013 kl. 16:03 skrev martin rudalics <rudalics@gmx.at>:

> > I see no need for anything as complicated as this.  Just restore each
> > frame to their recorder size if possible, and let it have some other
> > size (determined by the window manager) if not.
> 
> This would mean that a maximized frame occupies the entire screen after
> it has been demaximized.

This is not true for many X window managers.  It will take the user or program size, specified at startup, and demaximize to that.  Emacs sets the program size to the size in the frame parameters when creating a frame.

So when I do:

(make-frame '((fullscreen . maximized)))

and de-maximize it, it comes out as a frame with geometry 80x32.  Of course, the position is whatever the WM chooses.  This is not a formal protocol of how window managers should behave, but many do it like this.

	Jan D.

Re: How to restore the layout?

[Juanma Barranquero]

On Fri, Jun 28, 2013 at 4:53 PM, Eli Zaretskii <eliz@gnu.org> wrote:

> That's not what I said.  I said try restoring it, but don't go to too
> great lengths if it fails; in the latter case, just let the defaults
> do their job.

Then we violently agree, except perhaps on defining what does cover
the expresson "too great lenghts".

    J

Re: How to restore the layout?

[Juanma Barranquero]

On Fri, Jun 28, 2013 at 5:22 PM, Jan Djärv <jan.h.d@swipnet.se> wrote:

> So when I do:
>
> (make-frame '((fullscreen . maximized)))
>
> and de-maximize it, it comes out as a frame with geometry 80x32.

That's not what happens on Windows. In fact, on Emacs for Windows,
(fullscreen . maximized) is decoupled from the window manager
"mazimized" state. With emacs- Q I get 80x38 frames by default, but
after (make-frame '((fullscreen . maximized))) I get a frame that uses
the full screen (minus the taskbar), but that is not really maximized
(it has borders, for example). Clicking on the maximize/restore button
does maximized it, according to the window manager definition (and
clicking again brings it back to its non-maximized, but
full-screen-covering previous size).

OTOH, (make-frame '((fullscreen . fullscreen))) does indeed work as
you describe; M-x toggle-frame-fullscreen gives a default, 80x38
frame.

    J

Re: How to restore the layout?

[Jan Djärv]

Hello.

28 jun 2013 kl. 17:32 skrev Juanma Barranquero <lekktu@gmail.com>:

> On Fri, Jun 28, 2013 at 5:22 PM, Jan Djärv <jan.h.d@swipnet.se> wrote:
> 
>> So when I do:
>> 
>> (make-frame '((fullscreen . maximized)))
>> 
>> and de-maximize it, it comes out as a frame with geometry 80x32.
> 
> That's not what happens on Windows. In fact, on Emacs for Windows,
> (fullscreen . maximized) is decoupled from the window manager
> "mazimized" state. With emacs- Q I get 80x38 frames by default, but
> after (make-frame '((fullscreen . maximized))) I get a frame that uses
> the full screen (minus the taskbar), but that is not really maximized
> (it has borders, for example). Clicking on the maximize/restore button
> does maximized it, according to the window manager definition (and
> clicking again brings it back to its non-maximized, but
> full-screen-covering previous size).
> 
> OTOH, (make-frame '((fullscreen . fullscreen))) does indeed work as
> you describe; M-x toggle-frame-fullscreen gives a default, 80x38
> frame.

The W32 behaviour is also seen on NS.  To bad the X way isn't universal.

	Jan D.

Re: How to restore the layout?

[martin rudalics]

> Why is that a problem? Do you mean that letting the window manager
> create & size the frame wouldn't ever put it in a place occupied by
> another application?

Yes, unless it has run out of pixels.  Here I get an offset of some
20 pixels in both directions when creating a new frame.  Not a great
deal, obviously.

martin

Re: How to restore the layout?

[Stefan Monnier]

>> 2.- It is acceptable on POSIX systems to try to create X frames if
>> emacs was started with -nw?
> I won't like that, FWIW.

And more generally, it's probably better to avoid opening frames on
other displays/terminals than "the current one".  OTOH it might make
sense to open the same windows&frames even if "the current display" is
different from the one last time.


        Stefan

Re: How to restore the layout?

[Juanma Barranquero]

On Fri, Jun 28, 2013 at 7:22 PM, Stefan Monnier
<monnier@iro.umontreal.ca> wrote:

> And more generally, it's probably better to avoid opening frames on
> other displays/terminals than "the current one".

Why? If the user had them open in other displays, and then saved the
session, why/how would be better not to restore them as they were?

> OTOH it might make
> sense to open the same windows&frames even if "the current display" is
> different from the one last time.

Yes. But how to choose what to do? Both behaviors are reasonable.

   J

Re: How to restore the layout?

[Eli Zaretskii]

> From: Juanma Barranquero <lekktu@gmail.com>
> Date: Fri, 28 Jun 2013 17:22:18 +0200
> Cc: martin rudalics <rudalics@gmx.at>, jan.h.d@swipnet.se, 
> 	Angelo Graziosi <angelo.graziosi@alice.it>, Emacs developers <emacs-devel@gnu.org>, 
> 	Stefan Monnier <monnier@iro.umontreal.ca>, Stephen Berman <stephen.berman@gmx.net>, 
> 	Jambunathan K <kjambunathan@gmail.com>
> 
> the option I'm suggesting to offer is "Do you want to try to restore
> frame sizes & positions, even if not guaranteed to work on 100% of
> cases, or are you happy with letting the window manager
> destr... rearrange things for you?".

Who'd want to choose the latter?

Re: How to restore the layout?

[Eli Zaretskii]

> From: Juanma Barranquero <lekktu@gmail.com>
> Date: Fri, 28 Jun 2013 17:06:49 +0200
> Cc: martin rudalics <rudalics@gmx.at>, jan.h.d@swipnet.se, 
> 	Angelo Graziosi <angelo.graziosi@alice.it>, Emacs developers <emacs-devel@gnu.org>, 
> 	Stefan Monnier <monnier@iro.umontreal.ca>, Stephen Berman <stephen.berman@gmx.net>, 
> 	Jambunathan K <kjambunathan@gmail.com>
> 
> You start with a 80x35 frame, maximize (let's say, 250x50 is the max
> size), save, restore. The frame is now 250x50 maximized, and 250x50
> de-maximized. That's ugly. If we cannot get back to 80x35, at the very
> least let's get default width/height.

That's what I meant: use the default size, then maximize.

Re: How to restore the layout?

[Eli Zaretskii]

> From: Juanma Barranquero <lekktu@gmail.com>
> Date: Fri, 28 Jun 2013 13:48:10 +0200
> Cc: martin rudalics <rudalics@gmx.at>, Angelo Graziosi <angelo.graziosi@alice.it>, 
> 	Emacs developers <emacs-devel@gnu.org>, Stefan Monnier <monnier@iro.umontreal.ca>, 
> 	Stephen Berman <stephen.berman@gmx.net>, Jambunathan K <kjambunathan@gmail.com>
> 
> Isn't the POSIX Emacs already able to create both kinds of frames? I
> mean, leaving aside the current issue with desktop.el, if you do this:
> 
>    emacs -nw
>    M-: (make-frame-on-display ":0.0") <RET>
> 
> on a POSIX Emacs, does it create an X frame?

I don't know, and don't have a way of trying that.

> >>     (and (eq system-type 'windows-nt) (not window-system))
> >
> > You could use display-graphic-p, of course.
> 
> Yes, I thought of that, but I'm trying to distinguish between the
> Windows port (where creating a w32 frame in a non-windowed Emacs is A
> Really Bad Idea, see bug#14739), and the POSIX one (where both kinds
> of frames are simultaneously supported). Currently we discourage
> checking for window-system, and system-type does not tell you whether
> you're running in -nw mode.

I meant use display-graphic-p instead of window-system.

Re: How to restore the layout?

[Stefan Monnier]

>> emacs -nw
>> M-: (make-frame-on-display ":0.0") <RET>
>> on a POSIX Emacs, does it create an X frame?

Yes.


        Stefan

Re: How to restore the layout?

[Stefan Monnier]

>> And more generally, it's probably better to avoid opening frames on
>> other displays/terminals than "the current one".
> Why? If the user had them open in other displays, and then saved the
> session, why/how would be better not to restore them as they were?

It all depends on the use-case, but my own use cases, frames on other
displays/terminals are always "temporary frames" I created via
emacsclient so as to access remotely the state of a running Emacs.

>> OTOH it might make sense to open the same windows&frames even if "the
>> current display" is different from the one last time.
> Yes. But how to choose what to do? Both behaviors are reasonable.

I suggest you start with "only use the current display" (at least for
the non-daemon mode), since it's a kind of halfway step between the
previous behavior (which did not save&restore the window&frame state)
and the "restore the state on all the displays".


        Stefan

Re: How to restore the layout?

[Juanma Barranquero]

On Fri, Jun 28, 2013 at 7:52 PM, Eli Zaretskii <eliz@gnu.org> wrote:

> Who'd want to choose the latter?

Jan, if I understood him correctly. Or anyone who thinks that
restoring the old position will cause trouble (by obscuring another
application, or moving the frames outside the current display, etc.)

   J

Re: How to restore the layout?

[Juanma Barranquero]

On Fri, Jun 28, 2013 at 7:53 PM, Eli Zaretskii <eliz@gnu.org> wrote:

> That's what I meant: use the default size, then maximize.

That's what Martin and I have been proposing all along.

I have code to do that, but there's a weird issue with fullheight
frames that I'm trying to sort out.

    J

Re: How to restore the layout?

[Juanma Barranquero]

On Fri, Jun 28, 2013 at 9:36 PM, Stefan Monnier
<monnier@iro.umontreal.ca> wrote:

> It all depends on the use-case, but my own use cases, frames on other
> displays/terminals are always "temporary frames" I created via
> emacsclient so as to access remotely the state of a running Emacs.

The question is, what is the more common use-case?

> I suggest you start with "only use the current display" (at least for
> the non-daemon mode), since it's a kind of halfway step between the
> previous behavior (which did not save&restore the window&frame state)
> and the "restore the state on all the displays".

The other behavior (try to restore the frame in its original display)
is already implemented. I can remove that code, but I wouldn't like to
do it unless there are reports of trouble.

It could be customized, of course. We could change the meaning of
desktop-save-windows (currently a boolean flag), to have:

- t : restore all frames in their displays
- local-state: only frames already in the current display
- current-display: restore frames in the current display

etc. (with better names)

    j

Re: How to restore the layout?

[Stephen Leake]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Juanma Barranquero <lekktu@gmail.com>
>> Date: Fri, 28 Jun 2013 14:08:57 +0200
>> Cc: Jan Djärv <jan.h.d@swipnet.se>, 
>> 	martin rudalics <rudalics@gmx.at>, Angelo Graziosi <angelo.graziosi@alice.it>, 
>> 	Emacs developers <emacs-devel@gnu.org>, Stefan Monnier
>> <monnier@iro.umontreal.ca>,
>> 	Stephen Berman <stephen.berman@gmx.net>, Jambunathan K <kjambunathan@gmail.com>
>> 
>> > Just make sure we re-create all those frames, and if they need to be
>> > resized or moved, be it by the window manager or manually, so be it.
>> > It will already be a great improvement from what we had before,
>> > whereby users would have manually recreate every frame.
>> 
>> For some users/use cases, not for others.
>
> Please give examples of uses where what I suggest would be profoundly
> wrong or nonsensical.

I would consider it a serious bug if Emacs did not restore frame
positions in "restore desktop".

-- 
-- Stephe

Re: How to restore the layout?

[Eli Zaretskii]

> From: Stephen Leake <stephen_leake@member.fsf.org>
> Date: Sat, 29 Jun 2013 04:03:02 -0400
> 
> >> > Just make sure we re-create all those frames, and if they need to be
> >> > resized or moved, be it by the window manager or manually, so be it.
> >> > It will already be a great improvement from what we had before,
> >> > whereby users would have manually recreate every frame.
> >> 
> >> For some users/use cases, not for others.
> >
> > Please give examples of uses where what I suggest would be profoundly
> > wrong or nonsensical.
> 
> I would consider it a serious bug if Emacs did not restore frame
> positions in "restore desktop".

So do you also consider it a "serious bug" when today's desktop fails
to restore buffers, because their files disappeared or moved?

Re: How to restore the layout?

[martin rudalics]

 > It could be customized, of course. We could change the meaning of
 > desktop-save-windows (currently a boolean flag), to have:
 >
 > - t : restore all frames in their displays
 > - local-state: only frames already in the current display
 > - current-display: restore frames in the current display
 >
 > etc. (with better names)

I think we should do that.  We probably should also rename the basic
option to `desktop-restore-frames' and include an option for frame
positioning/sizing where the latter could assume values like 'accurate
or 'sloppy with 'accurate trying to restore positions and sizes as
accurately as possible, while 'sloppy could, for example, try to
reposition and/or resize frames so they fit a new screen dimension.

martin

Re: How to restore the layout?

[Stephen Leake]

Juanma Barranquero <lekktu@gmail.com> writes:

> On Fri, Jun 28, 2013 at 7:52 PM, Eli Zaretskii <eliz@gnu.org> wrote:
>
>> Who'd want to choose the latter?
>
> Jan, if I understood him correctly. Or anyone who thinks that
> restoring the old position will cause trouble (by obscuring another
> application, or moving the frames outside the current display, etc.)

Moving the frame outside the current display is an issue; it would be
nice if the restore could detect that, and keep the frames in view.

-- 
-- Stephe

Re: How to restore the layout?

[Stephen Leake]

Juanma Barranquero <lekktu@gmail.com> writes:

> On Fri, Jun 28, 2013 at 12:01 PM, Jan Djärv <jan.h.d@swipnet.se> wrote:
>
>> It is overkill to to that, just make the frames and maximize/fullscreen them
>> as they where when the desktop was saved.  It is a mistake to try to be a
>> window manager and force frames to exact positions.
>
> What you call a mistake, I call the main thing that would make the
> save&restore feature worth using for me. I don't want frames restored
> if they are not at the same place they were before.

+1

I have multiple frames that fill one monitor; it's easier to navigate
between frames than among lots of Emacs windows in one frame, but I also
want too see everything at once.

-- 
-- Stephe

Re: How to restore the layout?

[Stephen Leake]

martin rudalics <rudalics@gmx.at> writes:

>> Yes.  So I guess you have to implement a smallish window manager to
>> get this right, i.e. handle resolution that differs from the one
>> saved, when previous visible frames vould now be invisible, handle
>> frames that spanned multiple monitors, but those monitors anre no
>> longer available, and so on.  This is a hard problem.
>
> Indeed.  In a first step, the desktop changes will mostly address people
> who resume a session on one and the same machine.  When machines differ,
> all sort of things may have to be adapted.

I would prefer the restore operation to abort with a message "saved info
is for a different display configuration".

The next step would be to keep several saved configurations, and present
a menu of which one to restore (one for laptop only, one for laptop plus
home monitor, one for work monitor).

However, it is not easy to detect the monitor setup. On MS windows,
laptop + monitor is just one big display, and you can have windows at
negative positions (which breaks all kinds of assumptions!).

-- 
-- Stephe

Re: How to restore the layout?

[Stephen Leake]

Juanma Barranquero <lekktu@gmail.com> writes:

> On Fri, Jun 28, 2013 at 7:22 PM, Stefan Monnier
> <monnier@iro.umontreal.ca> wrote:
>
>> And more generally, it's probably better to avoid opening frames on
>> other displays/terminals than "the current one".
>
> Why? If the user had them open in other displays, and then saved the
> session, why/how would be better not to restore them as they were?
>
>> OTOH it might make
>> sense to open the same windows&frames even if "the current display" is
>> different from the one last time.
>
> Yes. But how to choose what to do? Both behaviors are reasonable.

Prompt the user.

and/or provide a user option to override the prompt.

-- 
-- Stephe

Re: How to restore the layout?

[chad]

On 29 Jun 2013, at 01:51, Stephen Leake <stephen_leake@member.fsf.org> wrote:

> Prompt the user.

From what frame?

~Chad

Re: How to restore the layout?

[Eli Zaretskii]

> From: chad <yandros@MIT.EDU>
> Date: Sat, 29 Jun 2013 11:00:42 -0700
> Cc: emacs-devel@gnu.org
> 
> On 29 Jun 2013, at 01:51, Stephen Leake <stephen_leake@member.fsf.org> wrote:
> 
> > Prompt the user.
> 
> From what frame?

The active minibuffer is always the one of the current frame.

Re: How to restore the layout?

[Juanma Barranquero]

On Sat, Jun 29, 2013 at 10:29 AM, martin rudalics <rudalics@gmx.at> wrote:

> We probably should also rename the basic
> option to `desktop-restore-frames'

I'm OK with that, or any other name, as long as there's some consensus
and we don't have to change it too many times ;-)

> and include an option for frame
> positioning/sizing where the latter could assume values like 'accurate
> or 'sloppy with 'accurate trying to restore positions and sizes as
> accurately as possible, while 'sloppy could, for example, try to
> reposition and/or resize frames so they fit a new screen dimension.

I don't see how that could be integrated with
desktop-save-windows/desktop-restore-frames options that I proposed.
Seems like a different configuration option to me (unless you want to
multiply the available options: all-frames-and-displays-accurate,
all-frames-and-displays-sloppy, local-state-accurate,
local-state-sloppy, current-display-accurate, current-display-sloppy.
Is that what you're suggesting (leaving aside the precise option
names, of course)?

    J

Re: How to restore the layout?

[Juanma Barranquero]

On Sat, Jun 29, 2013 at 10:39 AM, Stephen Leake
<stephen_leake@member.fsf.org> wrote:

> Moving the frame outside the current display is an issue; it would be
> nice if the restore could detect that, and keep the frames in view.

How can I do that? Is there any way to get from Emacs the maximum
dimensions of a frame in the current display, other than

(let ((frame (make-frame '((fullscreen . maximized)))))
  (prog1
      (cons (frame-width frame) (frame-height frame))
    (delete-frame frame)))

which has the downside of being noticeable to the user?

   J

>
> --
> -- Stephe
>

Re: How to restore the layout?

[Juanma Barranquero]

On Sat, Jun 29, 2013 at 10:47 AM, Stephen Leake
<stephen_leake@member.fsf.org> wrote:

> I would prefer the restore operation to abort with a message "saved info
> is for a different display configuration".

That leaves us with the problem of defining what a "display configuration" is.

> The next step would be to keep several saved configurations, and present
> a menu of which one to restore (one for laptop only, one for laptop plus
> home monitor, one for work monitor).

You can already save & restore different configurations by saving
different desktops.

   J

Re: How to restore the layout?

[Juanma Barranquero]

On Sat, Jun 29, 2013 at 10:51 AM, Stephen Leake
<stephen_leake@member.fsf.org> wrote:

> Prompt the user.

Not so sure. If you invoke desktop-read interactively, it could make
sense (or we could add an argument, so C-u M-x desktop-read selects
the alternate behavior). But in the most common case, which is (likely
to be) running desktop-read from after-init-hook (which is
automatically done now if you enable desktop-mode), I don't think
asking the user is the way to go. Far from it.

> and/or provide a user option to override the prompt.

Yeah.

    J

RE: How to restore the layout?

[Drew Adams]

> > Moving the frame outside the current display is an issue; it would be
> > nice if the restore could detect that, and keep the frames in view.
> 
> How can I do that? Is there any way to get from Emacs the maximum
> dimensions of a frame in the current display, other than
> 
> (let ((frame (make-frame '((fullscreen . maximized)))))
>   (prog1
>       (cons (frame-width frame) (frame-height frame))
>     (delete-frame frame)))
> 
> which has the downside of being noticeable to the user?

Dunno whether it helps, but this is what I do in frame-cmds.el,
to determine the screen space available for positioning and
resizing frames, e.g., for moving them about or tiling them.

1. Provide a user option, `available-screen-pixel-bounds', which
defaults to nil and otherwise is a list of the pixel coordinates
of the upper left and the lower right corners of the available
screen space, measured from screen absolute origin, (0, 0), at
the upper left.

For example,  (x0 y0 x1 y1), where (x0, y0) is the upper left
position and (x1, y1) is the lower right position.

2. If the option is nil then the available space is calculated
by the function with the same name.  It tries to return the
currently available screen area.  The option is available to
let you declare some known outside area off limits (e.g., the MS
Windows task bar).

(defun available-screen-pixel-bounds ()
  (or available-screen-pixel-bounds
      (if (fboundp 'mac-display-available-pixel-bounds) ; Mac-OS
          (mac-display-available-pixel-bounds)
        (list 0 0 (x-display-pixel-width)
                  (x-display-pixel-height)))))

3. Function `effective-screen-pixel-bounds' starts with
`available-screen-pixel-bounds' and removes the space used by
the standalone minibuffer frame of oneonone.el:

(defun effective-screen-pixel-bounds ()
  (if (boundp '1on1-minibuffer-frame)
      (append
       (butlast (available-screen-pixel-bounds))
       (list
        (frame-geom-value-numeric
         'top (cdr (assq 'top (frame-parameters
                               1on1-minibuffer-frame))))))
    (available-screen-pixel-bounds)))

[`frame-geom-value-numeric' returns a numeric value (pixels)
 that is equivalent to a frame geometry spec.  Examples: 

  Assuming display height/width=1024, frame height/width=600:
  300 inside display edge:                   300  =>  300
                                         (+  300) =>  300
  300 inside opposite display edge:      (-  300) => -300
                                            -300  => -300
  300 beyond display edge
   (= 724 inside opposite display edge): (+ -300) => -724
  300 beyond display edge
   (= 724 inside opposite display edge): (- -300) =>  724

 In the last two examples, the returned value is relative to the
 opposite frame edge from the edge indicated in the input spec.]

Again, dunno whether such an approach helps you.  It is based on
`x-display-pixel-(width|height)'.  Whether that helps when using
multiple monitors etc., I'm not sure.  The idea of letting users
override an available-space calculation might be something to
consider, at least.

4. In the same library, frame-cmds.el, I have commands that
move a frame incrementally up/down/left/right.  You can easily
move a frame off the display that way, so you no longer see it.
Or you can move it back onto the display, if off.

There is a user option, `move-frame-wrap-within-display-flag',
that determines whether continuing to move a frame in some
direction brings it back around from the opposite screen border,
i.e., wraps the movement so the frame comes back onto the display.
If the option is nil then you can keep moving a frame as far off
the display as you like.

IIRC, with multiple displays, moving a frame off of one display
can move it onto another.

HTH.

Re: How to restore the layout?

[Jan Djärv]

Hello.

30 jun 2013 kl. 00:18 skrev Juanma Barranquero <lekktu@gmail.com>:

> On Sat, Jun 29, 2013 at 10:39 AM, Stephen Leake
> <stephen_leake@member.fsf.org> wrote:
> 
>> Moving the frame outside the current display is an issue; it would be
>> nice if the restore could detect that, and keep the frames in view.
> 
> How can I do that? Is there any way to get from Emacs the maximum
> dimensions of a frame in the current display, other than
> 
> (let ((frame (make-frame '((fullscreen . maximized)))))
>  (prog1
>      (cons (frame-width frame) (frame-height frame))
>    (delete-frame frame)))
> 
> which has the downside of being noticeable to the user?
> 

Take a look at display-monitor-attributes-list.

	Jan D.

Re: How to restore the layout?

[martin rudalics]

 > I don't see how that could be integrated with
 > desktop-save-windows/desktop-restore-frames options that I proposed.
 > Seems like a different configuration option to me

I think we already need at least two different configuration options,
one for the sizes/coordinates and one for the displays/monitors.  That's
why I think that we shouldn't have `desktop-save-windows' handle the
monitor/display stuff itself.  Just keep it boolean forever and any
remaining options can be added later on when we need them.

 > (unless you want to
 > multiply the available options: all-frames-and-displays-accurate,
 > all-frames-and-displays-sloppy, local-state-accurate,
 > local-state-sloppy, current-display-accurate, current-display-sloppy.
 > Is that what you're suggesting (leaving aside the precise option
 > names, of course)?

Certainly not.

martin

Re: How to restore the layout?

[martin rudalics]

 > Take a look at display-monitor-attributes-list.

I intend to add a SystemParametersInfo (SPI_GETWORKAREA, ...) call on
Windows so we get the workarea there too.  But I'm not yet sure whether
to write a `w32-display-monitor-attributes-list' for that purpose.

martin

Re: How to restore the layout?

[Jan Djärv]

Hello.

30 jun 2013 kl. 11:35 skrev martin rudalics <rudalics@gmx.at>:

> > Take a look at display-monitor-attributes-list.
> 
> I intend to add a SystemParametersInfo (SPI_GETWORKAREA, ...) call on
> Windows so we get the workarea there too.  But I'm not yet sure whether
> to write a `w32-display-monitor-attributes-list' for that purpose.

YAMAMOTO Mitsuharu started on something for W32 here:
http://lists.gnu.org/archive/html/emacs-devel/2013-05/msg00193.html

	Jan D.

Re: How to restore the layout?

[martin rudalics]

> YAMAMOTO Mitsuharu started on something for W32 here:
> http://lists.gnu.org/archive/html/emacs-devel/2013-05/msg00193.html

Thanks.  Juanma can you take a look at this?  Here it doesn't
apply :-(

martin

Re: How to restore the layout?

[Juanma Barranquero]

On Sun, Jun 30, 2013 at 1:48 AM, Drew Adams <drew.adams@oracle.com> wrote:

> Again, dunno whether such an approach helps you.

I think that's adding complexity to desktop.el that does not really
belongs there.

>  It is based on
> `x-display-pixel-(width|height)'.  Whether that helps when using
> multiple monitors etc.,

Calculating the available area on Windows with multiple monitors is
always going to give trouble, because all "screen space" is contiguous,
yet not all coordinates point to visible space.

   J

Re: How to restore the layout?

[Juanma Barranquero]

On Sun, Jun 30, 2013 at 9:51 AM, Jan Djärv <jan.h.d@swipnet.se> wrote:

> Take a look at display-monitor-attributes-list.

Thanks, I didn't know about that one.

It could be useful for checking the frame's (potential) visibility,
because getting the frame-pixel-{width|height} is already possible. Of
course there's still the issue of multiple monitors.

   J

Re: How to restore the layout?

[Juanma Barranquero]

On Sun, Jun 30, 2013 at 11:35 AM, martin rudalics <rudalics@gmx.at> wrote:

> I think we already need at least two different configuration options,
> one for the sizes/coordinates and one for the displays/monitors.  That's
> why I think that we shouldn't have `desktop-save-windows' handle the
> monitor/display stuff itself.  Just keep it boolean forever and any
> remaining options can be added later on when we need them.

Sorry, you lost me here. I proposed turning desktop-save-windows into
a multi-valued custom, and you agreed. I suppose that means you
changed your mind?

Also, you proposed to rename the option to desktop-restore-frames,
and/or do you propose now to reserve that name for the
"display/monitors" option you're suggesting?

I'm not arguing for/against anything, just trying to understand what
is being suggested, exactly.

   J

Re: How to restore the layout?

[Juanma Barranquero]

On Sun, Jun 30, 2013 at 12:11 PM, martin rudalics <rudalics@gmx.at> wrote:

> Thanks.  Juanma can you take a look at this?  Here it doesn't
> apply :-(

I'll look into it later today.

    J

Re: How to restore the layout?

[martin rudalics]

 > Sorry, you lost me here. I proposed turning desktop-save-windows into
 > a multi-valued custom, and you agreed. I suppose that means you
 > changed your mind?

I'm still uncertain what would be best.

 > Also, you proposed to rename the option to desktop-restore-frames,
 > and/or do you propose now to reserve that name for the
 > "display/monitors" option you're suggesting?
 >
 > I'm not arguing for/against anything, just trying to understand what
 > is being suggested, exactly.

I'd vote for one basic option called `desktop-restore-frames' because
I'd probably always save windows and frames (virtually everything that
could be useful) and leave it to the restoration routine to decide
whether and which items shall be restored.  This option should be
boolean in order to not confuse users too much and I would probably turn
it on by default.

Other options should be added when we see that we need them.  Two
candidates we have discussed so far are what I would call
`desktop-restore-frame-positions' where possible values are to do that
as accurately as possible (with the potential for failure) and less
accurately, leaving the decision mainly to the window manager.  The
other option would be something like `desktop-restore-frame-displays' to
specify whether we should try to restore frames on multiple monitors and
the like.

But I have no really strong opinion and preferably leave the decision to
you.

martin

Re: How to restore the layout?

[martin rudalics]

 > It could be useful for checking the frame's (potential) visibility,
 > because getting the frame-pixel-{width|height} is already possible.

The workarea is much better for determining the rectangle within which
our frames should appear.  I intended to make it available via an extra
function but obviously Yamamoto's patch would be preferable.

 > Of
 > course there's still the issue of multiple monitors.

Wouldn't we get these via EnumDisplayDevices?

martin

Re: How to restore the layout?

[Stephen Leake]

Juanma Barranquero <lekktu@gmail.com> writes:

> On Sat, Jun 29, 2013 at 10:39 AM, Stephen Leake
> <stephen_leake@member.fsf.org> wrote:
>
>> Moving the frame outside the current display is an issue; it would be
>> nice if the restore could detect that, and keep the frames in view.
>
> How can I do that? Is there any way to get from Emacs the maximum
> dimensions of a frame in the current display, 

(display-pixel-height)
(display-pixel-width)

-- 
-- Stephe

Re: How to restore the layout?

[Stephen Leake]

Juanma Barranquero <lekktu@gmail.com> writes:

> On Sat, Jun 29, 2013 at 10:47 AM, Stephen Leake
> <stephen_leake@member.fsf.org> wrote:
>
>> I would prefer the restore operation to abort with a message "saved info
>> is for a different display configuration".
>
> That leaves us with the problem of defining what a "display
> configuration" is.

A user name associated with a display size would work for a single
display.

I don't know how to detect multiple displays (I don't use any systems
that have that).

>> The next step would be to keep several saved configurations, and present
>> a menu of which one to restore (one for laptop only, one for laptop plus
>> home monitor, one for work monitor).
>
> You can already save & restore different configurations by saving
> different desktops.

That should be sufficient. The user can then choose the desktop to
restore based on their knowledge of the display config.

-- 
-- Stephe

Re: How to restore the layout?

[Stephen Leake]

Juanma Barranquero <lekktu@gmail.com> writes:

> On Sat, Jun 29, 2013 at 10:51 AM, Stephen Leake
> <stephen_leake@member.fsf.org> wrote:
>
>> Prompt the user.
>
> Not so sure. If you invoke desktop-read interactively, it could make
> sense (or we could add an argument, so C-u M-x desktop-read selects
> the alternate behavior). But in the most common case, which is (likely
> to be) running desktop-read from after-init-hook (which is
> automatically done now if you enable desktop-mode), I don't think
> asking the user is the way to go. Far from it.

Can you elaborate? what is wrong with prompting the user from
after-init-hook?

The doc for after-init-hook says it is run "after initializing the Emacs
session". It does not mention displays, so I assume the default display
is available for prompting the user.

-- 
-- Stephe

Re: How to restore the layout?

[Stephen Leake]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Stephen Leake <stephen_leake@member.fsf.org>
>> Date: Sat, 29 Jun 2013 04:03:02 -0400
>> 
>> >> > Just make sure we re-create all those frames, and if they need to be
>> >> > resized or moved, be it by the window manager or manually, so be it.
>> >> > It will already be a great improvement from what we had before,
>> >> > whereby users would have manually recreate every frame.
>> >> 
>> >> For some users/use cases, not for others.
>> >
>> > Please give examples of uses where what I suggest would be profoundly
>> > wrong or nonsensical.
>> 
>> I would consider it a serious bug if Emacs did not restore frame
>> positions in "restore desktop".
>
> So do you also consider it a "serious bug" when today's desktop fails
> to restore buffers, because their files disappeared or moved?

No, moving or deleting those files outside Emacs is a user action, so
the user should expect that.

On the other hand, I carefully set up my Emacs frame config, so I expect
it to be restored when I save and restore the desktop.

-- 
-- Stephe

Re: How to restore the layout?

[Eli Zaretskii]

> From: Stephen Leake <stephen_leake@member.fsf.org>
> Date: Sun, 30 Jun 2013 11:23:02 -0400
> 
> Juanma Barranquero <lekktu@gmail.com> writes:
> 
> > On Sat, Jun 29, 2013 at 10:39 AM, Stephen Leake
> > <stephen_leake@member.fsf.org> wrote:
> >
> >> Moving the frame outside the current display is an issue; it would be
> >> nice if the restore could detect that, and keep the frames in view.
> >
> > How can I do that? Is there any way to get from Emacs the maximum
> > dimensions of a frame in the current display, 
> 
> (display-pixel-height)
> (display-pixel-width)

Doesn't this disregards the size of the frame decorations?

Re: How to restore the layout?

[Eli Zaretskii]

> From: Stephen Leake <stephen_leake@member.fsf.org>
> Date: Sun, 30 Jun 2013 11:29:31 -0400
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> I would consider it a serious bug if Emacs did not restore frame
> >> positions in "restore desktop".
> >
> > So do you also consider it a "serious bug" when today's desktop fails
> > to restore buffers, because their files disappeared or moved?
> 
> No, moving or deleting those files outside Emacs is a user action, so
> the user should expect that.

So is invoking Emacs from a different display.  Also, files could
disappear due to reasons other than user actions.

> On the other hand, I carefully set up my Emacs frame config, so I expect
> it to be restored when I save and restore the desktop.

That wasn't the issue.  The issue was whether it would be fatal if we
tried to restore, but failed.  Like with buffers whose files
disappeared.

RE: How to restore the layout?

[Drew Adams]

> > Again, dunno whether such an approach helps you.
> 
> I think that's adding complexity to desktop.el that does not really
> belongs there.

I was not suggesting adding any such code to desktop.el.  It was
an FYI/FWIW about how I determine available screen space, and a
suggestion to consider letting users override whatever available
space we calculate.

> >  It is based on `x-display-pixel-(width|height)'.  Whether that
> > helps when using multiple monitors etc., I'm not sure.
> 
> Calculating the available area on Windows with multiple monitors is
> always going to give trouble, because all "screen space" is
> contiguous, yet not all coordinates point to visible space.

`x-display-pixel-(width|height)' was all that was available at
the time I wrote that code, AFAIK.

And I too was not aware of the Emacs 24.4 addition of
`display-monitor-attributes-list' and `frame-monitor-attributes'.
Sounds like you are now getting some of the info that you need,
in any case.

Re: How to restore the layout?

[Juanma Barranquero]

On Sun, Jun 30, 2013 at 2:55 PM, martin rudalics <rudalics@gmx.at> wrote:

> I'm still uncertain what would be best.

OK So do I.

> I'd vote for one basic option called `desktop-restore-frames' because
> I'd probably always save windows and frames (virtually everything that
> could be useful) and leave it to the restoration routine to decide
> whether and which items shall be restored.  This option should be
> boolean in order to not confuse users too much and I would probably turn
> it on by default.

Agreed.

> Other options should be added when we see that we need them.  Two
> candidates we have discussed so far are what I would call
> `desktop-restore-frame-positions' where possible values are to do that
> as accurately as possible (with the potential for failure) and less
> accurately, leaving the decision mainly to the window manager.  The
> other option would be something like `desktop-restore-frame-displays' to
> specify whether we should try to restore frames on multiple monitors and
> the like.

I still don't see much use for desktop-restore-frame-positions. On one
hand, if you s&r in the same display (which I naïvely assume is the
most common use case), positions and sizes are preserved and removing
that info to let the window manager do its thing is a bit strange,
and, as discussed before, it could fail for some frame configurations
with small windows. On the other hand, if you restore in a different
display, or a different monitor size, that's a problem that we should
try to solve, even if only partially, regardless of any user option
setting... desktop-restore-frame-displays makes more sense because
there are already users who prefer it that way (like Stefan).

   Juanma

Re: How to restore the layout?

[Juanma Barranquero]

On Sun, Jun 30, 2013 at 2:55 PM, martin rudalics <rudalics@gmx.at> wrote:

> The workarea is much better for determining the rectangle within which
> our frames should appear.  I intended to make it available via an extra
> function but obviously Yamamoto's patch would be preferable.

Yes, understood.

> Wouldn't we get these via EnumDisplayDevices?

I'm not sure what kind of Lisp-level API are you envisioning. But my
comment was in reference to the fact that, on Windows, if you have
multiple displays of varying sizes, they are contiguous but the
visible area is not, generally speaking, a rectangle. There are gaps.

At this point, I'd be very grateful if people could explain what kind
of behavior are they suggesting with respect to frames that fall
wholly or partially outside a visible screen area. I mean, I don't
want to write (because I don't think that belongs into desktop.el) an
elisp window manager which will detect that the display size, or the
number of monitors, has changed, and that will try to resize the
frames to fit them like a puzzle in the current display. That's a case
whose failure mode IMHO should simply be to try and make sure that
frame captions (to allow grabbing and moving the frame) fall inside
their displays.

But perhaps other potential users have different expectations, and if
so, please comment them.

   Juanma



>
> martin

Re: How to restore the layout?

[Juanma Barranquero]

[Stephen, you're answering to this thread from an email address that
does not accept email delivery.]

On Sun, Jun 30, 2013 at 5:25 PM, Stephen Leake
<stephen_leake@member.fsf.org> wrote:
> Juanma Barranquero <lekktu@gmail.com> writes:

> A user name associated with a display size would work for a single
> display.
>
> I don't know how to detect multiple displays (I don't use any systems
> that have that).
[...]
> That should be sufficient. The user can then choose the desktop to
> restore based on their knowledge of the display config.

Currently you can only save different desktops on different
directories, or play games with desktop names. Generalizing desktop.el
to support saving several desktop "sessions" is another project
altogether (search in the Emacs wiki for "desktops as bookmarks").

   J

Re: How to restore the layout?

[Juanma Barranquero]

On Sun, Jun 30, 2013 at 5:27 PM, Stephen Leake
<stephen_leake@member.fsf.org> wrote:

> Can you elaborate? what is wrong with prompting the user from
> after-init-hook?

Is unexpected and rude. We have many packages that save & restore
state, and none of them asks the user while Emacs is starting up. That
does not mean that it can't/shouldn't be done, just that it should be
an option for users who like that kind of interaction. I expect my
Emacs to get to a fully usable status by itself, without my
interaction.

> The doc for after-init-hook says it is run "after initializing the Emacs
> session". It does not mention displays, so I assume the default display
> is available for prompting the user.

Yes, I'm not talking about technical issues, but UI ones.

    J

Re: How to restore the layout?

[Juanma Barranquero]

On Sun, Jun 30, 2013 at 6:30 PM, Drew Adams <drew.adams@oracle.com> wrote:

> I was not suggesting adding any such code to desktop.el.

Yes, I understood that.

> It was
> an FYI/FWIW about how I determine available screen space, and a
> suggestion to consider letting users override whatever available
> space we calculate.

And I'm saying that we're trying to cram much complexity into
desktop.el for what should be much simpler: can you restore as saved?
Yes? Restore. No? Try to find a way of not making a disaster and let
the user sort the pieces.

   J

Re: How to restore the layout?

[Jan Djärv]

Hello. 

30 jun 2013 kl. 20:03 skrev Juanma Barranquero <lekktu@gmail.com>:

> 
> At this point, I'd be very grateful if people could explain what kind
> of behavior are they suggesting with respect to frames that fall
> wholly or partially outside a visible screen area. I mean, I don't
> want to write (because I don't think that belongs into desktop.el) an
> elisp window manager which will detect that the display size, or the
> number of monitors, has changed, and that will try to resize the
> frames to fit them like a puzzle in the current display. That's a case
> whose failure mode IMHO should simply be to try and make sure that
> frame captions (to allow grabbing and moving the frame) fall inside
> their displays.
> 

I would expect that if a saved frame position is not available, the frame would be recreated at some default position, i.e. let the window manager deside. 

If the position is available, I'd expect the frame to be recreated there even if the size might no longer fit (the monitor is smaller). Some window managers will resize the frame to fit, so Emacs should not bother to try to fit the size. 

    Jan D. 

Re: How to restore the layout?

[Juanma Barranquero]

On Sun, Jun 30, 2013 at 11:32 PM, Jan Djärv <jan.h.d@swipnet.se> wrote:

> I would expect that if a saved frame position is not available, the frame would be recreated at some default position, i.e. let the window manager deside.
>
> If the position is available, I'd expect the frame to be recreated there even if the size might no longer fit (the monitor is smaller). Some window managers will resize the frame to fit, so Emacs should not bother to try to fit the size.

That's more or less what I'm trying to do, modulo detecting that "a
saved frame position is not available".

   J

Re: How to restore the layout?

[Juanma Barranquero]

I've pushed a new patch. It renames the restore option to
desktop-restore-frames, adds a new one
desktop-restore-in-current-display, and includes a few bugfixes.

In particular, on Windows:

- Save in GUI mode
- Restore in -nw mode
- Save in -nw mode
- Restore in GUI mode

does work more or less reasonably. I've been forced to filter out the
font frame parameter because it didn't really survive the roundtrip
and caused an error. There's some work to do deciding which parameters
make sense to save and which ones do not, specially when doing that
GUI -> tty -> GUI roundtrip (on Windows and elsewhere).

Other things to do:

- Detect that frames are restored in a non-visible area and do
something about it (discussion ongoing about the precise way to do
it).
- What to do about minibufferless frames and minibuffer-only frames?
- In my tests, fullscreen frames (i.e., (fullscreen . fullscreen), not
the other kinds) restore with the wrong height, about two lines longer
that they should. Could be related to settings of tool-bar-mode, etc.
Not very serious because there's a binding for
toggle-frame-fullscreen, but it is still a bit ugly.
- Currently, if you have desktop-restore-frames = t and want to reload
the desktop without restoring frames, you must configure the variable
or edit by hand the desktop file (or set desktop--saved-states to
nil). I think it'd be good to have interactive arguments for
desktop-(save|load) to toggle frame saving&restoring. Or treat this as
sort of a pseudo-minor-mode and add a function to toggle it.
- At some point in the future, Stefan's patch/idea to add an option to
emacs to delay creating the first frame, so we can avoid the flicker
of resizing it.

That's off the top of my head. Anything else I've missed, just holler.

  J

Re: How to restore the layout?

[martin rudalics]

 > I still don't see much use for desktop-restore-frame-positions. On one
 > hand, if you s&r in the same display (which I naïvely assume is the
 > most common use case), positions and sizes are preserved and removing
 > that info to let the window manager do its thing is a bit strange,
 > and, as discussed before, it could fail for some frame configurations
 > with small windows.

Agreed.  That would be the default and most users won't care about such
an option.

 > On the other hand, if you restore in a different
 > display, or a different monitor size, that's a problem that we should
 > try to solve, even if only partially, regardless of any user option
 > setting...

Agreed as well.  But the options here could be to (1) just fail
restoring frames when they cannot be restored accurately, (2) try to
move them into the visible part of the screen (workarea), and (3) leave
the decision where to place them to the window manager making only sure
that they are large enough.  And we could start doing this after we get
the first bug report in this area (this means, hopefully, never).

 > desktop-restore-frame-displays makes more sense because
 > there are already users who prefer it that way (like Stefan).

OK.

martin

Re: How to restore the layout?

[martin rudalics]

 > I've pushed a new patch. It renames the restore option to
 > desktop-restore-frames, adds a new one
 > desktop-restore-in-current-display, and includes a few bugfixes.

Thank you!

 > I've been forced to filter out the
 > font frame parameter because it didn't really survive the roundtrip
 > and caused an error.

Could you please add a comment about this in the code.

 > There's some work to do deciding which parameters
 > make sense to save and which ones do not, specially when doing that
 > GUI -> tty -> GUI roundtrip (on Windows and elsewhere).

If really needed, we can make this customizable.

 > Other things to do:
 >
 > - Detect that frames are restored in a non-visible area and do
 > something about it (discussion ongoing about the precise way to do
 > it).
 > - What to do about minibufferless frames and minibuffer-only frames?

When saving we will have to establish a relationship between each
minibuffer-less frame and its associated minibuffer frame.  When
restoring we first have to create the minibuffer frame(s) and then
create the minibuffer-less frames and redirect them to their minibuffer
frame(s).  When at this time a normal frame (with minibuffer window)
remains, we probably have to delete it - AFAIK there's no function to
convert an existing minibuffer-equipped frame to a minibuffer-less one.

I think anyone needing such an arrangement will have to write the
appropriate code.  Here we only have to make sure that (some sort of)
frame names can be written by desktop so we can use them later when
restoring the frame/minibuffer relationships.

 > - In my tests, fullscreen frames (i.e., (fullscreen . fullscreen), not
 > the other kinds) restore with the wrong height, about two lines longer
 > that they should. Could be related to settings of tool-bar-mode, etc.
 > Not very serious because there's a binding for
 > toggle-frame-fullscreen, but it is still a bit ugly.

Is it possible that you call `desktop--make-full-frame' too "early", in
some sense?  Does maximize have the same problem?

martin

Re: How to restore the layout?

[Juanma Barranquero]

On Mon, Jul 1, 2013 at 8:50 AM, martin rudalics <rudalics@gmx.at> wrote:

> Could you please add a comment about this in the code.

Yes. will do.

> If really needed, we can make this customizable.

If you mean through desfcustom, I don't really think that's something
the user should care/know about. But I'll change the defconst to a
defvar to make it clear that users doing low-level customization (via
hooks and elisp code) can of course alter it. I have not yet given
much thought to these kinds of customizations, but I'll likely add
some hooks or whatever is necessary so people wanting to mess with the
save&restore process in their .emacs (for example, making sure that
some window or frame is deleted before saving, etc.) will be able to.

> When saving we will have to establish a relationship between each
> minibuffer-less frame and its associated minibuffer frame.  When
> restoring we first have to create the minibuffer frame(s) and then
> create the minibuffer-less frames and redirect them to their minibuffer
> frame(s).

Yes.

> I think anyone needing such an arrangement will have to write the
> appropriate code.

I don't know whether minibuffer-less frames are unusual
(frequency-wise), but they are documented on the manual, and have
built-in support, so they should work (wrt saving&restoring) out of
the box.

> Here we only have to make sure that (some sort of)
> frame names can be written by desktop so we can use them later when
> restoring the frame/minibuffer relationships.

We can add desktop-* frame parameters easily with all kind of
information we need (as long as it can be read back).

> Is it possible that you call `desktop--make-full-frame' too "early", in
> some sense?

If so, I don't know in which sense.

> Does maximize have the same problem?

No, maximized frames have their correct height.

    J

RE: How to restore the layout?

[Drew Adams]

>  > - What to do about minibufferless frames and minibuffer-only frames?
> 
> When saving we will have to establish a relationship between each
> minibuffer-less frame and its associated minibuffer frame.  When
> restoring we first have to create the minibuffer frame(s) and then
> create the minibuffer-less frames and redirect them to their minibuffer
> frame(s).  When at this time a normal frame (with minibuffer window)
> remains, we probably have to delete it - AFAIK there's no function to
> convert an existing minibuffer-equipped frame to a minibuffer-less one.
> 
> I think anyone needing such an arrangement will have to write the
> appropriate code.  Here we only have to make sure that (some sort of)
> frame names can be written by desktop so we can use them later when
> restoring the frame/minibuffer relationships.

Another possibility/suggestion, from little-to-no knowledge of this
stuff: Simply do not record or restore a minibuffer-only frame.
Otherwise, record the `minibuffer' property of a frame, including the
case where it is nil (no minibuffer).

That should at least handle the case of someone who restores a desktop
in an Emacs session that already has a standalone minibuffer.  (But
from your message I now have a doubt: is it necessary to associate the
ordinary restored frames with the existing standalone minibuffer?)

And I think that is the common (only?) standalone minibuffer frame
scenario, I believe.

There are perhaps other use cases, e.g., where the desktop is
invoked/restored before the Emacs session has created its standalone
minibuffer.  Dunno - can't really speak to such scenarios.

But for the usual (?) case, where an Emacs session exists with a
standalone minibuffer and *then* you restore a desktop, I would guess
(naively) that it should work perfectly.

Keep in mind that to use a standalone minibuffer you really need to
set it up at startup time, e.g., from the command line or from your
init file.  You cannot add a (useful) standalone minibuffer after Emacs
has already created its first frame, which has its own minibuffer.

Correction of that last observation welcome.  But it seems to be the
case.  My simple proposal above (do not record/restore minibuffer-only
frames) is, I guess, based on it.

Re: How to restore the layout?

[Juanma Barranquero]

On Mon, Jul 1, 2013 at 4:11 PM, Drew Adams <drew.adams@oracle.com> wrote:

> Another possibility/suggestion, from little-to-no knowledge of this
> stuff: Simply do not record or restore a minibuffer-only frame.

Yes, that's one posibility, but then, if the user moved or resized it,
these changes won't be restored. Not a deal breaker, but something to
take into account. OTOH, restoring a minibuffer-only frame does not
really make much sense unless you do it first of all and set
default-minibuffer-frame to it...  Time to go doing some
experimenting.

> Otherwise, record the `minibuffer' property of a frame, including the
> case where it is nil (no minibuffer).

The `minibuffer' property can contain non-readable things, like a
window reference.

> (But
> from your message I now have a doubt: is it necessary to associate the
> ordinary restored frames with the existing standalone minibuffer?)

minibuffer can be t/n/only, but also a reference to a minibuffer
window in another frame.
- t : nothing to do, it works out of the box
- nil: emacs will try to associate the frame with
default-minibuffer-frame or create one minibuffer frame for it
- only: as discussed above
- a window: we currently can do nothing about this, because we do not
have a way to name windows and restore references to them.

> Keep in mind that to use a standalone minibuffer you really need to
> set it up at startup time, e.g., from the command line or from your
> init file.  You cannot add a (useful) standalone minibuffer after Emacs
> has already created its first frame, which has its own minibuffer.

Yes. minibuffer-only frames and their brethren are strange beasts.

   J

RE: How to restore the layout?

[Drew Adams]

> > Another possibility/suggestion, from little-to-no knowledge of this
> > stuff: Simply do not record or restore a minibuffer-only frame.
> 
> Yes, that's one posibility, but then, if the user moved or resized it,
> these changes won't be restored. Not a deal breaker, but something to
> take into account.

My guess is that, for the reasons I gave earlier (must set up during
startup), someone using a standalone minibuffer frame will already have
set it up, including its position and size, before trying to restore a
desktop.  Users will neither want nor need a desktop to record and
restore a standalone minibuffer frame.

My suggestion is to record & restore only the frames that do not have
an `only' value for frame parameter `minibuffer'.  No one will miss the "feature" of recording & restoring a standalone minibuffer frame.

This assumes that everything works as expected otherwise:

1. Restoring a frame with nil `minibuffer' property correctly associates
it with the standalone minibuffer frame.  I assume that that is the case,
because that is what happens today when `default-frame-alist' specifies
nil as the `minibuffer' property value.  That is the only that makes
sense to me.

2. Restoring a frame that had a non-nil, non-`only' `minibuffer' property
correctly associates it with an existing standalone minibuffer frame.
I assume that is the only reasonable behavior, but I'm no expert on that.
Perhaps there is someone who uses both a standalone minibuffer and
separate minibuffers in some frames?  I doubt it, however.

If I prove wrong about the expected use cases then you can think later
about providing a user option.  The default behavior should anyway,
IMO, be what I described: do not record or restore any frame that has
`only' as its `minibuffer' frame parameter value.

That is at least the first behavior to try out for your prototype, IMO.

> OTOH, restoring a minibuffer-only frame does not
> really make much sense unless you do it first of all and set
> default-minibuffer-frame to it...  Time to go doing some
> experimenting.

Exactly.

> > Otherwise, record the `minibuffer' property of a frame, including the
> > case where it is nil (no minibuffer).
> 
> The `minibuffer' property can contain non-readable things, like a
> window reference.

Yes.  I don't know whether anyone uses that, or whether it is used
somehow internally by Emacs.  In any case, I have nothing useful to
offer about that.

If the value is a window then it supposedly must be a minibuffer
window on some other frame.  How you would deal with that in the
context of desktop.el I don't know. I guess if you are actually
restoring windows in general then you could restore that value (and
hence the association) as well.

But again, what is a use case for that?  It would not be needed for
the usual case of input redirection, AFAIK.  For that, you would just
redirect input to your standalone minibuffer.  (That's what I do for
a separate *Completions* frame, for instance.)

> > (But from your message I now have a doubt: is it necessary to
> > associate the ordinary restored frames with the existing standalone
> > minibuffer?)
> 
> minibuffer can be t/n/only, but also a reference to a minibuffer
> window in another frame.
> - t : nothing to do, it works out of the box
> - nil: emacs will try to associate the frame with
> default-minibuffer-frame or create one minibuffer frame for it
> - only: as discussed above
> - a window: we currently can do nothing about this, because we do not
> have a way to name windows and restore references to them.

See above.  I wouldn't worry about the window-valued case, at least
for now.  Note too: it is not just any old window - it should (must?)
be a minibuffer window.

> > Keep in mind that to use a standalone minibuffer you really need to
> > set it up at startup time, e.g., from the command line or from your
> > init file.  You cannot add a (useful) standalone minibuffer after Emacs
> > has already created its first frame, which has its own minibuffer.
> 
> Yes. minibuffer-only frames and their brethren are strange beasts.

Every beast is a strange beast.  Every Emacs feature that one is not
used to using seems strange at first.

FWIW, a standalone minibuffer frame was not only not strange but was
the DEFAULT and the TYPICAL way for users to interact with Emacs back
in the days of Epoch.  And Epoch's standalone minibuffer worked even
better than what I've been able to cobble together for GNU Emacs.

From http://tonic.physics.sunysb.edu/docs/emacs/emacsFAQ.html#sec93
(long ago):

  93:  What is the difference between GNU Emacs and Epoch?
  
  Marc Andreessen <marca@ncsa.uiuc.edu> writes:
  
    Epoch is GNU Emacs on steroids: an adaptation of GNU Emacs with lots of
    additional support for features made possible by the X11 windowing
    system.  These features include multiple editing windows, arbitrary
    colors and fonts (fixed-width and proportional), selectable zones per
    buffer with arbitrary display styles (font, color, underline, stipple,
    pixmap), an optional separate minibuffer window, improved keyboard and
    mouse handling, full 8-bit character set support, and more.

From http://www.cs.utah.edu/dept/old/texinfo/epoch/epoch.html#SEC9:

  Epoch supports two different kinds of minibuffers. The default is a
  non-local minibuffer, which is displayed in its own distinct screen;
  this is what Epoch has traditionally done. The alternative is to have
  minibuffer windows local to each edit screen; this is similar to
  traditional GNU Emacs. In the case of non-local minibuffers, there
  will always be exactly one minibuffer screen, and one or more edit
  screens; a single edit screen and minibuffer screen together act
  similarly to normal GNU Emacs. For local minibuffers, the real
  minibuffer will be located at the bottom of the current edit screen. 

Yes, GNU Emacs has caught up with much of what Epoch offered more than
20 years ago.  And it has added important features that Epoch did not have.
But in spite of being the best thing around today, GNU Emacs has still not
caught up with some of what Epoch offered, out of the box, many, many moon
ago.

Strange?

  "Bizarre" ? Moi, j'ai dit "bizarre, bizarre" ? Comme c'est drole.
  Pourquoi aurais-je dit "bizarre, bizarre" ? ... Moi, j'ai dit
  "bizarre" ? Comme c'est bizarre.

http://www.youtube.com/watch?v=Ku-ChVdBwDs
[Louis Jouvet, "Drole de Drame", 1937]

Longer extract (3.5 min):
http://www.youtube.com/watch?v=4QiuzDEWD8I

Re: How to restore the layout?

[Juanma Barranquero]

On Mon, Jul 1, 2013 at 6:03 PM, Drew Adams <drew.adams@oracle.com> wrote:

> My guess is that, for the reasons I gave earlier (must set up during
> startup), someone using a standalone minibuffer frame will already have
> set it up, including its position and size, before trying to restore a
> desktop.  Users will neither want nor need a desktop to record and
> restore a standalone minibuffer frame.

In many cases, the user will already have set up other frames in
precise detail, the initial one for example (until now, I usually set
my initial frame with specific size & position). But if she moves the
frame and saves Emacs, she will expect the frame to restore at the new
position, not the one in initial-frame-alist. I don't really see why
moving a minibuffer-only frame from its default position should be
different (other that because it is harder to implement correctly, of
course ;-).

> My suggestion is to record & restore only the frames that do not have
> an `only' value for frame parameter `minibuffer'.  No one will miss the
> "feature" of recording & restoring a standalone minibuffer frame.

I've tested that and it works, but it is a bit jarring. Your frame
will restore at the same place it was saved, but the new minibuffer
frame is restored all over the place. Of course, if you set up
minibuffer-frame-alist for a specific position, it will be recreated
there, which is still jarring if you've moved the main frame.

That said, as a last resort I can live with not saving the
minibuffer-only frame and document clearly that the user is reponsible
of its appearance *and* position and should set minibuffer-frame-alist
correctly when using desktop-restore-frames.

> 1. Restoring a frame with nil `minibuffer' property correctly associates
> it with the standalone minibuffer frame.  I assume that that is the case,
> because that is what happens today when `default-frame-alist' specifies
> nil as the `minibuffer' property value.  That is the only that makes
> sense to me.

Yes.

> 2. Restoring a frame that had a non-nil, non-`only' `minibuffer' property
> correctly associates it with an existing standalone minibuffer frame.
> I assume that is the only reasonable behavior, but I'm no expert on that.
> Perhaps there is someone who uses both a standalone minibuffer and
> separate minibuffers in some frames?  I doubt it, however.

No idea.

> That is at least the first behavior to try out for your prototype, IMO.

Already tested. Now let me try with saving&restoring the
minibuffer-only frame; I can fall back to your proposal easily enough.

> If the value is a window then it supposedly must be a minibuffer
> window on some other frame.  How you would deal with that in the
> context of desktop.el I don't know. I guess if you are actually
> restoring windows in general then you could restore that value (and
> hence the association) as well.

That's currently not possible because we don't have a way to identify
a window (in the window state returned by window-state-get). Martin
said it could be added, if required, but let's try to avoid it if at
all possible.

> Every beast is a strange beast.  Every Emacs feature that one is not
> used to using seems strange at first.

You're talking about UI. I can understand why you do think that they
are not that strange (or stranger than any other setup). I was talking
about implementation. From a cursory look at frames.el and other code,
I'd say minibuffer-only frames add a lot of complexity.

> FWIW, a standalone minibuffer frame was not only not strange but was
> the DEFAULT and the TYPICAL way for users to interact with Emacs back
> in the days of Epoch.  And Epoch's standalone minibuffer worked even
> better than what I've been able to cobble together for GNU Emacs.

Individual tastes and diversity are wonderful things. From using
minibuffer-only frames for a few minutes, I wouldn't touch them with a
ten foot pole. Multi-frame setups yes, they are nice and, as Stephen
said, in many cases is easier to deal with many open frames than
switch between Emacs windows. But I fail entirely to see the appeal of
having the minibuffer in another frame. Which is not to say that I
won't work hard on make them work with this feature ;-)

> http://www.youtube.com/watch?v=Ku-ChVdBwDs
> [Louis Jouvet, "Drole de Drame", 1937]

Funny.

   Juanma

RE: How to restore the layout?

[Drew Adams]

> > My guess is that, for the reasons I gave earlier (must set up during
> > startup), someone using a standalone minibuffer frame will already have
> > set it up, including its position and size, before trying to restore a
> > desktop.  Users will neither want nor need a desktop to record and
> > restore a standalone minibuffer frame.
> 
> In many cases, the user will already have set up other frames

"Already" when? You mean before restoring a desktop?  If so, agreed.

That was my point, wrt the minibuffer frame: a user will already have it
set up, before trying to restore a desktop.

> in precise detail, the initial one for example (until now, I usually set
> my initial frame with specific size & position). But if she moves the
> frame and saves Emacs, she will expect the frame to restore

Restore when?

> at the new position, not the one in initial-frame-alist.

Sorry, I don't follow you.  Restore how - via a desktop?

I don't see `initial-frame-alist' entering the discussion anyway, but that
might be because I don't make any use of it.  I use only `default-frame-alist'.

I guess if I wanted to see the initial frame with different properties from
`default-frame-alist' then I would do something like this:

(setq default-frame-alist nil
      initial-frame-alist '((background-color . "Whatever")))
      default-frame-alist <whatever I wanted different>)

> I don't really see why moving a minibuffer-only frame from its default
> position should be different (other that because it is harder to implement
> correctly, of course ;-).

It's not clear to me what you mean by restoring, or when that happens.

Typically, a user with a standalone minibuffer will (must?) set it up when Emacs starts, from the command line or the init file.  If s?he then moves that frame
for some reason, I would NOT assume that s?he wants the next Emacs session to
remember the last position/size of that frame.  I would assume that the same
startup code would be used to configure the frame anew the same way.

IOW, I would assume that if a user wants to change what the standalone minibuffer
frame looks like, s?he would do that in the startup code.

Perhaps you are suggesting something like this: A user might want different
desktops that have different standalone minibuffer properties (e.g. size, position).

If so, yes, I can see that possibility.  But I would advise leaving handling
that possibility for later, as it's not obvious in that case how to deal with
the various problems I reported to you (separately).  There needs to be (IMO,
AFAIK) at most one standalone minibuffer.

Perhaps one solution would be to go ahead and (as you have done so far, I
believe) record the standalone minibuffer frame, but when it comes to restoring
from a desktop, do NOT try to restore it if there already is a standalone
minibuffer frame.

Or perhaps, if there is already a minibuffer frame, just MODIFY its parameters
based on the recorded ones from the desktop - as opposed to creating a new
minibuffer frame.

In any case, I think you need to avoid trying to create another minibuffer frame.
And avoiding that might just eliminate some of the problems I saw.  (Dunno.)

> > My suggestion is to record & restore only the frames that do not have
> > an `only' value for frame parameter `minibuffer'.  No one will miss the
> > "feature" of recording & restoring a standalone minibuffer frame.
> 
> I've tested that and it works, but it is a bit jarring. Your frame
> will restore at the same place it was saved, but the new minibuffer
> frame is restored all over the place.

What "new minibuffer frame"?  My suggestion was to NOT record or restore
a minibuffer frame.  So restoring a desktop should not be creating any "new
minibuffer frame".

> Of course, if you set up minibuffer-frame-alist for a specific position,
> it will be recreated there, which is still jarring if you've moved the main
> frame.

It's hard to talk about this and follow each other, with just descriptions.
I suggest we take it off list for a while and we stick to easy-to-follow
recipes.

> That said, as a last resort I can live with not saving the
> minibuffer-only frame and document clearly that the user is reponsible
> of its appearance *and* position and should set minibuffer-frame-alist
> correctly when using desktop-restore-frames.

I'd suggest that we start with that.  See my other suggestions above, for
possible use afterward.  IOW, we might be able to (optionally) accommodate
save/restore of a minibuffer-only frame, if the restore operation avoided
trying to create a new standalone minibuffer frame when one already exists.

> > That is at least the first behavior to try out for your prototype, IMO.
> 
> Already tested. Now let me try with saving&restoring the
> minibuffer-only frame; I can fall back to your proposal easily enough.

Great.  Good to hear that at least the simple solution works.  (That should
be enough for my own use.)

> > Every beast is a strange beast.  Every Emacs feature that one is not
> > used to using seems strange at first.
> 
> You're talking about UI. I can understand why you do think that they
> are not that strange (or stranger than any other setup). I was talking
> about implementation. From a cursory look at frames.el and other code,
> I'd say minibuffer-only frames add a lot of complexity.

I see.  Yes, I mistakenly thought you were talking about a user point of view.

> Individual tastes and diversity are wonderful things. From using
> minibuffer-only frames for a few minutes, I wouldn't touch them with a
> ten foot pole. Multi-frame setups yes, they are nice and, as Stephen
> said, in many cases is easier to deal with many open frames than
> switch between Emacs windows. But I fail entirely to see the appeal of
> having the minibuffer in another frame. Which is not to say that I
> won't work hard on make them work with this feature ;-)

Thanks for the last part. ;-)

As to the missing appeal:

1. Single place to look for all user command input and echoed messages.
   No matter what frame might be selected, your visual focus for commands and
   messages is always the same.

2. Long, long minibuffer - full-screen width.
   And in my case, expands to any number of lines.  (I use the minibuffer for
   lots of stuff, including sometimes large sexps.)

3. Less wasted screen real estate.  This (minor) advantage would go away
   if Emacs showed a minibuffer only for the selected frame.  No need for each
   frame to show a minibuffer/echo area, even if it cannot currently be used.

   However, if Emacs did dynamicaly show/hide minibuffers in frames that way,
   it might be distracting/disorienting.  In any case, I would prefer the
   single-location, permanent, standalone minibuffer frame solution.

Re: How to restore the layout?

[Juanma Barranquero]

> On Mon, Jul 1, 2013 at 8:03 PM, Drew Adams <drew.adams@oracle.com> wrote:

> "Already" when? You mean before restoring a desktop?  If so, agreed.

Yes. in the init file, or via X resources / W32 registry.

> Restore when?

In all this discussion, when I say "restore" I'm mostly talking about
automatic (desktop) restoration while starting emacs, but I don't
think a later M-x desktop-read <RET> would be any different.

> Sorry, I don't follow you.  Restore how - via a desktop?

Yes.

> I don't see `initial-frame-alist' entering the discussion anyway, but that
> might be because I don't make any use of it.  I use only `default-frame-alist'.

That doesn't really change much of what is being discussed.

> Typically, a user with a standalone minibuffer will (must?) set it up when Emacs starts,
> from the command line or the init file.  If s?he then moves that frame
> for some reason, I would NOT assume that s?he wants the next Emacs session to
> remember the last position/size of that frame.  I would assume that the same
> startup code would be used to configure the frame anew the same way.

That's weird. If I set up default-frame-alist to create frames of size
80x50, and then I resize them, after desktop-save/desktop-read (or
exit Emacs and restart it) I would expect them to be just like I left
them, not how the "code to configure the frame[s] anew" would make
them. That's the *whole* reason I'm using desktop-restore-frames. I
assume you would expect the same. How is the minibuffer-only frame any
different?

> IOW, I would assume that if a user wants to change what the standalone minibuffer
> frame looks like, s?he would do that in the startup code.

Yes, for new minibuffer frames. But when you're using
desktop-restore-frames, you're asking your frames, and the changes (in
size, position, window setup and buffers displayed) to be
persistent...

Hmm. While writing the above sentences, it dawned on me: it seems like
you're thinking of desktop-restore-frames as a way to set
(quasi-)immutable snapshots (or desktop bookmarks). You want to use
them to be able to roll back to defined window&frame states. Is that
so?

That is, of course, perfectly valid, but desktop-restore-frames must
also support a more transient use case, where what the user wants is
for the current state to be saved upon exit and restored on restart.
If I were to use a separate minibuffer-only frame, my expectation
would definitely not be for that frame to appear always at the sample
place, but at the place it was when I exited from Emacs. To me, that's
not a new frame recreated anew in each Emacs run (though it really is,
from Emacs' POV); it's the same one I moved aside or resized in my
previous working session.

> Or perhaps, if there is already a minibuffer frame, just MODIFY its parameters
> based on the recorded ones from the desktop - as opposed to creating a new
> minibuffer frame.

That's more or less what I'm trying right now.

> In any case, I think you need to avoid trying to create another minibuffer frame.
> And avoiding that might just eliminate some of the problems I saw.  (Dunno.)

Yes, agreed. Creating a second minibuffer-only frame would be a bug.

> What "new minibuffer frame"?  My suggestion was to NOT record or restore
> a minibuffer frame.  So restoring a desktop should not be creating any "new
> minibuffer frame".

I think you're talking about a desktop-save/desktop-read use case:
that is, you say that if you have a current setup, with a
minibuffer-only frame, and you do M-x desktop-read, no new
minibuffer-only frame should be created. And I was talking about
kill-emacs / run emacs. A new minibuffer-only frame is created.

> It's hard to talk about this and follow each other, with just descriptions.
> I suggest we take it off list for a while and we stick to easy-to-follow
> recipes.

OK, though public discussion helps to integrate other people's
opinions. Surely you're not the only one using multi-frame setups and
minibuffer-only frames :-)

> IOW, we might be able to (optionally) accommodate
> save/restore of a minibuffer-only frame, if the restore operation avoided
> trying to create a new standalone minibuffer frame when one already exists.

Of course, that's always been the goal. Let's not forget that we're
talking about unfinished code and evolving designs here.

> Great.  Good to hear that at least the simple solution works.  (That should
> be enough for my own use.)

Yes, though it wouldn't be for mine, if I used a setup like yours. Now
would be a great time for different opinions to enter the discussion
(hint, hint).

> As to the missing appeal:
>
> 1. Single place to look for all user command input and echoed messages.
>    No matter what frame might be selected, your visual focus for commands and
>    messages is always the same.

In my case, that would be a disadvantage, when using multiple frames
(for a one-work-frame, one-minibuffer-frame, I could bear it, though
it wouldn't really be much different or better than the default
setup). Non-locality kills me. That's the same reason, I suppose, I
can not stand the recentering scrolling of stock Emacs and must resort
to line-by-line scrolling.

> 2. Long, long minibuffer - full-screen width.
>    And in my case, expands to any number of lines.  (I use the minibuffer for
>    lots of stuff, including sometimes large sexps.)

You don't need minibuffer-only frames for that. I have my minibuffer
set up so it can grow up to 1/3 of the frame height, which I find more
than enough for most uses. You could potentially make it almost
full-screen height.

>    However, if Emacs did dynamicaly show/hide minibuffers in frames that way,
>    it might be distracting/disorienting.  In any case, I would prefer the
>    single-location, permanent, standalone minibuffer frame solution.

Goes to show why both of us use the Extensible, Customizable Text Editor.

   J

RE: How to restore the layout?

[Drew Adams]

> > Typically, a user with a standalone minibuffer will (must?) set it up when
                             ^^^^^^^^^^^^^^^^^^^^^                  ^^
> > Emacs starts, from the command line or the init file.  If s?he then moves
> > that frame for some reason, I would NOT assume that s?he wants the next
    ^^^^^^^^^^
> > Emacs session to remember the last position/size of that frame.  I would
                                                        ^^^^^^^^^^
> > assume that the same startup code would be used to configure the frame
                                                                 ^^^
> > anew the same way.
> 
> That's weird. If I set up default-frame-alist to create frames of size
> 80x50, and then I resize them, after desktop-save/desktop-read (or
> exit Emacs and restart it) I would expect them to be just like I left
> them, not how the "code to configure the frame[s] anew" would make
> them. That's the *whole* reason I'm using desktop-restore-frames. I
> assume you would expect the same. How is the minibuffer-only frame any
> different?

I was talking only about a standalone minibuffer frame.  Sorry if that
was not clear.  How is it different?  In the ways I've already described,
i.e., the uses I described as being, I think, typical.

And in the fact that it uses `minibuffer-frame-alist', which supersedes
`default-frame-alist'.  IOW, almost the same answer for why we even have
a `minibuffer-frame-alist' user option.

> > IOW, I would assume that if a user wants to change what the standalone
> > minibuffer frame looks like, s?he would do that in the startup code.
> 
> Yes, for new minibuffer frames. But when you're using
> desktop-restore-frames, you're asking your frames, and the changes (in
> size, position, window setup and buffers displayed) to be
> persistent...

In general, yes.  My assumption was that that is not generally the case
for a standalone minibuffer frame.  Whereas there can often be many
frames that are built off of the `default-frame-alist', and which a user
might well move here and there and resize, I don't see that kind of thing
happening typically for a minibuffer frame.

I'm not saying that what I think will be the typical case is the only
possible case.  I think I mentioned that a few times.  I can't really
speak much to such cases.  My experience is with the case I'm assuming
will be typical for someone using a standalone minibuffer.  Others are
free to correct me if they feel otherwise.

> Hmm. While writing the above sentences, it dawned on me: it seems
> like you're thinking of desktop-restore-frames as a way to set
> (quasi-)immutable snapshots (or desktop bookmarks). You want to use
> them to be able to roll back to defined window&frame states. Is that
> so?

No, that would be independent of the considerations I put forth for the
minibuffer frame.  I see desktops used lots of different ways. 
A simple and common way will be to simply remember and restore the last
state of Emacs, including the sizes, positions, colors, fonts (yes,
fonts!), etc. of its frames.  I nevertheless see changes to the
minibuffer frame due to the dynamic use of Emacs to be something (a)
rare and (b) you probably do not want to save.

Since I mentioned fonts -

I think I saw that you mentioned that you cannot currently save/restore
a frame's font.  To me, that ability is far more important that letting
users record and restore any dynamic changes they might have made to a
standalone minibuffer frame.  It is important to me, at least.

For me, restoring a frame's font is also required for restoring
thumbnail frames.  They are, to simplify, tiny frames made tiny by
shrinking their fonts.  Of course, it is not just font size that
matters, but other aspects of the font as well.  I change various
fields (including size info) of an XLFD font name, and would expect
that to be restored by Desktop.

(I realize that not everything will be perfect in the first draft.
I'm just saying that, to me, restoring the font is important.)

> That is, of course, perfectly valid, but desktop-restore-frames must
> also support a more transient use case, where what the user wants is
> for the current state to be saved upon exit and restored on restart.

See above.  Yes, that will a common use case, perhaps the most common.
Nothing I've said gets in the way of that use case, if you assume that
people will (a) not be dynamically changing a minibuffer frame and (b)
will not care to save any dynamic changes they might happen to make to
it.  (I'm not talking about changes to it that they might make through
customization etc., but simply moving or resizing etc.)

> If I were to use a separate minibuffer-only frame, my expectation
> would definitely not be for that frame to appear always at the sample
> place, but at the place it was when I exited from Emacs.

Where would you expect that you would be moving it, and why?  Again,
I'm not talking about customizing where you want it, and perhaps
changing your mind about that customization once in a while.

> To me, that's not a new frame recreated anew in each Emacs run
> (though it really is, from Emacs' POV); it's the same one I moved
> aside or resized in my previous working session.

Let me be clear.  I have no problem with you doing what you suggest:
make a standalone minibuffer behave like others in terms of remembering
its state.  I was trying to make your job easier by pointing out that
in most cases no one need that feature.  But if it works well then I
have no problem with it.

Here's a probably lousy analogy, but it is one that comes to my mind:
The Windows task bar.  You can move it to the top, bottom, left or
right.  Most people do not move it every 30 minutes.  Moving it is,
effectively, customizing its position.  But yes, the fact that Windows
remembers the last position as the customization is fine.

I would have no problem if Desktop handled the minibuffer frame
similarly - modulo certain considerations (below).  I will go further:
if Desktop handles that right then it lets users not worry about setting
things up using Lisp code.  They can simply drag the frame to where they
want it and give it the size they want, and that will be remembered
(provided they start up with Desktop) each time.  Formidable!

But the devil will be in the details wrt "works well", probably.
My setup code creates a new minibuffer frame according to user
customizations.  If the desktop code can be used in such a way that it
does not interfere with that then there will be no problem.

You might want to reread what I wrote about the creation of a
minibuffer frame.  To have one, you need to create it during startup.
That means that users do so in their Emacs startup.  And there can be at
most one such frame.

If a user uses Desktop to restore the last state and that state now
tries to also restore a saved minibuffer frame, then that restoration
code needs to check whether there is already a minibuffer frame, and if
so then either (as I said before): (a) ignore its saved info for the
minibuffer frame (leave the user's frame alone) or (b) MODIFY the
already existing minibuffer frame - as opposed to trying to create
another such.

If you implement a way for a user to choose between (a) and (b), no
problem.  If you offer only (b) then that would be limiting for a
user who wants to control the frame properties via setup at start time.
If you offer only (a) then that would be limiting for the user who
really does want any last-session changes to the minibuffer frame to
be reflected in the new session.

> > Or perhaps, if there is already a minibuffer frame, just MODIFY its
> > parameters based on the recorded ones from the desktop - as opposed
> > to creating a new minibuffer frame.
> 
> That's more or less what I'm trying right now.

That is (b), above.  A user should have the choice.

In fact, now that I mention that -

Users use frames for different things.  A user might well have
particular other frames, besides the minibuffer, that s?he wants to
have defined each time based on a startup-time setup, i.e., that s?he
does not want to have changed by Desktop.

Conceivable, at least.  I don't use frames that way, but some people
might (I too can hypothesize ;-).

In my case, I use "special-display" to handle frames that I want to have
particular properties.  And since that is set up anew each session, and
since the properties are anyway frame parameters, I'm pretty sure that
Desktop will not be a problem for me here.

Nevertheless, yes, it would be good to have a general feature of
classifying particular frames off-limits for Desktop, i.e., frames that
it either would not record or (probably better) simply would not restore.
The latter would probably be better because we could provide a runtime
way to override this prohibition on Desktop, i.e., to let a user allow
Desktop to restore a particular frame classified generally as off-limits.

There are lots of possibilities.  I'd say handle the simple case(s) first.
And in my view, leaving the minibuffer frame alone is the simple (common)
case.  IOW, if you have a minibuffer frame then I think you probably want
it in the same place each time.  Again, someone will correct me if they
think otherwise.

And again, if you can make it work well and be flexible  then it would be
an advantage to be able to directly manipulate the frame into the size and
position that one wants to keep.  Desktop could perhaps help there, but
I would rather see such direct-manipulation translated into customization.
IOW, once you get something like a minibuffer frame the way you generally
want it, you want to be able to say Basta! Hands off from now on, until I
change my mind.

> > In any case, I think you need to avoid trying to create another
> > minibuffer frame.  And avoiding that might just eliminate some of
> > the problems I saw.  (Dunno.)
> 
> Yes, agreed. Creating a second minibuffer-only frame would be a bug.

It wouldn't be possible, AFAIK.  What would happen is (likely) what we
saw: only one of the frames would get the `only' value of parameter
`minibuffer'.

But I think we are really saying the same thing here, describing it
differently.  We don't want two frames trying or pretending to each be
the minibuffer frame, even if only one can ever really be such.

> > What "new minibuffer frame"?  My suggestion was to NOT record or
> > restore a minibuffer frame.  So restoring a desktop should not be
> > creating any "new minibuffer frame".
> 
> I think you're talking about a desktop-save/desktop-read use case:
> that is, you say that if you have a current setup, with a
> minibuffer-only frame, and you do M-x desktop-read, no new
> minibuffer-only frame should be created.

Yes.

> And I was talking about kill-emacs / run emacs.

Meme combat - from my point of view.  Not the same use case, but I feel
the same about both cases.

> A new minibuffer-only frame is created.

But, as I mentioned, since a minibuffer frame must be created during
startup, it will be created (anyway) by the user's startup code.

Now just maybe, if you make Desktop get in the act and try to restore
the minibuffer frame, the user will then need to start worrying about
just when to invoke Desktop, relative to the user code that creates the
minibuffer frame.  Or maybe s?he will now have to worry about having
conditional code that checks whether desktop (which might have run first)
has already created a standalone minibuffer, and then skip doing that
in the user startup code.

IOW, either Desktop or the user will need to worry about avoiding an
attempt to create a second minibuffer frame.  I would rather it be
Desktop, a priori.  See above for possible extensions to allow users
to let Desktop restore (i.e., create or modify) a minibuffer frame.

But the default Desktop behavior should, IMO, be the simple one (from
a user point of view): YAGNI, i.e., Desktop hands off the minibuffer.

> > It's hard to talk about this and follow each other, with just
> > descriptions.  I suggest we take it off list for a while and we
> > stick to easy-to-follow recipes.
> 
> OK, though public discussion helps to integrate other people's
> opinions.

I agree.  That's why I said "for a while".  There is also a risk of
boring others and going down a rabbit hole.  My suggestion was to
get through the vague discussion part using simple recipes instead,
then report back and get more input/discussion.  But I'm OK with either
way, as I've shown by this message. ;-)

> Surely you're not the only one using multi-frame setups and
> minibuffer-only frames :-)

I would hope not.  But I would unfortunately be willing to bet that
among those reading emacs-devel we are not a multitude. ;-)

> > IOW, we might be able to (optionally) accommodate save/restore
> > of a minibuffer-only frame, if the restore operation avoided
> > trying to create a new standalone minibuffer frame when one already
> > exists.
> 
> Of course, that's always been the goal. Let's not forget that we're
> talking about unfinished code and evolving designs here.

Not to worry. ;-)

> > Great.  Good to hear that at least the simple solution works.
> > (That should be enough for my own use.)
> 
> Yes, though it wouldn't be for mine, if I used a setup like yours. Now
> would be a great time for different opinions to enter the discussion
> (hint, hint).

+1 to that.

> > As to the missing appeal:
> >
> > 1. Single place to look for all user command input and echoed messages.
> >    No matter what frame might be selected, your visual focus for commands
> >    and messages is always the same.
> 
> In my case, that would be a disadvantage, when using multiple frames
> (for a one-work-frame, one-minibuffer-frame, I could bear it, though
> it wouldn't really be much different or better than the default
> setup). Non-locality kills me. That's the same reason, I suppose, I
> can not stand the recentering scrolling of stock Emacs and must resort
> to line-by-line scrolling.

There is more locality, not less.  Not in the sense that the minibuffer
is always closer to the particular buffer text you're editing/reading, but
in the sense that the focus stays the same for command I/O.

I probably spend a lot more time in the minibuffer than most.  But what
I do there involves interactions with other frames - in particular a
standalone *Completions* frame.  If the minibuffer and *Completions* buffer
were jumping all around from frame to frame it would be very distracting.

But as you noted, everyone is different.  After I tried Epoch (with its
standalone minibuffer) a couple of decades ago, I never went back, even
though it was a hassle to wrestle GNU Emacs into doing something similar.

> > 2. Long, long minibuffer - full-screen width.
> >    And in my case, expands to any number of lines.  (I use the minibuffer
> >    for lots of stuff, including sometimes large sexps.)
> 
> You don't need minibuffer-only frames for that. I have my minibuffer
> set up so it can grow up to 1/3 of the frame height, which I find more
> than enough for most uses. You could potentially make it almost
> full-screen height.

Height, but not width.  When I said "long" I meant "wide".  Being part of
an ordinary frame, your minibuffer cannot be screen-wide, unless the
frame is too.

I decouple the width I need for (a) a given frame, which is typically
the width of its text, which is typically of a fixed line length
(different for different kinds of buffers, of course) from (b) the width
of my minibuffer.

There is no logical relation between the width (I still want to say
"length", when talking about line length) of (a) minibuffer input and
echo area output and (b) ordinary buffer text.  Just as I want to fit
most frames to their (typically single) buffer text, so I want to have
a minibuffer that is not limited to the width of any other buffer's
text or window.  Why should it be?

> >    However, if Emacs did dynamicaly show/hide minibuffers in frames
> >    that way, it might be distracting/disorienting.  In any case, I
> >    would prefer the single-location, permanent, standalone
> >    minibuffer frame solution.
> 
> Goes to show why both of us use the Extensible, Customizable Text Editor.

Si.

Re: How to restore the layout?

[martin rudalics]

 > I don't know whether minibuffer-less frames are unusual
 > (frequency-wise), but they are documented on the manual, and have
 > built-in support, so they should work (wrt saving&restoring) out of
 > the box.

The problem is what to do when we initially have a minibuffer-equipped
frame and the state we restore contains only minibuffer-less and
minibuffer-only frames.  In that case we'd have to delete the initial
frame :-(

 > We can add desktop-* frame parameters easily with all kind of
 > information we need (as long as it can be read back).

A first, untested stab is below: Frames get a desktop-mini parameter
which is a cons.  The car is t if the frame has a minibuffer and nil if
not.  For a t-car frame the cdr is its number.  For a nil-car frame cdr
t means use the default minibuffer frame and a number use the minibuffer
frame whose desktop-mini cdr has that number.

Now restoring the desktop has to scan the dekstop-mini parameters first:
If a t-car one is found, make the frame.  Next process the nil-car ones
and make them.  If it's got a number-cdr, find the frame with that
number in its desktop-mini cdr and set the minibuffer-window parameter
of the frame we just process to the minibuffer window of the frame we
have found.

But I'm not sure how to do handle the problem sketched above so I didn't
write the restoration part.

martin


(defun desktop--save-minibuffer-frames ()
   "Save window/frame state, as a global variable.
Intended to be called from `desktop-save'.
Internal use only."
   (let ((frame-list (frame-list))
	(count 0)
	minibuffer-window minibuffer-frame)
     (dolist (frame frame-list)
       ;; For all frames reset desktop-mini parameter if set.
       (when (frame-parameter frame 'desktop-mini)
	(set-frame-parameter frame 'desktop-mini nil)))

     (dolist (frame frame-list)
       ;; Set minibuffer-frame to this frame's minibuffer frame.
       (let ((minibuffer-frame (window-frame (minibuffer-window frame))))
	(cond
	 ;; Process minibuffer-window frame parameter if present.
	 ((and (setq minibuffer-window
		     (frame-parameter frame 'minibuffer-window))
	       (window-minibuffer-p minibuffer-window))
	  (setq minibuffer-frame (window-frame minibuffer-window))
	  (let ((default (eq minibuffer-frame default-minibuffer-frame))
		(this-count
		 (cdr (frame-parameter minibuffer-frame 'desktop-mini))))
	    (unless this-count
	      ;; Make desktop-mini entry for minibuffer frame.
	      (setq count (1+ count) this-count count)
	      (set-frame-parameter
	       minibuffer-frame 'desktop-mini (cons t count)))
	    ;; Make desktop-mini entry for frame processed.
	    (set-frame-parameter
	     frame 'desktop-mini (cons nil this-count))))
	 ;; Do nothig if we are our own minibuffer frame.
	 ((eq minibuffer-frame frame))
	 ;; Use default-minibuffer-frame otherwise.
	 (t
	  (let ((this-count (cdr (frame-parameter
				  default-minibuffer-frame 'desktop-mini))))
	    (unless this-count
	      ;; Make desktop-mini entry for minibuffer frame.
	      (setq count (1+ count) this-count count)
	      (set-frame-parameter
	       default-minibuffer-frame 'desktop-mini (cons t count)))
	    ;; Make desktop-mini entry for frame processed.
	    (set-frame-parameter frame 'desktop-mini (cons nil t)))))))))

Re: How to restore the layout?

[Juanma Barranquero]

On Tue, Jul 2, 2013 at 12:38 PM, martin rudalics <rudalics@gmx.at> wrote:

> A first, untested stab is below: Frames get a desktop-mini parameter
> which is a cons.  The car is t if the frame has a minibuffer and nil if
> not.  For a t-car frame the cdr is its number.  For a nil-car frame cdr
> t means use the default minibuffer frame and a number use the minibuffer
> frame whose desktop-mini cdr has that number.

This is intended to be run before desktop--save-frames, I suppose?

> But I'm not sure how to do handle the problem sketched above so I didn't
> write the restoration part.

Oh, don't worry. My local copy is in a state of flux right now, better
not to invest too much time in the current trunk code.

I'm seeing a frame height problem on Windows 7 with side-aligned
frames (=> the ones you get by typing Windows + Left or Windows +
Right).

With a minimal .emacs, containing:

(desktop-save-mode 1)
(setq desktop-restore-frames t)

then

emacs
W-left
C-x 5 2
W-right
;;; at this point, both frames height's are 65 lines
C-x 5 o
C-x C-c
emacs
;;; now left frame's height is 65 lines, right frame's height is 68;
its top is also a bit higher

Comparing the saved state before & after, there only differences are
the height and top parameters of the second frame, and obviously the
total-height in the window-state. Whatever happens, happens when
creating a new frame with (make-frame-on-display display saved-state).

If you add

(setq default-frame-alist '((tool-bar-lines . 0)))

to .emacs, it doesn't happen anymore. ISTR some old bug report about this

Any idea how to fix that?

   J

Re: How to restore the layout?

[Juanma Barranquero]

On Tue, Jul 2, 2013 at 5:46 AM, Drew Adams <drew.adams@oracle.com> wrote:

> I was talking only about a standalone minibuffer frame.  Sorry if that
> was not clear.  How is it different?  In the ways I've already described,
> i.e., the uses I described as being, I think, typical.

I disagree about "typical" here. The alternate use case I'm suggesting
is neither convoluted nor artificial.

> And in the fact that it uses `minibuffer-frame-alist', which supersedes
> `default-frame-alist'.  IOW, almost the same answer for why we even have
> a `minibuffer-frame-alist' user option.

Well, the initial frame also has a `initial-frame-alist' that
supersedes `default-frame-alist', but you're not proposing to treat it
different that other (non-minibuffer-only) frames.

> In general, yes.  My assumption was that that is not generally the case
> for a standalone minibuffer frame.  Whereas there can often be many
> frames that are built off of the `default-frame-alist', and which a user
> might well move here and there and resize, I don't see that kind of thing
> happening typically for a minibuffer frame.

My assumption is that, just as `initial-frame-alist' is a template for
the first frame (but changes are persistently saved by
desktop-reuse-frames), `minbuffer-frame-alist' is a template for the
minibuffer-only frame, but once created, the user is free to change it
(and expect these changes to stick).

> I nevertheless see changes to the
> minibuffer frame due to the dynamic use of Emacs to be something (a)
> rare and (b) you probably do not want to save.

That's the point where we disagree. That said, you have much more
experience with minibuffer-only frames than me. It'd be good if other
minibuffer-only-frame users would speak now.

> I think I saw that you mentioned that you cannot currently save/restore
> a frame's font.  To me, that ability is far more important that letting
> users record and restore any dynamic changes they might have made to a
> standalone minibuffer frame.  It is important to me, at least.

Not saving the font parameter right now is not a decision or a
feature, just a stopgap measure. Eventually I'll have to revamp the
whole "save/restore frame parameters" code to allow more flexibility,
and then I'll re-save font.

> (I realize that not everything will be perfect in the first draft.
> I'm just saying that, to me, restoring the font is important.)

Yes, agreed.

> Where would you expect that you would be moving it, and why?  Again,
> I'm not talking about customizing where you want it, and perhaps
> changing your mind about that customization once in a while.

In my tests of the minibuffer-only frame (MOF from now on), I like to
have it near the main, or only, frame. So if I move the frame aside,
because I want to see something that's below it (let's say I'm typing
something related to something I'm reading in a browser tab), I
immediately move the MOF too. I suppose that's uncommon for you
because you put the MOF at a fixed place in the screen, likely not
overlapping or overlapped with any other application's window. That's
not how I work, I have Chrome open all the time, and it uses perhaps
80% of my screen space, so other things, including Emacs, do overlap
it. Moving Emacs aside is a pretty common operation for me.

> I was trying to make your job easier by pointing out that
> in most cases no one need that feature.  But if it works well then I
> have no problem with it.

"Works well" is not how I would define it right now. "Works most of
the time" is more like it, but of course, that difference is quite
important. So I don't reject at all the idea of falling back into the
do-not-save-MOF implementation strategy; I'm just wasting a little
time trying alternatives.

> Here's a probably lousy analogy, but it is one that comes to my mind:
> The Windows task bar.  You can move it to the top, bottom, left or
> right.  Most people do not move it every 30 minutes.  Moving it is,
> effectively, customizing its position.  But yes, the fact that Windows
> remembers the last position as the customization is fine.

Nothing overlaps with my Windows taskbar, so I don't need to move it anywhere.

> if Desktop handles that right then it lets users not worry about setting
> things up using Lisp code.  They can simply drag the frame to where they
> want it and give it the size they want, and that will be remembered
> (provided they start up with Desktop) each time.  Formidable!

That's what I'm trying to do.

> You might want to reread what I wrote about the creation of a
> minibuffer frame.  To have one, you need to create it during startup.
> That means that users do so in their Emacs startup.  And there can be at
> most one such frame.

Not exactly, though it will likely not work as expected:

(progn
   (dotimes (i 5) (make-frame '((minibuffer . only) (visibility . icon))))
   (mapcar (lambda (f) (frame-parameter f 'minibuffer)) (frame-list)))

=>

(only only only only only #<window 03599398 on  *Minibuf-0*>)

> (visibility . icon) does not affect the test, is just to avoid cluttering my desktop.
> If you implement a way for a user to choose between (a) and (b), no
> problem.  If you offer only (b) then that would be limiting for a
> user who wants to control the frame properties via setup at start time.

Not really. She could use desktop-after-read-hook to reapply settings,
for example. Some things we should allow via customization options,
some others via hooks, etc. It is too soon to decide which one belongs
to each category, I think. And customization options can always be
added later as needed.

> Users use frames for different things.  A user might well have
> particular other frames, besides the minibuffer, that s?he wants to
> have defined each time based on a startup-time setup, i.e., that s?he
> does not want to have changed by Desktop.

Yes. Currently there's no hook run just before saving the frames and
buffers, but I will have to add one. A practical example where I need
it: I very often have IELM buffers open. IELM is the kind of buffer
that does not make real sense to save&restore, because its usefulness
often depends on its state (variables changed, commands typed, etc.).
So I add it to desktop-buffers-not-to-save or
desktop-modes-not-to-save... But window-state-put will restore the
"buffer", if empty and in fundamental-mode. So I really need to be
able to run a hook before desktop--save-frames which runs
(delete-windows-on (get-buffer "*ielm*") 'all).

> IOW, once you get something like a minibuffer frame the way you generally
> want it, you want to be able to say Basta! Hands off from now on, until I
> change my mind.

Also called M-: (insert (format "(setq minibuffer-frame-alist '%S)"
(frame-parameters default-minibuffer-frame))) <RET> plus deleting the
MOF.plus some hand-tweaking. ;-)

>> I think you're talking about a desktop-save/desktop-read use case:
>> that is, you say that if you have a current setup, with a
>> minibuffer-only frame, and you do M-x desktop-read, no new
>> minibuffer-only frame should be created.
>
> Yes.
>
>> And I was talking about kill-emacs / run emacs.
>

> Meme combat - from my point of view.  Not the same use case, but I feel
> the same about both cases.


> But, as I mentioned, since a minibuffer frame must be created during
> startup

That's not really correct. You can do, at any point in time:

(let ((f (make-frame '((minibuffer . only)
      (height . 2)
      (tool-bar-lines .0)
      (menu-bar-lines . 0)))))
  (make-frame `((minibuffer . ,(minibuffer-window f)))))

> Now just maybe, if you make Desktop get in the act and try to restore
> the minibuffer frame, the user will then need to start worrying about
> just when to invoke Desktop, relative to the user code that creates the
> minibuffer frame.

M-x report-emacs-bug <RET>

> Or maybe s?he will now have to worry about having
> conditional code that checks whether desktop (which might have run first)
> has already created a standalone minibuffer, and then skip doing that
> in the user startup code.

At some point, for some combination of user customizations and use
cases, the user will have to resort to worring and checking and
configuring via hooks. I wouldn't have ~2,000 lines in my .emacs if
that were not the case.

> But the default Desktop behavior should, IMO, be the simple one (from
> a user point of view): YAGNI, i.e., Desktop hands off the minibuffer.

My "simple behavior" would be: do not treat the MOF differently than
any other frame. :-)

> I agree.  That's why I said "for a while".  There is also a risk of
> boring others and going down a rabbit hole.

You mean they aren't already there, hidding from us?

> There is more locality, not less.  Not in the sense that the minibuffer
> is always closer to the particular buffer text you're editing/reading

That's locality for me (or at least, for my visual cortex).

> Height, but not width.  When I said "long" I meant "wide".

Ah, interesting. Yes, I can see the appeal of that.

   J

RE: How to restore the layout?

[Drew Adams]

> > I was talking only about a standalone minibuffer frame.  Sorry if that
> > was not clear.  How is it different?  In the ways I've already described,
> > i.e., the uses I described as being, I think, typical.
> 
> I disagree about "typical" here. The alternate use case I'm suggesting
> is neither convoluted nor artificial.

1. I was quite clear that it is just a guess on my part wrt the typical
or common use case for a minibuffer frame.  I gave reasons why I think
this might be likely, including the fact that to have such a frame a
user must set it up during startup, and `minibuffer-frame-alist' is a
customization.

2. No one has said that anything you have suggested is convoluted or
artificial.  I don't even think that, let alone have not said it.

> > And in the fact that it uses `minibuffer-frame-alist', which supersedes
> > `default-frame-alist'.  IOW, almost the same answer for why we even have
> > a `minibuffer-frame-alist' user option.
> 
> Well, the initial frame also has a `initial-frame-alist' that
> supersedes `default-frame-alist', but you're not proposing to treat it
> different that other (non-minibuffer-only) frames.

I'm no expert on any of this stuff, but certainly not about
`initial-frame-alist'.  Its doc string, like that of `minibuffer-frame-alist',
says that it "supersedes" `default-frame-alist', without saying what that
means.

What I said about `m-f-alist' is based on my experience with it.  I have
almost no experience with `i-f-a'.  If you feel it should be handled the
same as is `m-f-a', give that a try.

> > In general, yes.  My assumption was that that is not generally the case
> > for a standalone minibuffer frame.  Whereas there can often be many
> > frames that are built off of the `default-frame-alist', and which a user
> > might well move here and there and resize, I don't see that kind of thing
> > happening typically for a minibuffer frame.
> 
> My assumption is that, just as `initial-frame-alist' is a template for
> the first frame (but changes are persistently saved by
> desktop-reuse-frames), `minbuffer-frame-alist' is a template for the
> minibuffer-only frame, but once created, the user is free to change it
> (and expect these changes to stick).

We have different assumptions wrt the typical use of `m-f-alist'.

Yes, anyone is free to change properties of the minibuffer frame after it
is created.  So what?  It does not follow that everyone or most will want
Desktop to save and restore such changes.  Time will tell, I guess.

Here's another data point you might consider: AFAIK, Desktop will save and
restore frame parameters, but those parameter values at any time do not
necessarily specify the frame completely from a user point of view.

What do I mean by that?

In oneonone.el, for example, the position and size of the minibuffer frame
is customizable.  But generally I recommend that absolute values not be 
used for this and that users instead let the code determine the width and
necessary `top' value to position the frame across the full screen width
at screen bottom.

That way, the frame is created correctly regardless of what screen you
view it on: laptop, large monitor, remote VNC window mgr...

IOW, whereas what frame parameters record are literal values, what a user
might want to express in some cases can be a behavior that does not reduce
to a literal value.  In Lisp terms, if frame paramters included functional
values then we might be talking apples & apples, but until then we are
talking apples & oranges.

Note that the recently added `fullscreen' parameter values are similar
to specifying functional behavior: they do not specify frame boundaries
explicitly but record the user wish that the frame fill the full screen
or whatever.  The implementation presumably leaves it up to the window
mgr to implement that function, and one cannot specify an arbitrary
function, but the idea is a bit similar: we do not record literal frame
coordinates & boundaries for a fullscreen frame.

If useful or common values (symbols) were implemented to encompass the
idea of a minibuffer frame extending across the screen bottom then one
would not need code to do that using code.  Until then, simply
recording and playing back frame parameters will not accomplish the
same thing.

It's just an example.

> > I nevertheless see changes to the
> > minibuffer frame due to the dynamic use of Emacs to be something (a)
> > rare and (b) you probably do not want to save.
> 
> That's the point where we disagree. That said, you have much more
> experience with minibuffer-only frames than me. It'd be good if other
> minibuffer-only-frame users would speak now.

I have experience only in a limited range.  I've made Emacs do more or
less what I want; that's all.  I can't speak to what others might want.

But I would point to the experience of lots of people with Epoch, back
in the day - FWIW.  As I mentioned, a standalone minibuffer was optional,
but it was the default.  I never saw anyone who chose not to use it (and
I saw lots of people using Epoch).  And the frame was at the bottom,
stretching the full screen width (IIRC, and I think I do).

So my own setup is so particular, it is copied from something that
lots of people used to use.  Yes, GNU Emacs has taken over the landscape,
but that was not because of Epoch's standalone minibuffer.  FWIW.

> > I think I saw that you mentioned that you cannot currently save/restore
> > a frame's font.  To me, that ability is far more important that letting
> > users record and restore any dynamic changes they might have made to a
> > standalone minibuffer frame.  It is important to me, at least.
> 
> Not saving the font parameter right now is not a decision or a
> feature, just a stopgap measure. Eventually I'll have to revamp the
> whole "save/restore frame parameters" code to allow more flexibility,
> and then I'll re-save font.

Sounds good.  That was my guess, that this is just something that you
cannot implement immediately, for whatever reasons.  Nothing wrong with
that.  It is wonderful that you are working on this general enhancement
to Desktop.

> > (I realize that not everything will be perfect in the first draft.
> > I'm just saying that, to me, restoring the font is important.)
> 
> Yes, agreed.
> 
> > Where would you expect that you would be moving it, and why?  Again,
> > I'm not talking about customizing where you want it, and perhaps
> > changing your mind about that customization once in a while.
> 
> In my tests of the minibuffer-only frame (MOF from now on), I like to
> have it near the main, or only, frame. So if I move the frame aside,
> because I want to see something that's below it (let's say I'm typing
> something related to something I'm reading in a browser tab), I
> immediately move the MOF too. I suppose that's uncommon for you
> because you put the MOF at a fixed place in the screen, likely not
> overlapping or overlapped with any other application's window. That's
> not how I work, I have Chrome open all the time, and it uses perhaps
> 80% of my screen space, so other things, including Emacs, do overlap
> it. Moving Emacs aside is a pretty common operation for me.

Got it.  I could be wrong, but I'd suggest using it for a month and then
see what you think.  Not joking.  I don't pretend to have discovered the
only way of working with frames - far from it.  But I have a right to
guess. ;-)

> > I was trying to make your job easier by pointing out that
> > in most cases no one need that feature.  But if it works well then I
> > have no problem with it.
> 
> "Works well" is not how I would define it right now. "Works most of
> the time" is more like it, but of course, that difference is quite
> important. So I don't reject at all the idea of falling back into the
> do-not-save-MOF implementation strategy; I'm just wasting a little
> time trying alternatives.

That's good to do, and not a waste, no doubt.

> > Here's a probably lousy analogy, but it is one that comes to my mind:
> > The Windows task bar.  You can move it to the top, bottom, left or
> > right.  Most people do not move it every 30 minutes.  Moving it is,
> > effectively, customizing its position.  But yes, the fact that Windows
> > remembers the last position as the customization is fine.
> 
> Nothing overlaps with my Windows taskbar, so I don't need to move it
> anywhere.

Things don't overlap my MF, unless I put them there (e.g., make something
fullscreen).  But I do hear what you are saying (and I did say it was a
lousy analogy - if it doesn't help, ignore it).
 
> > if Desktop handles that right then it lets users not worry about setting
> > things up using Lisp code.  They can simply drag the frame to where they
> > want it and give it the size they want, and that will be remembered
> > (provided they start up with Desktop) each time.  Formidable!
> 
> That's what I'm trying to do.

Great.
 
> > You might want to reread what I wrote about the creation of a
> > minibuffer frame.  To have one, you need to create it during startup.
> > That means that users do so in their Emacs startup.  And there can be at
> > most one such frame.
> 
> Not exactly, though it will likely not work as expected:
> 
> (progn
>    (dotimes (i 5) (make-frame '((minibuffer . only) (visibility . icon))))
>    (mapcar (lambda (f) (frame-parameter f 'minibuffer)) (frame-list)))

OK.

> > If a user uses Desktop to restore the last state and that state now
> > tries to also restore a saved minibuffer frame, then that restoration
> > code needs to check whether there is already a minibuffer frame, and if
> > so then either (as I said before): (a) ignore its saved info for the
> > minibuffer frame (leave the user's frame alone) or (b) MODIFY the
> > already existing minibuffer frame - as opposed to trying to create
> > another such.
> > 
> > If you implement a way for a user to choose between (a) and (b), no
> > problem.  If you offer only (b) then that would be limiting for a
> > user who wants to control the frame properties via setup at start time.
> 
> Not really. She could use desktop-after-read-hook to reapply settings,
> for example. Some things we should allow via customization options,
> some others via hooks, etc. It is too soon to decide which one belongs
> to each category, I think. And customization options can always be
> added later as needed.

Sounds like trying to make a virtue of the necessity of a particular
implementation.  I sincerely hope that you allow for both (a) and (b)
and give users a choice.

> > Users use frames for different things.  A user might well have
> > particular other frames, besides the minibuffer, that s?he wants to
> > have defined each time based on a startup-time setup, i.e., that s?he
> > does not want to have changed by Desktop.
> 
> Yes. Currently there's no hook run just before saving the frames and
> buffers, but I will have to add one.

In general, I would suggest saving stuff but letting restoration ignore
some of it, according to user preference etc.  IOW, it seems like it
would be more flexible to save and optionally not restore than to
optionally not save (and then not have the possibility of restoring).

This is assuming other things are equal, which they might not be.
But if they are, then late binding here is better: let the decision
be made at the next session.

What I said earlier about use with different monitors applies here as
well.  Your next session might be with a different monitor or on a
different platform.  Users might use desktop files across different
platforms, equipment/media, whatever.  You can easily do that now,
using desktop bookmarks, for instance.  As a general rule, it is
more flexible to let the consuming software/session decide, not the
producing software/session.

Again, assuming other things are equal, which you can judge better
than I.

> A practical example where I need
> it: I very often have IELM buffers open. IELM is the kind of buffer
> that does not make real sense to save&restore, because its usefulness
> often depends on its state (variables changed, commands typed, etc.).
> So I add it to desktop-buffers-not-to-save or
> desktop-modes-not-to-save... But window-state-put will restore the
> "buffer", if empty and in fundamental-mode. So I really need to be
> able to run a hook before desktop--save-frames which runs
> (delete-windows-on (get-buffer "*ielm*") 'all).

Or accomplish the same end some other way.  Worth thinking about.

> > IOW, once you get something like a minibuffer frame the way you generally
> > want it, you want to be able to say Basta! Hands off from now on, until I
> > change my mind.
> 
> Also called M-: (insert (format "(setq minibuffer-frame-alist '%S)"
> (frame-parameters default-minibuffer-frame))) <RET> plus deleting the
> MOF.plus some hand-tweaking. ;-)

Hopefully accomplish the same end another way.  This is something users
should be able to do easily.

> > But, as I mentioned, since a minibuffer frame must be created during
> > startup
> 
> That's not really correct. You can do, at any point in time:
> 
> (let ((f (make-frame '((minibuffer . only)
>       (height . 2)
>       (tool-bar-lines .0)
>       (menu-bar-lines . 0)))))
>   (make-frame `((minibuffer . ,(minibuffer-window f)))))

AFAIK, you will never be able to get rid of the frame created initially,
which has its own minibuffer.  That was the point here.  If you want a
standalone minibuffer frame, and if you want it to be the only such
(which I would again argue is the typical case of MF users), then AFAIK
you must create the MF at the outset.

Believe me, I've submitted enough bug reports for which I had to point
out a startup sequence, because adding a standalone minibuffer frame
later does not give you the same behavior.

> > Now just maybe, if you make Desktop get in the act and try to restore
> > the minibuffer frame, the user will then need to start worrying about
> > just when to invoke Desktop, relative to the user code that creates the
> > minibuffer frame.
> 
> M-x report-emacs-bug <RET>

Better to think about some of these things ahead of time.  Sounds like
you're thinking more in terms of hooks to dance around Desktop than
customization options to prevent it from doing the things you would have
users dance around.  I could be wrong but that's my impression based on
some of what you wrote above.  I would sooner you implemented (a) and
(b) above, and let users choose.

> > Or maybe s?he will now have to worry about having
> > conditional code that checks whether desktop (which might have run first)
> > has already created a standalone minibuffer, and then skip doing that
> > in the user startup code.
> 
> At some point, for some combination of user customizations and use
> cases, the user will have to resort to worring and checking and
> configuring via hooks. I wouldn't have ~2,000 lines in my .emacs if
> that were not the case.

Or decide it's not worth it and not use Desktop to restore frames.

I hope, at least, that users will be able to use Desktop without the
frame/window restoration.  And I hope they will be able to restore
windows & frames without necessarily restoring all the other stuff
that Desktop can handle.

IOW, I hope we give users control over the various things that Desktop
can save & restore.  And I hope that control will be available both in
terms of saving (don't bother saving stuff you know you don't want to
restore) and in terms of restoring (save, but do not restore if told not
to - see above for the flexibility this offers, at a cost of
save/restore time and desktop-file storage space).

> > But the default Desktop behavior should, IMO, be the simple one (from
> > a user point of view): YAGNI, i.e., Desktop hands off the minibuffer.
> 
> My "simple behavior" would be: do not treat the MOF differently than
> any other frame. :-)

Which is why I wrote "from a user point of view".  I'm not interested
here with simplicity of implementation.  Of course, we can disagree about
what is simpler for a user.  Again, I'd point to Epoch users...

> > There is more locality, not less.  Not in the sense that the minibuffer
> > is always closer to the particular buffer text you're editing/reading
> 
> That's locality for me (or at least, for my visual cortex).

But you're not necessarily acting on or interacting with a single buffer
or frame, in general.

That's another difference I didn't mention.  I use the minibuffer more,
but I also use it to act on multiple buffers and frames during the same
minibuffer "session" (the command calling for minibuffer input, completion
in particular).  When using the minibuffer, even when my eye is not on
the minibuffer and not on *Completions*, it can easily move among multiple frames/buffers.  In this context, the most central, static, or "local"
location during the interaction is the minibuffer - it is the center of
the action.

I'm not saying that anyone needs to use a standalone minibuffer. 
I'm saying that someone who does do that has a single place to look
for command input/output.

You said:

> In my tests of the minibuffer-only frame (MOF from now on), I like to
> have it near the main, or only, frame.

Wait until you are interacting with multiple frames, and there is NO
"main, or only, frame".  Then we can talk again about "locality". ;-)

> > Height, but not width.  When I said "long" I meant "wide".
> 
> Ah, interesting. Yes, I can see the appeal of that.

Cheers - and thanks again for working on this.  It will be a welcome
addition to Emacs.

Re: How to restore the layout?

[Juanma Barranquero]

On Tue, Jul 2, 2013 at 9:40 PM, Drew Adams <drew.adams@oracle.com> wrote:

> 2. No one has said that anything you have suggested is convoluted or
> artificial.  I don't even think that, let alone have not said it.

Please, don't take my comment as more than it was, just that I thought
that my use case is equally common. Wasn't accusing you of anything.
:-)

> Yes, anyone is free to change properties of the minibuffer frame after it
> is created.  So what?  It does not follow that everyone or most will want
> Desktop to save and restore such changes.  Time will tell, I guess.

Sure.

> Note that the recently added `fullscreen' parameter values are similar
> to specifying functional behavior: they do not specify frame boundaries
> explicitly but record the user wish that the frame fill the full screen
> or whatever.  The implementation presumably leaves it up to the window
> mgr to implement that function, and one cannot specify an arbitrary
> function, but the idea is a bit similar: we do not record literal frame
> coordinates & boundaries for a fullscreen frame.

I agree that ways of specifying more generic behavior would be good.

> If useful or common values (symbols) were implemented to encompass the
> idea of a minibuffer frame extending across the screen bottom then one
> would not need code to do that using code.

For the "across the screen" bit you can of course use (fullscreen .
fullwidth), though I see an interesting bug where the frame does not
really goes fullwidth until selected. But for positioning it at the
bottom, (top - N) is only a crude tool that requires some code.

> Yes, GNU Emacs has taken over the landscape,
> but that was not because of Epoch's standalone minibuffer.  FWIW.

I'm sure of that ;-)

> Sounds good.  That was my guess, that this is just something that you
> cannot implement immediately, for whatever reasons.

Because it breaks restoring after the roundtrip GUI -> tty -> GUI. But
it is something I must fix, like the warning messages in that same
roundtrip about invalid colors.

> Sounds like trying to make a virtue of the necessity of a particular
> implementation.

No, I'm not. Just that I can see many things that could be
customizable (via defcustom, I mean) but I don't think all should be;
only the common ones. At the end, which ones do get their own
customization option and which ones do not is not mine (alone) to
decide, it's a community thing (and of course, anyone can add further
options afterwards even if they didn't strike me as necessary).

> In general, I would suggest saving stuff but letting restoration ignore
> some of it, according to user preference etc.  IOW, it seems like it
> would be more flexible to save and optionally not restore than to
> optionally not save (and then not have the possibility of restoring).
>
> This is assuming other things are equal, which they might not be.
> But if they are, then late binding here is better: let the decision
> be made at the next session.

In general, I agree.

As for the devil in the details: there are things that make sense to
delete on saving (like unwanted windows). And in some cases, the code
is cleaner if you delete on saving. desktop--restore-frames is already
more complex than desktop--save-frames, and I don't think that trend
will change.

Something to decide feature by feature.

> Or accomplish the same end some other way.  Worth thinking about.

Yes, of course. Perhaps killing some windows/buffers will be a common
enough operation that some defcustom should be added, for example.

In fact, the example I gave is tricky, because I don't want to delete
IELM windows while I'm working (for example, if I do M-x desktop-save
during a session). So perhaps that's one of these cases where deleting
on restoring is more effective and simple.

> Hopefully accomplish the same end another way.  This is something users
> should be able to do easily.

I'm not sure what the UI would be for that.

> AFAIK, you will never be able to get rid of the frame created initially,
> which has its own minibuffer.  That was the point here.  If you want a
> standalone minibuffer frame, and if you want it to be the only such
> (which I would again argue is the typical case of MF users), then AFAIK
> you must create the MF at the outset.

Yes, you can delete the initial frame, just try this:

(let* ((s (selected-frame))
       (f (make-frame '((minibuffer . only)
                        (height . 2)
                        (tool-bar-lines .0)
                        (menu-bar-lines . 0)))))
  (make-frame `((minibuffer . ,(minibuffer-window f))))
  (delete-frame s))

> Believe me, I've submitted enough bug reports for which I had to point
> out a startup sequence, because adding a standalone minibuffer frame
> later does not give you the same behavior.

Oh, I think the minibuffer should give the same behavior, but I have
not trouble believing you that it doesn't. Lots of tricky details.

> Better to think about some of these things ahead of time.  Sounds like
> you're thinking more in terms of hooks to dance around Desktop than
> customization options to prevent it from doing the things you would have
> users dance around.  I could be wrong but that's my impression based on
> some of what you wrote above.  I would sooner you implemented (a) and
> (b) above, and let users choose.

As said above, it's not that I think that, it's that the number of
possible customizations is unbounded, while the number of defcustoms
we can sensibly add is bounded and relatively small, so we have to
pick our battles.

> Or decide it's not worth it and not use Desktop to restore frames.

That's a possibility I cannot avoid in any way.

> I hope, at least, that users will be able to use Desktop without the
> frame/window restoration.

(setq desktop-restore-frames nil)

Or, if I we decide to turn it into a pseudo-minor mode, like
desktop-save-mode, (desktop-restore-frames -1).

> And I hope they will be able to restore
> windows & frames without necessarily restoring all the other stuff
> that Desktop can handle.

As discussed previously, that's a worthwhile goal, but not one I'm
pursuing right now.

> But you're not necessarily acting on or interacting with a single buffer
> or frame, in general.

*In general*, yes, I do. If not a single buffer, at least a single
window, two at most, more than 99% of the time. And definitely a
single frame.

> I'm not saying that anyone needs to use a standalone minibuffer.
> I'm saying that someone who does do that has a single place to look
> for command input/output.

Yes, of course. At this point, I'm just explaining why do I think that
it isn't a good setup *for me*.

> Wait until you are interacting with multiple frames, and there is NO
> "main, or only, frame".  Then we can talk again about "locality". ;-)

My brain is wired to look at nearby places, not always at the same
place. Again, that's why recentering scrolling doesn't work for me. I
could put my eyes in the center line of the window and enjoy the
recentering, but I do not. I really do not.

    J

Re: How to restore the layout?

[martin rudalics]

 > This is intended to be run before desktop--save-frames, I suppose?

Yes, because it installs a frame parameter that should get saved by
desktop--save-frames.

 > I'm seeing a frame height problem on Windows 7 with side-aligned
 > frames (=> the ones you get by typing Windows + Left or Windows +
 > Right).
 >
 > With a minimal .emacs, containing:
 >
 > (desktop-save-mode 1)
 > (setq desktop-restore-frames t)
 >
 > then
 >
 > emacs
 > W-left
 > C-x 5 2
 > W-right
 > ;;; at this point, both frames height's are 65 lines
 > C-x 5 o
 > C-x C-c
 > emacs
 > ;;; now left frame's height is 65 lines, right frame's height is 68;
 > its top is also a bit higher

3 lines reserved for the toolbar, obviously.

 > Comparing the saved state before & after, there only differences are
 > the height and top parameters of the second frame, and obviously the
 > total-height in the window-state. Whatever happens, happens when
 > creating a new frame with (make-frame-on-display display saved-state).
 >
 > If you add
 >
 > (setq default-frame-alist '((tool-bar-lines . 0)))
 >
 > to .emacs, it doesn't happen anymore. ISTR some old bug report about this
 >
 > Any idea how to fix that?

No.  In a `fit-frame-to-buffer' function you find in my window.el I use
a workaround with a comment going as

	     ;; When tool-bar-mode is enabled and we just created a new
	     ;; frame, reserve lines for toolbar resizing.  Needed
	     ;; because for reasons unknown to me Emacs (1) reserves one
	     ;; line for the toolbar when making the initial frame and
	     ;; toolbars are enabled, and (2) later adds the remaining
	     ;; lines needed.  Our code runs IN BETWEEN (1) and (2).
	     ;; YMMV when you're on a system that behaves differently.

So this is still an unsolved mystery, probably to straighten out
differences with external toolbar implementations.  I can look into it
again but do not expect too much.  Drew should have experienece with
this problem as well.

martin

Re: How to restore the layout?

[martin rudalics]

 > Not saving the font parameter right now is not a decision or a
 > feature, just a stopgap measure. Eventually I'll have to revamp the
 > whole "save/restore frame parameters" code to allow more flexibility,
 > and then I'll re-save font.

Note that the font parameter determines the size of the frame and most
of its building blocks (toolbar, scrollbars, fringes, ...) on screen.
Most problems I encounter with frames are an (in-)direct consequence of
this.

martin

Re: How to restore the layout?

[martin rudalics]

 > AFAIK, you will never be able to get rid of the frame created initially,
 > which has its own minibuffer.  That was the point here.  If you want a
 > standalone minibuffer frame, and if you want it to be the only such
 > (which I would again argue is the typical case of MF users), then AFAIK
 > you must create the MF at the outset.

With emacs -Q

(let ((frame (selected-frame))
       frame-1 frame-2)
   (setq frame-1 (make-frame '((minibuffer . only))))
   (setq default-minibuffer-frame frame-1)
   (setq frame-2 (make-frame '((minibuffer . none))))
   (delete-frame frame))

martin

Re: How to restore the layout?

[martin rudalics]

 > In fact, the example I gave is tricky, because I don't want to delete
 > IELM windows while I'm working (for example, if I do M-x desktop-save
 > during a session).

The only thing `desktop-save' is allowed to do is to change its own
window or frame parameters (and its own variables of course).

martin

Re: How to restore the layout?

[Juanma Barranquero]

On Wed, Jul 3, 2013 at 11:27 AM, martin rudalics <rudalics@gmx.at> wrote:

> 3 lines reserved for the toolbar, obviously.

Yes.

> No.  In a `fit-frame-to-buffer' function you find in my window.el I use
> a workaround with a comment going as
>
>              ;; When tool-bar-mode is enabled and we just created a new
>              ;; frame, reserve lines for toolbar resizing.  Needed
>              ;; because for reasons unknown to me Emacs (1) reserves one
>              ;; line for the toolbar when making the initial frame and
>              ;; toolbars are enabled, and (2) later adds the remaining
>              ;; lines needed.  Our code runs IN BETWEEN (1) and (2).
>              ;; YMMV when you're on a system that behaves differently.
>
> So this is still an unsolved mystery, probably to straighten out
> differences with external toolbar implementations.  I can look into it
> again but do not expect too much.  Drew should have experienece with
> this problem as well.

Has someone filed a bug report about this?

   J

Re: How to restore the layout?

[Juanma Barranquero]

On Wed, Jul 3, 2013 at 11:27 AM, martin rudalics <rudalics@gmx.at> wrote:

> Note that the font parameter determines the size of the frame and most
> of its building blocks (toolbar, scrollbars, fringes, ...) on screen.

Yes. Currently it works because there's few people using the feature
yet, and they do not change the default font(set) between invocations
of Emacs. But I'll fix it soonish.

   J

Re: How to restore the layout?

[Juanma Barranquero]

On Wed, Jul 3, 2013 at 11:34 AM, martin rudalics <rudalics@gmx.at> wrote:

> The only thing `desktop-save' is allowed to do is to change its own
> window or frame parameters (and its own variables of course).

Allowed by whom?

   J

Re: How to restore the layout?

[martin rudalics]

 > Has someone filed a bug report about this?

Not that I know.  I don't even know whether it's a bug.  And reverting
the order how we do things might easily break something else.

The underlying problem is, as I discussed a while ago with Eli and Jan,
that Emacs is allowed to change the overall pixel size of a frame when
adding or removing certain things like scrollbars or menubars, or when
changing the font, but not when adding or removing the toolbar.
Apparently, many people like that behavior and we have to live with the
consequences :-(

martin

Re: How to restore the layout?

[martin rudalics]

>> The only thing `desktop-save' is allowed to do is to change its own
>> window or frame parameters (and its own variables of course).
> 
> Allowed by whom?

By us, if you agree ;-)

martin

RE: How to restore the layout?

[Drew Adams]

>  > AFAIK, you will never be able to get rid of the frame created initially,
>  > which has its own minibuffer.  That was the point here.  If you want a
>  > standalone minibuffer frame, and if you want it to be the only such
>  > (which I would again argue is the typical case of MF users), then AFAIK
>  > you must create the MF at the outset.
>
> (let ((frame (selected-frame))
>        frame-1 frame-2)
>    (setq frame-1 (make-frame '((minibuffer . only))))
>    (setq default-minibuffer-frame frame-1)
>    (setq frame-2 (make-frame '((minibuffer . none))))
>    (delete-frame frame))

(Similar reply from Juanma.)

I stand corrected; thanks.  And it is the case in older Emacs versions also.
Dunno what exactly I was thinking of.  Sorry for the misinformation, and
thanks for the correction.

RE: How to restore the layout?

[Drew Adams]

> > I hope, at least, that users will be able to use Desktop without the
> > frame/window restoration.
> 
> (setq desktop-restore-frames nil)
> 
> Or, if I we decide to turn it into a pseudo-minor mode, like
> desktop-save-mode, (desktop-restore-frames -1).
> 
> > And I hope they will be able to restore
> > windows & frames without necessarily restoring all the other stuff
> > that Desktop can handle.
> 
> As discussed previously, that's a worthwhile goal, but not one I'm
> pursuing right now.

I'm not familiar with the code, but a priori it feels like that should
be doable and done at the outset.  Is there some reason it would be hard
to stop Desktop from saving (or restoring) the other stuff?  I'm not
asking you to go into detail here, just wondering what the difficulty is
in general terms.  Is the desktop.el code written in such a way that that
would be messy to do?

> > But you're not necessarily acting on or interacting with a single buffer
> > or frame, in general.
> 
> *In general*, yes, I do. If not a single buffer, at least a single
> window, two at most, more than 99% of the time. And definitely a
> single frame.

I didn't mean you, personally.  If someone (even you) interacts with only
one or two frames 99% of the time then there is not much case to be
made, from my point of view, for them to use a standalone minibuffer frame.

IOW, why argue that people with standalone minibuffer frames lose locality
if the supporting case is a single frame scenario?  Sounds a bit like
saying that a teaspoon is not the best pot for boiling lots of water.

> Yes, of course. At this point, I'm just explaining why do I think that
> it isn't a good setup *for me*.

OK.  But I thought we were discussing the "locality" argument you raised
generally.

Anyway, please keep up the good work, and bon courage !

RE: How to restore the layout?

[Drew Adams]

Haven't been following this part of the thread; dunno what I missed.

> No.  In a `fit-frame-to-buffer' function you find in my window.el

Where can I find that?

> I use a workaround with a comment going as
> 
> 	     ;; When tool-bar-mode is enabled and we just created a new
> 	     ;; frame, reserve lines for toolbar resizing.  Needed
> 	     ;; because for reasons unknown to me Emacs (1) reserves one
> 	     ;; line for the toolbar when making the initial frame and
> 	     ;; toolbars are enabled, and (2) later adds the remaining
> 	     ;; lines needed.  Our code runs IN BETWEEN (1) and (2).
> 	     ;; YMMV when you're on a system that behaves differently.
> 
> So this is still an unsolved mystery, probably to straighten out
> differences with external toolbar implementations.  I can look into it
> again but do not expect too much.  Drew should have experienece with
> this problem as well.

I'm afraid I don't have anything to offer here, sorry.  My frame-fitting
code pretty much side-steps handling of the tool bar (and it tries to
DTRT for multiple Emacs versions).  Here is a comment from the code:

;; `extra-lines' for minimum frame height.  Starting with Emacs 21+,
;; `set-frame-size' includes the tool-bar and the minibuffer.  For Emacs
;; without a toolkit, the one-line menu-bar is also included - add 1 line
;; for that.  Add 1 line for the minibuffer, unless it is standalone.
;; Perhaps we should also take into account a possible horizontal scroll
;; bar, but we don't do that.

To allow for the tool bar I just add
(cdr (assq 'tool-bar-lines (frame-parameters frame))) to the needed height.

A bigger problem for me is wrapped menu-bar lines (I guess the same
problem is there for a wrapped tool bar too).  This is my code comment:

;; We can't really know whether menu-bar gets wrapped.
;; Assume it wraps once.

RE: How to restore the layout?

[Drew Adams]

> > Note that the font parameter determines the size of the frame and most
> > of its building blocks (toolbar, scrollbars, fringes, ...) on screen.

And thank goodness for that interaction.  It provides a way to resize
things together.

> Yes. Currently it works because there's few people using the feature
> yet, and they do not change the default font(set) between invocations
> of Emacs. But I'll fix it soonish.

That "fix" sounds ominous, but perhaps I'm becoming paranoid.

I don't understand what you are saying there (what works? what is the
feature? what is the relation to changing font(set) between invocations?)

I hope that changing the font size will continue to resize the frame and
associated building blocks.  If you choose to offer some other behavior,
please at least preserve this longstanding behavior as well, as an
alternative.

I make heavy use of this feature (a frame's font driving size in
general).  It would break most of what I use everyday if this feature
were to be "fixed" away.

Re: How to restore the layout?

[Juanma Barranquero]

On Wed, Jul 3, 2013 at 2:42 PM, martin rudalics <rudalics@gmx.at> wrote:

> Not that I know.  I don't even know whether it's a bug.

Well...

> And reverting
> the order how we do things might easily break something else.

Yes,

> Apparently, many people like that behavior and we have to live with the
> consequences :-(

And yet, I find very hard to believe that, when toolbars are enabled, this code

  (let ((params '((width . 60) (height . 25))))
    (make-frame params)
    (modify-frame-parameters (make-frame) params))

is allowed to create two frames of different height. That's the very
model of a modern major bug.

    J

Re: How to restore the layout?

[Juanma Barranquero]

On Wed, Jul 3, 2013 at 4:20 PM, Juanma Barranquero <lekktu@gmail.com> wrote:

>   (let ((params '((width . 60) (height . 25))))
>     (make-frame params)
>     (modify-frame-parameters (make-frame) params))

I suppose I can work around the issue by modifying the saved frame
parameter 'height and substracting (cdr (assq 'tool-bar-lines PARAMS))
while restoring.

Aside: How come that there's no defuns assq-key, assq-value? Yes, they
are trivial; yes, they do introduce an overhead. And still, I've
written (cdr (assq ..)) so many times already that I'm starting to
like the idea of saving the parameter list as a plist just to be able
to use plist-(get|put)... Grr.

    J

Re: How to restore the layout?

[Juanma Barranquero]

On Wed, Jul 3, 2013 at 2:42 PM, martin rudalics <rudalics@gmx.at> wrote:

> By us, if you agree ;-)

desktop-save should be sort of idempotent, so yes, doing things that
modify the setup seems misguided.

But I don't understand what do you mean by "its own window or frame
parameters". Who's "it" refering to?

   J

Re: How to restore the layout?

[Juanma Barranquero]

On Wed, Jul 3, 2013 at 4:08 PM, Drew Adams <drew.adams@oracle.com> wrote:

> I'm not familiar with the code, but a priori it feels like that should
> be doable and done at the outset.  Is there some reason it would be hard
> to stop Desktop from saving (or restoring) the other stuff?  I'm not
> asking you to go into detail here, just wondering what the difficulty is
> in general terms.

The "other stuff" is buffers (and a few global variables, but that's
almost irrelevant). window-state depends on buffers. Of course it is
already possible to restore a window and find that its buffer is
missing (currently, I think the end result is that the buffer will be
recreated in fundamental mode). But it does not make much sense not to
save buffers but do save frames and windows, unless and until we
define an UI to allow the user to more precisely explain what does she
want to save and what doesn't want to.

Which seems useful, but not something I'm going to worry about right now.

> IOW, why argue that people with standalone minibuffer frames lose locality
> if the supporting case is a single frame scenario?  Sounds a bit like
> saying that a teaspoon is not the best pot for boiling lots of water.

I've never argued that standalone minibuffer frames lose locality.
I've argued that they lose it for me. They are farther, and in the few
cases that I use two or more frames, more so.

> OK.  But I thought we were discussing the "locality" argument you raised
> generally.

No. Of course no. That's why I've mentioned my problems with
recentering scrolling. I do know it's not a general problem, because
many users enjoy recentering scrolling, which to me is so incredibly
annoying that I would literally be unable to use Emacs if I weren't
able to customize away that "feature". In the same vein, many people
find useful to have things at the same location in the screen (that's
why the taskbar does exist, after all).

   J

Re: How to restore the layout?

[Juanma Barranquero]

On Wed, Jul 3, 2013 at 4:08 PM, Drew Adams <drew.adams@oracle.com> wrote:

> That "fix" sounds ominous, but perhaps I'm becoming paranoid.

Just a little bit ;-)

> (what works?

Saving and restoring frames, which should (and could) produce unwanted
results because I don't save the font parameter.

> what is the feature?

The same one I'm developing. Save&restore frames&windows.

> what is the relation to changing font(set) between invocations?)

That currently, if you save a frame, and then start Emacs with another
fontset, and then desktop-read, the frames will not have the same size
(pixel-wise), which can be a problem for big frames or frames where
the exact size is important.

If the font parameter were saved, recreating the frame would use it.

I'm QUITE afraid you will now say that in some cases you want the font
saved (you already said as much), but in other cases you would the
frames to be "transparent" to the font, so restoring them woul inherit
the current default font of the running Emacs.

> I hope that changing the font size will continue to resize the frame and
> associated building blocks.

Yes. The font value of a frame parameter cannot preclude you doing
(set-default-font "DejaVus Sans Mono-15" nil t) and changing every
frame in sight.

> I make heavy use of this feature (a frame's font driving size in
> general).  It would break most of what I use everyday if this feature
> were to be "fixed" away.

For features, all input is welcome. For bugs, I would prefer if you
could wait untill you stumble upon it ;-)

   J

RE: How to restore the layout?

[Drew Adams]

> If the font parameter were saved, recreating the frame would use it.

Good.

> I'm QUITE afraid you will now say that in some cases you want the font
> saved (you already said as much),

Yes, of course.

> but in other cases you would the frames to be "transparent" to the
> font, so restoring them woul inherit the current default font of
> the running Emacs.

No, except for user-specified exceptions.

A notable exception is a standalone minibuffer frame.  I want at least
the possibility to tell Desktop not to restore (and even not to save)
such a frame; IOW, hands-off.

And I am still of the opinion that folks using a standalone minibuffer
frame will typically not want additional minibuffers (I'd guess 99.999%
of the time, but I could be wrong of course).  So I think it would make
sense for this particular exception to be the default case.

To cite Epoch again, there were two possibilities only: (1) use a
standalone minibuffer frame, in which case there were no other
minibuffers, or (2) have a minibuffer in each frame.  (#1 was the
default, and I never saw anyone choose #2.

In Epoch there was no chimera possibility such as exists in GNU Emacs.
Perhaps it is good that GNU Emacs allows for such a possibility, but
IMHO it should not be encouraged - or even allowed for when designing
something like Desktop frame support.  I just do not see a use case
for mixing a standalone minibuffer frame and other frames that have
their own minibuffers.  No one has spoken up to the contrary, and I
doubt you ever will find someone who makes use of that odd possibility.

To be clear:

Yes, Desktop should save and restore the `font' parameter in general.
Yes, users should be able to specify certain frames or types of frames
that they do not want saved or that they do not want restored.
Yes, users should be able to specify particular frame parameters that
they do not want saved or that they do not want restored in general.
Yes, users should be able to specify particular frame parameters that
they do not want saved (or...restored) for particular frames or
particular types of frames.

IOW, some of the design questions that you are raising should in fact
be user-specifiable preferences, if that is at all possible.  Desktop
should provide the knobs for users to easily adjust Desktop to get
different behaviors.  One size will not fit all.  That does not mean,
of course, that Desktop cannot or should not have a simple-to-understand
default behavior.

Whether you can provide all of that flexibility at the outset I don't
know, but it should be a goal, IMO.  And I'm guessing that it makes
sense to consider this from the outset, to avoid painting into a corner.
But I'm not familiar with your implementation/design and I can't really
say anything specific about this.  Just a general heads-up, something
to keep in mind.

> > I hope that changing the font size will continue to resize the
> > frame and associated building blocks.
> 
> Yes. The font value of a frame parameter cannot preclude you doing
> (set-default-font "DejaVus Sans Mono-15" nil t) and changing every
> frame in sight.
> 
> > I make heavy use of this feature (a frame's font driving size in
> > general).  It would break most of what I use everyday if this feature
> > were to be "fixed" away.
> 
> For features, all input is welcome. For bugs, I would prefer if you
> could wait untill you stumble upon it ;-)

100% agreed.  (I don't think I've spoken about any bugs.)

Re: How to restore the layout?

[martin rudalics]

 > And yet, I find very hard to believe that, when toolbars are enabled, this code
 >
 >   (let ((params '((width . 60) (height . 25))))
 >     (make-frame params)
 >     (modify-frame-parameters (make-frame) params))
 >
 > is allowed to create two frames of different height. That's the very
 > model of a modern major bug.

It could be also related to this part of x_figure_window_size:

   /* This used to be done _before_ calling x_figure_window_size, but
      since the height is reset here, this was really a no-op.  I
      assume that moving it here does what Gerd intended (although he
      no longer can remember what that was...  ++KFS, 2003-03-25.  */

   /* Add the tool-bar height to the initial frame height so that the
      user gets a text display area of the size he specified with -g or
      via .Xdefaults.  Later changes of the tool-bar height don't
      change the frame size.  This is done so that users can create
      tall Emacs frames without having to guess how tall the tool-bar
      will get.  */
   if (toolbar_p && FRAME_TOOL_BAR_HEIGHT (f))

So maybe you should file a bug report, at least to find out whether this
happens on all platforms.

martin

Re: How to restore the layout?

[martin rudalics]

 > But I don't understand what do you mean by "its own window or frame
 > parameters". Who's "it" refering to?

desktop.  It should be allowed to set and modify any parameters prefixed
with `desktop-'.  These parameters are private to the desktop code.

martin

Re: How to restore the layout?

[Juanma Barranquero]

On Thu, Jul 4, 2013 at 11:35 AM, martin rudalics <rudalics@gmx.at> wrote:

> desktop.  It should be allowed to set and modify any parameters prefixed
> with `desktop-'.  These parameters are private to the desktop code.

Well, desktop-save/desktop-read obviously should be allowed to set and
modify desktop-* parameters. But not only these (font and display are
good examples of ones we'll have to modify or remove in some cases).

   J

Re: How to restore the layout?

[Angelo Graziosi]

Some update..

With the GTK build of trunk on Cygwin [1] I notice the following.. [2]

Suppose I start Emacs without any desktop file. It starts with the 
default frame almost a square. Now I click on maximize button and the 
frame has the width of the Windows desktop (about 160 columns) and the 
height just a line above the Windows status bar [3].

After this I quit from Emacs, it asks to save desktop (Yes), I restart 
Emacs... It starts with a frame whose width is as that of Windows 
desktop (OK) but the height is N-4 lines and the maximized button is 
*not* selected. Maximizing, the frame gains another line (N-3).

I notice this only with the Cygwin build. On Ubuntu and Kubuntu the 
frame is restored always with the maximize button selected and takes 
always N-2 lines. It is really maximized!


Ciao
Angelo.


---
[1] On XP the windows has on top right corner 3 buttons (from left to 
right): minimize, maximize and close

[2] To the init file I have added
(setq desktop-restore-frames t)

[3] If the Windows desktop has N+2 lines (+2 for the status bar) then 
the Emacs frame maximized has N-3 lines

Re: How to restore the layout?

[Juanma Barranquero]

On Thu, Jul 4, 2013 at 10:41 PM, Angelo Graziosi
<angelo.graziosi@alice.it> wrote:

> With the GTK build of trunk on Cygwin [1] I notice the following.. [2]

I can not test the Cygwin build, but in Emacs for Windows, what Emacs
considers a "maximized" or a "fullscreen" frame is not really a
maximized frame (window manager style, I mean). If I maximize
(wm-style) a frame and exit Emacs, when I restart it I get a frame of
the same size, but neither maximized.nor in the same exact location.

BTW, if you disable the tool bar before saving (adding (tool-bar-lines
. 0) to default-frame-alist, for example), do you see any difference?

   J

>
> Suppose I start Emacs without any desktop file. It starts with the default
> frame almost a square. Now I click on maximize button and the frame has the
> width of the Windows desktop (about 160 columns) and the height just a line
> above the Windows status bar [3].
>
> After this I quit from Emacs, it asks to save desktop (Yes), I restart
> Emacs... It starts with a frame whose width is as that of Windows desktop
> (OK) but the height is N-4 lines and the maximized button is *not* selected.
> Maximizing, the frame gains another line (N-3).
>
> I notice this only with the Cygwin build. On Ubuntu and Kubuntu the frame is
> restored always with the maximize button selected and takes always N-2
> lines. It is really maximized!
>
>
> Ciao
> Angelo.
>
>
> ---
> [1] On XP the windows has on top right corner 3 buttons (from left to
> right): minimize, maximize and close
>
> [2] To the init file I have added
> (setq desktop-restore-frames t)
>
> [3] If the Windows desktop has N+2 lines (+2 for the status bar) then the
> Emacs frame maximized has N-3 lines

Re: How to restore the layout?

[Angelo Graziosi]

Il 04/07/2013 23.34, Juanma Barranquero ha scritto:
> On Thu, Jul 4, 2013 at 10:41 PM, Angelo Graziosi
> <angelo.graziosi@alice.it> wrote:
>
>> With the GTK build of trunk on Cygwin [1] I notice the following.. [2]
>
> I can not test the Cygwin build, but in Emacs for Windows, what Emacs
> considers a "maximized" or a "fullscreen" frame is not really a
> maximized frame (window manager style, I mean). If I maximize
> (wm-style) a frame and exit Emacs, when I restart it I get a frame of
> the same size, but neither maximized.nor in the same exact location.

I think it is the same I see here... It seems as a Windows window 
manager "effect"..

>
> BTW, if you disable the tool bar before saving (adding (tool-bar-lines
> . 0) to default-frame-alist, for example), do you see any difference?

Yes, Emacs is restored "maximized", i.e. N lines, but the maximize 
button is not selected (and not tool bar, obviously)

Ciao,
Angelo.

>
>     J
>
>>
>> Suppose I start Emacs without any desktop file. It starts with the default
>> frame almost a square. Now I click on maximize button and the frame has the
>> width of the Windows desktop (about 160 columns) and the height just a line
>> above the Windows status bar [3].
>>
>> After this I quit from Emacs, it asks to save desktop (Yes), I restart
>> Emacs... It starts with a frame whose width is as that of Windows desktop
>> (OK) but the height is N-4 lines and the maximized button is *not* selected.
>> Maximizing, the frame gains another line (N-3).
>>
>> I notice this only with the Cygwin build. On Ubuntu and Kubuntu the frame is
>> restored always with the maximize button selected and takes always N-2
>> lines. It is really maximized!
>>
>>
>> Ciao
>> Angelo.
>>
>>
>> ---
>> [1] On XP the windows has on top right corner 3 buttons (from left to
>> right): minimize, maximize and close
>>
>> [2] To the init file I have added
>> (setq desktop-restore-frames t)
>>
>> [3] If the Windows desktop has N+2 lines (+2 for the status bar) then the
>> Emacs frame maximized has N-3 lines

Re: How to restore the layout?

[Juanma Barranquero]

On Fri, Jul 5, 2013 at 1:10 AM, Angelo Graziosi
<angelo.graziosi@alice.it> wrote:

> I think it is the same I see here... It seems as a Windows window manager
> "effect"..

I think it's an Emacs limitation that it doesn't really use the window
manager maximization. Which is strange, because it is available:

  (w32-send-sys-command #xf030)

et voilà. The problem being, I think, that we have no reliable way to
know wheter an Emacs frame is in that state (there's left and top
being -8, but that depends on UI settings).

I think at this point the only sensible thing to do is to recommend
people wanting to save & restore frames to use
toggle-frame-(maximized|fullscreen) instead of wm maximization. :-(

   J

Re: How to restore the layout?

[martin rudalics]

 > Well, desktop-save/desktop-read obviously should be allowed to set and
 > modify desktop-* parameters. But not only these (font and display are
 > good examples of ones we'll have to modify or remove in some cases).

`desktop-read' should.  But not `desktop-save', IMO.

martin

Re: How to restore the layout?

[martin rudalics]

 > I can not test the Cygwin build, but in Emacs for Windows, what Emacs
 > considers a "maximized" or a "fullscreen" frame is not really a
 > maximized frame (window manager style, I mean). If I maximize
 > (wm-style) a frame and exit Emacs, when I restart it I get a frame of
 > the same size, but neither maximized.nor in the same exact location.

I think at some point of time we virtually do get a maximized frame but
setting some other frame parameter (like the scrollbar or the size
itself) spoils it later on.  We will have to inspect the order how
parameters get evaluated - the mixture of initial and default parameters
is sufficient pain in this regard already - and maybe find a better one.

martin

Re: How to restore the layout?

[martin rudalics]

 > I think it is the same I see here... It seems as a Windows window
 > manager "effect"..

I'm sure it's an Emacs "effect".

 >> BTW, if you disable the tool bar before saving (adding (tool-bar-lines
 >> . 0) to default-frame-alist, for example), do you see any difference?
 >
 > Yes, Emacs is restored "maximized", i.e. N lines, but the maximize
 > button is not selected (and not tool bar, obviously)

I think this clearly hints that the the toolbar is the culprit with
respect to the size.  Now please try to (1) remove the size parameters
from the desktop file, (2) check and tell us whether it contains a
maximize request, and (3) try again with the thus modified desktop file.
(And save that desktop file somewhere so it doesn't get overwritten -
maybe we have to remove some more parameters to get the maximize request
come through.)

martin

Re: How to restore the layout?

[martin rudalics]

 > I think it's an Emacs limitation that it doesn't really use the window
 > manager maximization. Which is strange, because it is available:
 >
 >   (w32-send-sys-command #xf030)
 >
 > et voilà. The problem being, I think, that we have no reliable way to
 > know wheter an Emacs frame is in that state (there's left and top
 > being -8, but that depends on UI settings).

It's part of the WINDOWPLACEMENT structure, IIUC.

 > I think at this point the only sensible thing to do is to recommend
 > people wanting to save & restore frames to use
 > toggle-frame-(maximized|fullscreen) instead of wm maximization. :-(

I think we can get it right.  In the worst case we have to send a
maximze request _after_ we're done with all other parts of window
restoration.

martin

Re: How to restore the layout?

[Juanma Barranquero]

On Fri, Jul 5, 2013 at 9:43 AM, martin rudalics <rudalics@gmx.at> wrote:

> `desktop-read' should.  But not `desktop-save', IMO.

If what you're saying is that desktop-save should not affect current
windows and frames, I agree.

Re: How to restore the layout?

[Juanma Barranquero]

On Fri, Jul 5, 2013 at 9:45 AM, martin rudalics <rudalics@gmx.at> wrote:

> It's part of the WINDOWPLACEMENT structure, IIUC.

I mean at lisp level. Obviously from C you can know the maximized
state of a frame, because the wm knows.

> I think we can get it right.  In the worst case we have to send a
> maximze request _after_ we're done with all other parts of window
> restoration.

That'd be great.

    J

Re: How to restore the layout?

[Angelo Graziosi]

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

Il 05/07/2013 9.45, martin rudalics ha scritto:
>  > I think it is the same I see here... It seems as a Windows window
>  > manager "effect"..
>
> I'm sure it's an Emacs "effect".

I guessed that from the fact that, apparently it happens only on Windows 
systems, not on Ubuntu or Kubuntu...


>
>  >> BTW, if you disable the tool bar before saving (adding (tool-bar-lines
>  >> . 0) to default-frame-alist, for example), do you see any difference?
>  >
>  > Yes, Emacs is restored "maximized", i.e. N lines, but the maximize
>  > button is not selected (and not tool bar, obviously)
>
> I think this clearly hints that the the toolbar is the culprit with
> respect to the size.  Now please try to (1) remove the size parameters
> from the desktop file, (2) check and tell us whether it contains a
> maximize request, and (3) try again with the thus modified desktop file.

I have removed the desktop file. Then I started Emacs, maximized the 
frame and closed Emacs after saved the desktop. The resulting desktop 
(test bzipped) is attached. Which parameters do you suggest to remove? I 
notice only a "fullscreen", but I have only clicked on the maximize 
button... May you resend it as you think?


TIA,
   Angelo.


[-- Attachment #2: desktop.test.bz2 --]
[-- Type: application/octet-stream, Size: 820 bytes --]

Re: How to restore the layout?

[martin rudalics]

 > I have removed the desktop file. Then I started Emacs, maximized the
 > frame and closed Emacs after saved the desktop. The resulting desktop
 > (test bzipped) is attached. Which parameters do you suggest to remove? I
 > notice only a "fullscreen", but I have only clicked on the maximize
 > button... May you resend it as you think?

The `fullscreen' parameter is nil.  This is a bug on Windows, so the
first step is to set the fullscreen parameter after a maximize request.
Am I right that on X this is done in x_handle_net_wm_state and on NS in
setFSValue?  IIUC on Windows this should be part of the SIZE_MAXIMIZED
case in w32_read_socket.  Or am I missing something?

Anyway, you could try changing (fullscreen) to (fullscreen . maximized)
and look what happens when you load the file then.

martin

Re: How to restore the layout?

[Jan Djärv]

Hi.

5 jul 2013 kl. 14:58 skrev martin rudalics <rudalics@gmx.at>:

> > I have removed the desktop file. Then I started Emacs, maximized the
> > frame and closed Emacs after saved the desktop. The resulting desktop
> > (test bzipped) is attached. Which parameters do you suggest to remove? I
> > notice only a "fullscreen", but I have only clicked on the maximize
> > button... May you resend it as you think?
> 
> The `fullscreen' parameter is nil.  This is a bug on Windows, so the
> first step is to set the fullscreen parameter after a maximize request.
> Am I right that on X this is done in x_handle_net_wm_state and on NS in
> setFSValue?  IIUC on Windows this should be part of the SIZE_MAXIMIZED
> case in w32_read_socket.  Or am I missing something?


That sounds about right.

	Jan D.

Re: How to restore the layout?

[Angelo Graziosi]

Il 05/07/2013 14.58, martin rudalics ha scritto:
>  > I have removed the desktop file. Then I started Emacs, maximized the
>  > frame and closed Emacs after saved the desktop. The resulting desktop
>  > (test bzipped) is attached. Which parameters do you suggest to remove? I
>  > notice only a "fullscreen", but I have only clicked on the maximize
>  > button... May you resend it as you think?
>
> The `fullscreen' parameter is nil.  This is a bug on Windows, so the
> first step is to set the fullscreen parameter after a maximize request.
> Am I right that on X this is done in x_handle_net_wm_state and on NS in
> setFSValue?  IIUC on Windows this should be part of the SIZE_MAXIMIZED
> case in w32_read_socket.  Or am I missing something?
>
> Anyway, you could try changing (fullscreen) to (fullscreen . maximized)
> and look what happens when you load the file then.

In that case, Emacs starts as after "M-x toggle-frame-fullscreen", i.e. 
with the Windows status bar (or Windows aplications bar, if you prefer) 
partially covering the bottom of Emacs frame and, obviously, with the 
maximize button *NOT* selected.

If I try (maximized), instead, Emacs starts with M columns and N-2 lines 
[*] and maximize button *NOT* selected.


Ciao,
Angelo.

---
[*] Assuming the Windows Desktop dimensions of M columns and N+2 lines 
(+2 for the status bar)

Re: How to restore the layout?

[Angelo Graziosi]

BTW, now I am noticing (I think not Cygwin specific) another issue 
regarding buffers restoration.

Suppose I am working with a foo.cpp buffer in HOME (~/foo.cpp). Suppose 
also I have visited another buffer ~/applications/foo.f90. Now I quit 
Emacs and delete the ~/foo.cpp file. When I restart Emacs, it restore 
both buffers: ~/applications/foo.f90 (and this is OK) and an EMPTY 
~/applications/foo.cpp!!! and foo.cpp is visited in Fundamental mode 
(notice the new directory for foo.cpp too..).

I think this is wrong. Until few week ago, Emacs restored only the 
existent files, i.e. ~/applications/foo.f90 (in the Messages buffer it 
wrote something like "...foo.cpp not found...". I think this is the 
right thing to do: files that do not exist any more (or are moved 
elsewhere) should not be restored at all.


Ciao,
  Angelo.

Re: How to restore the layout?

[martin rudalics]

 > In that case, Emacs starts as after "M-x toggle-frame-fullscreen", i.e.
 > with the Windows status bar (or Windows aplications bar, if you prefer)
 > partially covering the bottom of Emacs frame and, obviously, with the
 > maximize button *NOT* selected.

I'm completely lost now:

(1) What is the maximize button and how do I (de-)select it?  Here, I
     have three buttons on the top right corner of my frame and they are
     always either selected or invisible - the latter when in fullscreen
     mode (F11).

(2) With emacs -Q `toggle-frame-fullscreen' gets me a full screen frame,
     nothing covered and no buttons visible.

(3) `toggle-frame-maximized' (which I've just seen for the first time)
     gets me a maximized frame with decorations.  This looks nice but I
     never found another application here which does such a thing.  All
     (Firefox, Thunderbird) have the decorations (outer frame borders)
     turned off when I send them a maximize request and so does Emacs
     when I click its maximize button.

So disregarding (F11) fullscreen mode, we currently have two types of
maximized frames on Windows - one with outer borders and one without,
and apparently only the former has its frame parameter set.

Can someone please enlighten me here?

martin

Re: How to restore the layout?

[Juanma Barranquero]

On Fri, Jul 5, 2013 at 4:02 PM, Angelo Graziosi
<angelo.graziosi@alice.it> wrote:

> When I restart Emacs, it restore both buffers:
> ~/applications/foo.f90 (and this is OK) and an EMPTY
> ~/applications/foo.cpp!!! and foo.cpp is visited in Fundamental mode (notice
> the new directory for foo.cpp too..).

This only happens if you set desktop-restore-frames = t, which is
currently experimental.

> I think this is the right thing to
> do: files that do not exist any more (or are moved elsewhere) should not be
> restored at all.

It's not a file, it's a buffer. Note that buffer-file-name is nil.

That's a consequence of the way window-state-put currently works. Martin?

    J

Re: How to restore the layout?

[Angelo Graziosi]

Il 05/07/2013 16.55, Juanma Barranquero ha scritto:
> On Fri, Jul 5, 2013 at 4:02 PM, Angelo Graziosi
>  wrote:
>
>> When I restart Emacs, it restore both buffers:
>> ~/applications/foo.f90 (and this is OK) and an EMPTY
>> ~/applications/foo.cpp!!! and foo.cpp is visited in Fundamental mode (notice
>> the new directory for foo.cpp too..).
>
> This only happens if you set desktop-restore-frames = t, which is
> currently experimental.

Obviously I have that
>
>> I think this is the right thing to
>> do: files that do not exist any more (or are moved elsewhere) should not be
>> restored at all.
>
> It's not a file, it's a buffer. Note that buffer-file-name is nil.

OK, it is a buffer, but restoring what that doesn't exist any more is 
wrong, in my opinion


> That's a consequence of the way window-state-put currently works. Martin?

Yes, Martin.. please fix that...


Ciao,
  Angelo.

Re: How to restore the layout?

[Juanma Barranquero]

On Fri, Jul 5, 2013 at 5:02 PM, Angelo Graziosi
<angelo.graziosi@alice.it> wrote:

> Obviously I have that

Then please treat any problem you see as something to report, but not
yet as a bug, as behavior is likely to change :-)

> OK, it is a buffer, but restoring what that doesn't exist any more is wrong,
> in my opinion

Not only I agree, but a few days ago I commented as much. You're
talking about files, but the same happens for buffers that are not
saved/restored. Try M-x buffer-menu followed by saving and restoring.

> Yes, Martin.. please fix that...

No need to plead.

    J

Re: How to restore the layout?

[martin rudalics]

 > It's not a file, it's a buffer. Note that buffer-file-name is nil.
 >
 > That's a consequence of the way window-state-put currently works. Martin?

`window-state-put' doesn't know anything about files.  It simply expects
the window's buffer to be there.  But we can easily replace

	(set-window-buffer window (get-buffer-create (car state)))

by, for example,

	(set-window-buffer window (or (get-buffer (car state))
				      (get-buffer-create "*scratch*")))

If we saved and restored window-local buffer lists, we could show the
previous buffer on that window's list instead.

Two remarks: I never heard about `get-buffer-create' creating any files
or directories.  And, `window-state-put' reuses the name of the window's
buffer from the other session.  So if you have a buffer "foo" in the old
session and a completely different buffer "foo" in the new session, it
will show that other buffer instead.

martin

Re: How to restore the layout?

[Juanma Barranquero]

On Fri, Jul 5, 2013 at 5:21 PM, martin rudalics <rudalics@gmx.at> wrote:

> `window-state-put' doesn't know anything about files.  It simply expects
> the window's buffer to be there.

Of course.

>  But we can easily replace
>
>         (set-window-buffer window (get-buffer-create (car state)))
>
> by, for example,
>
>         (set-window-buffer window (or (get-buffer (car state))
>                                       (get-buffer-create "*scratch*")))
>
> If we saved and restored window-local buffer lists, we could show the
> previous buffer on that window's list instead.

That (restoring buffer lists) would be better, but still it is
possible that no previous buffer can be found, so creating *scratch*
or defaulting to something else will still be required.

> Two remarks: I never heard about `get-buffer-create' creating any files
> or directories.

I think Angelo was just a bit sloppy with his terminology.

> And, `window-state-put' reuses the name of the window's
> buffer from the other session.  So if you have a buffer "foo" in the old
> session and a completely different buffer "foo" in the new session, it
> will show that other buffer instead.

As it should. If the user plays such games, let her do it.

   J

Re: How to restore the layout?

[martin rudalics]

 > Not only I agree, but a few days ago I commented as much. You're
 > talking about files, but the same happens for buffers that are not
 > saved/restored. Try M-x buffer-menu followed by saving and restoring.

Finally I understand what you said then.  I'm not sure whether this
might be considered a feature as well.  It could remind you that at that
time you had some buffer open for selecting a buffer, reading help, the
shell ...  Maybe a better solution would be to show the *Messages*
buffer saying that the previous buffer doesn't exist any more.

martin

Re: How to restore the layout?

[Juanma Barranquero]

On Fri, Jul 5, 2013 at 5:30 PM, martin rudalics <rudalics@gmx.at> wrote:

> Finally I understand what you said then.

I need to work on my communication skills...

> I'm not sure whether this
> might be considered a feature as well.  It could remind you that at that
> time you had some buffer open for selecting a buffer, reading help, the
> shell ...

I don't consider it a feature. I very often have the IELM buffer open,
but it is usually temporary and the fact that it gets "saved" (the
correspondence window <-> buffer, I mean, as the buffer is not really
saved) is just by accident, because I do not bother to kill the IELM
buffer before exiting Emacs.

Previously, just adding "*ielm*" to dektop-buffers-not-to-save would
have sufficed, of course. Realizing the problem with window-state-put,
I though of adding a hook or a desktop-* customization option to
delete windows before saving, but that should distinguish between M-x
desktop-save and M-x save-buffers-kill-terminal, which is ugly. So
it's better to add some way either to show another buffer, as you
suggest, or delete the window after restoring it (that'd be my
preferred behavior, I think).

>  Maybe a better solution would be to show the *Messages*
> buffer saying that the previous buffer doesn't exist any more.

Well, if many buffers are left unrestored it could get a bit
confusing, because all messages will be shown in multiple windows. But
it is still better than what happens now.

   J

Re: How to restore the layout?

[martin rudalics]

 > That (restoring buffer lists) would be better, but still it is
 > possible that no previous buffer can be found, so creating *scratch*
 > or defaulting to something else will still be required.

How about replacing

     (set-window-buffer window (get-buffer-create (car state)))

by the (completely untested)

     (let ((buffer ((get-buffer (car state)))))
       (if buffer	
	  (set-window-buffer window buffer)
	(switch-to-prev-buffer window)))

martin

Re: How to restore the layout?

[Juanma Barranquero]

On Fri, Jul 5, 2013 at 5:39 PM, martin rudalics <rudalics@gmx.at> wrote:

> by the (completely untested)
>
>     (let ((buffer ((get-buffer (car state)))))
>       (if buffer
>           (set-window-buffer window buffer)
>         (switch-to-prev-buffer window)))

I think I'd be OK with that, but doesn't it need to save the buffer list?

  J

Re: How to restore the layout?

[martin rudalics]

 > ..., or delete the window after restoring it (that'd be my
 > preferred behavior, I think).

We could add a variable

(defvar window-state-put-stale-windows nil
     "Helper variable for `window-state-put'.")

use

     (let ((buffer ((get-buffer (car state)))))
       (if buffer	
	  (set-window-buffer window buffer)
	(switch-to-prev-buffer window)
	(setq window-state-put-stale-windows
	      (cons window window-state-put-stale-windows))))

as replacement and in `window-state-put' initially do

(setq window-state-put-stale-windows nil)

and before the final call to `window--check-frame' simply add a

(dolist (window window-state-put-stale-windows)
   (when (window-deletable-p window)
     (delete-window window)))

martin

Re: How to restore the layout?

[martin rudalics]

> I think I'd be OK with that, but doesn't it need to save the buffer list?

It should work without them.  If it doesn't, we've found a bug we have
to fix ;-)

martin

Re: How to restore the layout?

[Juanma Barranquero]

> We could add a variable
>
> (defvar window-state-put-stale-windows nil
>     "Helper variable for `window-state-put'.")
>
> use
>
>
>     (let ((buffer ((get-buffer (car state)))))
>       (if buffer
>           (set-window-buffer window buffer)
>         (switch-to-prev-buffer window)

Why? In case the window cannot be deleted?

>         (setq window-state-put-stale-windows
>               (cons window window-state-put-stale-windows))))

AKA (push window window-state-put-stale-windows)

> and before the final call to `window--check-frame' simply add a
>
> (dolist (window window-state-put-stale-windows)
>   (when (window-deletable-p window)
>     (delete-window window)))

(ignore-errors (delete-window window))

to protect only windows (i.e., when window-deletable-p returns `frame').

I like this.

    J

Re: How to restore the layout?

[martin rudalics]

 >>     (let ((buffer ((get-buffer (car state)))))
 >>       (if buffer
 >>           (set-window-buffer window buffer)
 >>         (switch-to-prev-buffer window)
 >
 > Why? In case the window cannot be deleted?

Yes.  IIRC this would otherwise show some temporary buffer instead.

 >>         (setq window-state-put-stale-windows
 >>               (cons window window-state-put-stale-windows))))
 >
 > AKA (push window window-state-put-stale-windows)

Better, yes.

 >> and before the final call to `window--check-frame' simply add a
 >>
 >> (dolist (window window-state-put-stale-windows)
 >>   (when (window-deletable-p window)
 >>     (delete-window window)))
 >
 > (ignore-errors (delete-window window))
 >
 > to protect only windows (i.e., when window-deletable-p returns `frame').

I forgot.  We could also delete the frame when `window-deletable-p'
returns 'frame.

 > I like this.

Please fix it up and install it.

martin

Re: How to restore the layout?

[Angelo Graziosi]

Il 05/07/2013 17.26, Juanma Barranquero ha scritto:
> On Fri, Jul 5, 2013 at 5:21 PM, martin rudalics <rudalics@gmx.at> wrote:
>
>> `window-state-put' doesn't know anything about files.  It simply expects
>> the window's buffer to be there.
>
> Of course.
>
>>   But we can easily replace
>>
>>          (set-window-buffer window (get-buffer-create (car state)))
>>
>> by, for example,
>>
>>          (set-window-buffer window (or (get-buffer (car state))
>>                                        (get-buffer-create "*scratch*")))
>>
>> If we saved and restored window-local buffer lists, we could show the
>> previous buffer on that window's list instead.
>
> That (restoring buffer lists) would be better, but still it is
> possible that no previous buffer can be found, so creating *scratch*
> or defaulting to something else will still be required.
>
>> Two remarks: I never heard about `get-buffer-create' creating any files
>> or directories.
>
> I think Angelo was just a bit sloppy with his terminology.

Obviously, in my example, the buffer "restored", ~/applications/foo.cpp 
doesn't exit on disk, it is a sort of "virtual" buffer.

Anyway, if I remove a *real* file ~/foo.cpp (because, for example, I 
don't need it any more), then restarting Emacs I cannot have a "virtual" 
buffer ~/applications/foo.cpp! I would expect that Emacs behaves as 
before the introduction of "desktop-restore-frames", i.e. a message in 
*Messages*, saying something like

  "... failure restoring  ~/foo.cpp because not found..."

This would be OK..

Ciao,
Angelo.

Re: How to restore the layout?

[Juanma Barranquero]

On Fri, Jul 5, 2013 at 7:03 PM, martin rudalics <rudalics@gmx.at> wrote:

> I forgot.  We could also delete the frame when `window-deletable-p'
> returns 'frame.

Hm, I'm not sure. It will flash a frame on screen and then delete it,
and frames are intrinsically more persistent (I mean, usually they
don't often get created temporally, except in some multi-frame
setups), while windows are mostly come-and-go.

> Please fix it up and install it.

OK.

   J

Re: How to restore the layout?

[Juanma Barranquero]

On Fri, Jul 5, 2013 at 7:04 PM, Angelo Graziosi
<angelo.graziosi@alice.it> wrote:

> Anyway, if I remove a *real* file ~/foo.cpp (because, for example, I don't
> need it any more), then restarting Emacs I cannot have a "virtual" buffer
> ~/applications/foo.cpp! I would expect that Emacs behaves as before the
> introduction of "desktop-restore-frames"

I thought it was already clear that:

1) desktop-restore-frames is not yet really "introduced"
2) both Martin and I agree that no buffer should be created in that
particular case.

>, i.e. a message in *Messages*, saying something like
>
>  "... failure restoring  ~/foo.cpp because not found..."

You already get a message that some buffers weren't reloaded.

   J

Re: How to restore the layout?

[martin rudalics]

 > Hm, I'm not sure. It will flash a frame on screen and then delete it,
 > and frames are intrinsically more persistent (I mean, usually they
 > don't often get created temporally, except in some multi-frame
 > setups), while windows are mostly come-and-go.

Then let's delete windows only.

martin

Re: How to restore the layout?

[Eli Zaretskii]

> Date: Fri, 05 Jul 2013 16:42:17 +0200
> From: martin rudalics <rudalics@gmx.at>
> Cc: Emacs developers <emacs-devel@gnu.org>
> 
> (1) What is the maximize button and how do I (de-)select it?

I guess the "maximize button" is the one which normally shows a single
rectangle, and, when the frame is maximized (i.e. the button is
"selected"), it shows two rectangles which partially overlap.

Re: How to restore the layout?

[Angelo Graziosi]

Il 05/07/2013 20.22, Eli Zaretskii ha scritto:
>> Date: Fri, 05 Jul 2013 16:42:17 +0200
>> From: martin rudalics <rudalics@gmx.at>
>> Cc: Emacs developers <emacs-devel@gnu.org>
>>
>> (1) What is the maximize button and how do I (de-)select it?
>
> I guess the "maximize button" is the one which normally shows a single
> rectangle, and, when the frame is maximized (i.e. the button is
> "selected"), it shows two rectangles which partially overlap.
>
Exactly!

Ciao,
  Angelo.

Re: How to restore the layout?

[martin rudalics]

 >>> (1) What is the maximize button and how do I (de-)select it?
 >>
 >> I guess the "maximize button" is the one which normally shows a single
 >> rectangle, and, when the frame is maximized (i.e. the button is
 >> "selected"), it shows two rectangles which partially overlap.
 >>
 > Exactly!

... and how do you (de-)select it?  The only way I can do that here is
by clicking that button, neither M-f10 nor f11 do it.  And when I click
that button and "the frame is maximized/its maximize button is
selected", my fullscreen frame parameter is nil.  Unless we fix that (on
Windows only, I presume), we can't expect desktop or the window-state
functions to save and restore it.

martin

Re: How to restore the layout?

[Angelo Graziosi]

Il 06/07/2013 10.47, martin rudalics ha scritto:
>  >>> (1) What is the maximize button and how do I (de-)select it?
>  >>
>  >> I guess the "maximize button" is the one which normally shows a single
>  >> rectangle, and, when the frame is maximized (i.e. the button is
>  >> "selected"), it shows two rectangles which partially overlap.
>  >>
>  > Exactly!
>
> ... and how do you (de-)select it?  The only way I can do that here is
> by clicking that button, neither M-f10 nor f11 do it.  And when I click

Yes, one should reclick it... and f11 (two times) puts Emacs in 
fullscreen but the maximize button is not selected (it shows only one 
rectangle/box). M-f10 does not seem to work rightly..

  Angelo

> that button and "the frame is maximized/its maximize button is
> selected", my fullscreen frame parameter is nil.  Unless we fix that (on
> Windows only, I presume), we can't expect desktop or the window-state
> functions to save and restore it.
>
> martin

Re: How to restore the layout?

[Juanma Barranquero]

On Sat, Jul 6, 2013 at 10:47 AM, martin rudalics <rudalics@gmx.at> wrote:

> ... and how do you (de-)select it?  The only way I can do that here is
> by clicking that button, neither M-f10 nor f11 do it.

Programmatically, with w32-send-sys-command.

   J

Re: How to restore the layout?

[martin rudalics]

 > Yes, one should reclick it... and f11 (two times) puts Emacs in
 > fullscreen but the maximize button is not selected (it shows only one
 > rectangle/box).

I'm still not getting it.  Here hitting f11 one time on a non-fullscreen
frame makes my Emacs frame fullscreen and I don't see neither a title
bar nor a maximize button.  Hitting f11 again now gets me a normal-sized
frame with the maximize button disabled.

 > M-f10 does not seem to work rightly..

In what sense?

martin

Re: How to restore the layout?

[martin rudalics]

 > Programmatically, with w32-send-sys-command.

OK.  If in w32term.c I simply replace this chunk

		case SIZE_MAXIMIZED:
		case SIZE_RESTORED:
		  {
		    bool iconified = FRAME_ICONIFIED_P (f);

		    SET_FRAME_VISIBLE (f, 1);
		    SET_FRAME_ICONIFIED (f, 0);

		    /* wait_reading_process_output will notice this
		       and update the frame's display structures.  */
		    SET_FRAME_GARBAGED (f);

		    if (iconified)
		      {
			int x, y;

			/* Reset top and left positions of the Window
			   here since Windows sends a WM_MOVE message
			   BEFORE telling us the Window is minimized
			   when the Window is iconified, with 3000,3000
			   as the co-ords. */
			x_real_positions (f, &x, &y);
			f->left_pos = x;
			f->top_pos = y;

			inev.kind = DEICONIFY_EVENT;
			XSETFRAME (inev.frame_or_window, f);
		      }
		    else if (! NILP (Vframe_list)
			     && ! NILP (XCDR (Vframe_list)))
		      /* Force a redisplay sooner or later
			 to update the frame titles
			 in case this is the second frame.  */
		      record_asynch_buffer_change ();
		  }
		  break;

with

		case SIZE_MAXIMIZED:
		  {
		    bool iconified = FRAME_ICONIFIED_P (f);

		    SET_FRAME_VISIBLE (f, 1);
		    SET_FRAME_ICONIFIED (f, 0);

		    /* wait_reading_process_output will notice this
		       and update the frame's display structures.  */
		    SET_FRAME_GARBAGED (f);

		    if (iconified)
		      {
			int x, y;

			/* Reset top and left positions of the Window
			   here since Windows sends a WM_MOVE message
			   BEFORE telling us the Window is minimized
			   when the Window is iconified, with 3000,3000
			   as the co-ords. */
			x_real_positions (f, &x, &y);
			f->left_pos = x;
			f->top_pos = y;

			inev.kind = DEICONIFY_EVENT;
			XSETFRAME (inev.frame_or_window, f);
		      }
		    else if (! NILP (Vframe_list)
			     && ! NILP (XCDR (Vframe_list)))
		      /* Force a redisplay sooner or later
			 to update the frame titles
			 in case this is the second frame.  */
		      record_asynch_buffer_change ();
		  }

		  store_frame_param (f, Qfullscreen, Qmaximized);
		  break;

		case SIZE_RESTORED:
		  {
		    bool iconified = FRAME_ICONIFIED_P (f);

		    SET_FRAME_VISIBLE (f, 1);
		    SET_FRAME_ICONIFIED (f, 0);

		    /* wait_reading_process_output will notice this
		       and update the frame's display structures.  */
		    SET_FRAME_GARBAGED (f);

		    if (iconified)
		      {
			int x, y;

			/* Reset top and left positions of the Window
			   here since Windows sends a WM_MOVE message
			   BEFORE telling us the Window is minimized
			   when the Window is iconified, with 3000,3000
			   as the co-ords. */
			x_real_positions (f, &x, &y);
			f->left_pos = x;
			f->top_pos = y;

			inev.kind = DEICONIFY_EVENT;
			XSETFRAME (inev.frame_or_window, f);
		      }
		    else if (! NILP (Vframe_list)
			     && ! NILP (XCDR (Vframe_list)))
		      /* Force a redisplay sooner or later
			 to update the frame titles
			 in case this is the second frame.  */
		      record_asynch_buffer_change ();
		  }

		  store_frame_param (f, Qfullscreen, Qnil);
		  break;

the fullscreen parameter gets set to 'maximized.  Then we could try to
restore the state in `desktop-read' via `w32-send-sys-command'.  But
obviously that function should be then also called when changing the
fullscreen frame parameter ...

martin

Re: How to restore the layout?

[Angelo Graziosi]

Il 06/07/2013 12.44, martin rudalics ha scritto:
>  > Yes, one should reclick it... and f11 (two times) puts Emacs in
>  > fullscreen but the maximize button is not selected (it shows only one
>  > rectangle/box).
>
> I'm still not getting it.  Here hitting f11 one time on a non-fullscreen
> frame makes my Emacs frame fullscreen and I don't see neither a title
> bar nor a maximize button.  Hitting f11 again now gets me a normal-sized
> frame with the maximize button disabled.

Hmm.. here (Cygwin on XP) "M-x toggle-frame-fullscreen" say to hit f11 
two times and indeed it puts Emacs in full screen only after hitting f11 
two times. I can see the title and the maximize button not selected, 
only the bottom of the frame si covered by Windows status bar. Hitting 
f11 again does nothing...


>
>  > M-f10 does not seem to work rightly..
>
> In what sense?

After I click the maximize button M-f10 works as f11 described above. If 
the maximize button is not selected, M-f10 does nothing..

Ciao,
Angelo.

Re: How to restore the layout?

[martin rudalics]

 > Hmm.. here (Cygwin on XP) "M-x toggle-frame-fullscreen" say to hit f11

Where and how does it say that?

 > two times and indeed it puts Emacs in full screen only after hitting f11
 > two times. I can see the title and the maximize button not selected,
 > only the bottom of the frame si covered by Windows status bar.

Does anyone else see the title and the maximize button after f11?

 > Hitting
 > f11 again does nothing...

Which would contradict the idea of toggling.

 >>  > M-f10 does not seem to work rightly..
 >>
 >> In what sense?
 >
 > After I click the maximize button M-f10 works as f11 described above. If
 > the maximize button is not selected, M-f10 does nothing..

This is contrived.  What I see with emacs -Q, i386-mingw-nt5.1.2600
build on Windows XP, is:

(1) Hitting f11 makes the frame fullscreen, no title bar or maximize
     button visible.  Hitting f11 again restores the previous appearance.

(2) If I maximize my frame by clicking on the maximize button, hitting
     f11 makes my frame fullscreen as before but hitting f11 again
     restores its previous size and not the maximized one.

(3) Hitting M-f10 makes my frame appear maximized with title and
     decorations visible and the maximize button enabled.  Hitting M-f10
     again restores the previous appearance.

(4) Maximizing the frame by clicking on the maximize button and then
     hitting M-f10 does nothing.

martin

Re: How to restore the layout?

[Eli Zaretskii]

> Date: Sat, 06 Jul 2013 15:06:31 +0200
> From: martin rudalics <rudalics@gmx.at>
> Cc: Eli Zaretskii <eliz@gnu.org>, emacs-devel@gnu.org
> 
>  > two times and indeed it puts Emacs in full screen only after hitting f11
>  > two times. I can see the title and the maximize button not selected,
>  > only the bottom of the frame si covered by Windows status bar.
> 
> Does anyone else see the title and the maximize button after f11?

I don't.  But don't you compare apples with oranges?  Angelo is
running a Cygwin Emacs, which uses X, so its behavior is not to be
compared with the native w32 Emacs.

>  > Hitting
>  > f11 again does nothing...
> 
> Which would contradict the idea of toggling.

Who knows what f11 does in the Cygwin-ported Xlib?

>  >>  > M-f10 does not seem to work rightly..
>  >>
>  >> In what sense?
>  >
>  > After I click the maximize button M-f10 works as f11 described above. If
>  > the maximize button is not selected, M-f10 does nothing..
> 
> This is contrived.  What I see with emacs -Q, i386-mingw-nt5.1.2600
> build on Windows XP, is:
> 
> (1) Hitting f11 makes the frame fullscreen, no title bar or maximize
>      button visible.  Hitting f11 again restores the previous appearance.
> 
> (2) If I maximize my frame by clicking on the maximize button, hitting
>      f11 makes my frame fullscreen as before but hitting f11 again
>      restores its previous size and not the maximized one.
> 
> (3) Hitting M-f10 makes my frame appear maximized with title and
>      decorations visible and the maximize button enabled.  Hitting M-f10
>      again restores the previous appearance.
> 
> (4) Maximizing the frame by clicking on the maximize button and then
>      hitting M-f10 does nothing.

You are using a completely different build, I think, than what Angelo
uses.

Re: How to restore the layout?

[martin rudalics]

 >> Does anyone else see the title and the maximize button after f11?
 >
 > I don't.  But don't you compare apples with oranges?  Angelo is
 > running a Cygwin Emacs, which uses X, so its behavior is not to be
 > compared with the native w32 Emacs.

I thought fullscreen is a term with broader semantics than those
provided by X or Windows.

 >>  > Hitting
 >>  > f11 again does nothing...
 >>
 >> Which would contradict the idea of toggling.
 >
 > Who knows what f11 does in the Cygwin-ported Xlib?

M-x toggle-frame-fullscreen as well?

 > You are using a completely different build, I think, than what Angelo
 > uses.

Obviously.  But when results can differ that much, it hardly makes sense
to change anything in this area.

martin

Re: How to restore the layout?

[Eli Zaretskii]

> Date: Sat, 06 Jul 2013 15:43:57 +0200
> From: martin rudalics <rudalics@gmx.at>
> CC: angelo.graziosi@alice.it, emacs-devel@gnu.org
> 
>  >> Does anyone else see the title and the maximize button after f11?
>  >
>  > I don't.  But don't you compare apples with oranges?  Angelo is
>  > running a Cygwin Emacs, which uses X, so its behavior is not to be
>  > compared with the native w32 Emacs.
> 
> I thought fullscreen is a term with broader semantics than those
> provided by X or Windows.

Semantics, yes.  Implementation details, I doubt it.

>  > You are using a completely different build, I think, than what Angelo
>  > uses.
> 
> Obviously.  But when results can differ that much, it hardly makes sense
> to change anything in this area.

You need to talk to someone who understands how fullscreen works in
the Cygwin X build, and specifically what F11 does in that case.

Re: How to restore the layout?

[Angelo Graziosi]

Il 06/07/2013 15.06, martin rudalics ha scritto:
>  > Hmm.. here (Cygwin on XP) "M-x toggle-frame-fullscreen" say to hit f11
>
> Where and how does it say that?

In the minibuffer and in *Messages* buffer.


I am speaking about the Cygwin GTK build of Emacs... I have also a 
Windows native build installed (end May trunk binaries from a link of 
Emacswiki) and there the f11 works as you have described!

Perhaps, at this stage, we can left aside these issues with f11 an M-f10 
on Cygwin. After all, the frame on Cygwin is restored quite well: M 
columns in width and N-2 lines in height [*]. Clicking the maximize 
button gains another line.

Ciao,
Angelo.


---
[*] The Windows desktop is M columns X N+2 lines (+2 for the status 
bar). Ideally we want N lines for Emacs when maximized.

Re: How to restore the layout?

[Juanma Barranquero]

On Fri, Jul 5, 2013 at 7:03 PM, martin rudalics <rudalics@gmx.at> wrote:

> Please fix it up and install it.

Done.

I've tweaked a bit the final loop to pop windows from the variable to
allow them to be garbage-collected.

   J

Re: How to restore the layout?

[Juanma Barranquero]

On Sat, Jul 6, 2013 at 12:44 PM, martin rudalics <rudalics@gmx.at> wrote:

> Then we could try to
> restore the state in `desktop-read' via `w32-send-sys-command'.  But
> obviously that function should be then also called when changing the
> fullscreen frame parameter ...

When changing it, and also when creating a new frame, if passed a
parameter 'fullscreen.

   J

RE: How to restore the layout?

[Drew Adams]

> This is contrived.  What I see with emacs -Q, i386-mingw-nt5.1.2600
> build on Windows XP, is:
> 
> (1) Hitting f11 makes the frame fullscreen, no title bar or maximize
>      button visible.  Hitting f11 again restores the previous appearance.
> 
> (2) If I maximize my frame by clicking on the maximize button, hitting
>      f11 makes my frame fullscreen as before but hitting f11 again
>      restores its previous size and not the maximized one.
> 
> (3) Hitting M-f10 makes my frame appear maximized with title and
>      decorations visible and the maximize button enabled.  Hitting M-f10
>      again restores the previous appearance.
> 
> (4) Maximizing the frame by clicking on the maximize button and then
>      hitting M-f10 does nothing.

I see the same thing, except for this part of #3: "and the maximize
button enabled".  For me, M-10 has does not change the state of the
maximize button.

And in fact, if I click the button, so that the frame is maximized and
the button changes to the selected state (overlapping frames icon),
M-f10 then leaves the icon the same and the frame maximized.  A second
M-f10 at that point restores (demaximizes) the frame but leaves the
icon showing that it is maximized.  At that point, clicking the button
has no effect except to change the icon to deselected (single frame icon).

In sum, it seems that Emacs does not update the icon.  Other than that,
I see what Martin reported.

Re: How to restore the layout?

[martin rudalics]

 > You need to talk to someone who understands how fullscreen works in
 > the Cygwin X build, and specifically what F11 does in that case.

It's about modifying the fullscreen parameter in the first place.  The
F11 behavior is only secondary.

martin

Re: How to restore the layout?

[martin rudalics]

> I've tweaked a bit the final loop to pop windows from the variable to
> allow them to be garbage-collected.

Fine.  Thank you.

martin

Re: How to restore the layout?

[martin rudalics]

 >> (3) Hitting M-f10 makes my frame appear maximized with title and
 >>      decorations visible and the maximize button enabled.  Hitting M-f10
 >>      again restores the previous appearance.
[...]
 > I see the same thing, except for this part of #3: "and the maximize
 > button enabled".  For me, M-10 has does not change the state of the
 > maximize button.

That's what I meant.  In a normal frame the maximize button is enabled.
Hit M-f10 and the maximize button is still enabled.

 > And in fact, if I click the button, so that the frame is maximized and
 > the button changes to the selected state (overlapping frames icon),
 > M-f10 then leaves the icon the same and the frame maximized.  A second
 > M-f10 at that point restores (demaximizes) the frame but leaves the
 > icon showing that it is maximized.  At that point, clicking the button
 > has no effect except to change the icon to deselected (single frame icon).

This happens because M-f10 and hitting the button are unaware of each
other.  M-f10 tries to emulate maximization by making the frame cover
the entire workarea.  Clicking the maximize button does more or less the
same but (1) also drops the outer frame borders and (2) enables the
restore size button.

martin

Re: How to restore the layout?

[Juanma Barranquero]

On Sun, Jul 7, 2013 at 12:57 PM, martin rudalics <rudalics@gmx.at> wrote:

> the entire workarea.  Clicking the maximize button does more or less the
> same but (1) also drops the outer frame borders

I don't think it "drops" them, it just resizes and repositions the
frame so they are outside the screen.

    J

Re: How to restore the layout?

[martin rudalics]

 > I don't think it "drops" them, it just resizes and repositions the
 > frame so they are outside the screen.

Judging from what GetWindowRect returns you're right.  In this case the
lower border would disappear under the taskbar so the appearance relies
on the order in which windows are drawn.  OTOH GetWindowRect could lie
to us by adding the border sizes to the bounding rectangle.  We won't be
able to tell the difference.

martin

RE: How to restore the layout?

[Drew Adams]

>  > I don't think it "drops" them, it just resizes and repositions the
>  > frame so they are outside the screen.
> 
> Judging from what GetWindowRect returns you're right.  In this case the
> lower border would disappear under the taskbar so the appearance relies
> on the order in which windows are drawn.  OTOH GetWindowRect could lie
> to us by adding the border sizes to the bounding rectangle.  We won't be
> able to tell the difference.

Interesting.  I hadn't played with f11 before.  FWIW (curiosity only,
probably):

Using my frame-movement commands I see something different: I can move
the maximized frame around normally, and thus can see that the frame
borders, including the title bar, have indeed been dropped (there are
none).

I can also resize the maximized frame (again, using frame-cmds.el
commands) horizontally any amount.  But I can shrink it vertically only
one line, for some reason.

I also did not realize that the same holds for a frame maximized by
clicking the Windows maximize icon/button in the title bar: I can move
it around and resize it.  And in this case, unlike the case after
maximizing with f11, there is no limit to shrinking vertically.

Re: How to restore the layout?

[Juanma Barranquero]

[Sorry, I've been busy and didn't test your code until now]

On Tue, Jul 2, 2013 at 12:38 PM, martin rudalics <rudalics@gmx.at> wrote:

> A first, untested stab is below: Frames get a desktop-mini parameter
> which is a cons.  The car is t if the frame has a minibuffer and nil if
> not.

But:

>          ;; Do nothing if we are our own minibuffer frame.
>          ((eq minibuffer-frame frame))

In fact, it is possible to do

  emacs -Q --eval "(make-frame `((minibuffer . ,(minibuffer-window))))"

and have the second frame to use the first one's minibuffer, so even
frames that arew their own minibuffer frames should be saved as
(desktop-mini t . NUMBER), shouldn't they?

   J

Re: How to restore the layout?

[martin rudalics]

 >>          ;; Do nothing if we are our own minibuffer frame.
 >>          ((eq minibuffer-frame frame))
 >
 > In fact, it is possible to do
 >
 >   emacs -Q --eval "(make-frame `((minibuffer . ,(minibuffer-window))))"
 >
 > and have the second frame to use the first one's minibuffer, so even
 > frames that arew their own minibuffer frames should be saved as
 > (desktop-mini t . NUMBER), shouldn't they?

The first frame does have a minibuffer window and no minibuffer
parameter.  IIUC such a frame always uses its own minibuffer window, so
I don't store anything.  And the second frame should by handled by this
condition:

	 ((and (setq minibuffer-window
		     (frame-parameter frame 'minibuffer-window))
	       (window-minibuffer-p minibuffer-window))

Or am I missing something?

martin

Re: How to restore the layout?

[martin rudalics]

 > Interesting.  I hadn't played with f11 before.  FWIW (curiosity only,
 > probably):
 >
 > Using my frame-movement commands I see something different: I can move
 > the maximized frame

F11 should make the frame fullscreen, not maximized.

 > around normally, and thus can see that the frame
 > borders, including the title bar, have indeed been dropped (there are
 > none).

Here I can't move such frames using the mouse.  IIUC mouse-dragging is
suppressed (by Windows) for maximized frames.  Fullscreen frames don't
have borders/title bars so they can't be dragged for obvious resons.

 > I can also resize the maximized frame (again, using frame-cmds.el
 > commands) horizontally any amount.  But I can shrink it vertically only
 > one line, for some reason.
 >
 > I also did not realize that the same holds for a frame maximized by
 > clicking the Windows maximize icon/button in the title bar: I can move
 > it around and resize it.  And in this case, unlike the case after
 > maximizing with f11, there is no limit to shrinking vertically.

Programmatically you should be able to move any frame.  It will become
demaximized/defullscreenified in the course, I presume.

martin

Re: How to restore the layout?

[Juanma Barranquero]

On Mon, Jul 8, 2013 at 8:47 AM, martin rudalics <rudalics@gmx.at> wrote:

> Or am I missing something?

No, *I* was missing this:

            (unless this-count
              ;; Make desktop-mini entry for minibuffer frame.
              (setq count (1+ count) this-count count)
              (set-frame-parameter
               minibuffer-frame 'desktop-mini (cons t count)))

I blame it on the late hour and sleep deprivation. Sorry for the noise.

   J

RE: How to restore the layout?

[Drew Adams]

>  > Interesting.  I hadn't played with f11 before.  FWIW (curiosity only,
>  > probably): Using my frame-movement commands I see something different:
>  > I can move the maximized frame
> 
> F11 should make the frame fullscreen, not maximized.

OK, but isn't one difference that fullscreen does not include borders
(including title bar)?  That is what I see here: no borders.  I thought
that fullscreen might also mean that, like maximized, you cannot move the
frame (it is "pinned" to the screen).

Is this the behavior to be expected, that you can move a fullscreen frame
around and resize it (so it is, in effect, no longer "full screen"?  To be
clear, I don't care, a priori, either way; I'm just reporting what I see,
in case it helps.

>  > around normally, and thus can see that the frame
>  > borders, including the title bar, have indeed been dropped (there are
>  > none).
> 
> Here I can't move such frames using the mouse.  IIUC mouse-dragging is
> suppressed (by Windows) for maximized frames.  Fullscreen frames don't
> have borders/title bars so they can't be dragged for obvious resons.

OK.  I wasn't mentioning the mouse, but that's good to know, I guess.

>  > I can also resize the maximized frame (again, using frame-cmds.el
>  > commands) horizontally any amount.  But I can shrink it vertically only
>  > one line, for some reason.
>  >
>  > I also did not realize that the same holds for a frame maximized by
>  > clicking the Windows maximize icon/button in the title bar: I can move
>  > it around and resize it.  And in this case, unlike the case after
>  > maximizing with f11, there is no limit to shrinking vertically.
> 
> Programmatically you should be able to move any frame.  It will become
> demaximized/defullscreenified in the course, I presume.

Whatever that last sentence might mean (in terms of effect; the English
is clear).  The frame still has the same "full-screen" appearance (e.g.,
no borders); it simply is not "full screen" (in a naive sense).

Note, BTW, that with MS Windows you cannot move or resize a maximized window.
Dunno about "programmatically", but you cannot do so using the "System Menu",
which is the way Windows users recuperate a stray window.  Menu items such
as `Move' are disabled for a maximized frame.

Re: How to restore the layout?

[Juanma Barranquero]

On Tue, Jul 2, 2013 at 12:38 PM, martin rudalics <rudalics@gmx.at> wrote:

> In that case we'd have to delete the initial frame :-(

There are some cases where we need to delete the initial frame, so
that shouldn't be a problem.

I'm now writing the restore function and also fixing the parameter
filtering. I hope to install some changes tonight.

A couple of comments about your function:

       (let ((minibuffer-frame (window-frame (minibuffer-window frame))))
         (cond
          ;; Process minibuffer-window frame parameter if present.
          ((and (setq minibuffer-window
                      (frame-parameter frame 'minibuffer-window))
                (window-minibuffer-p minibuffer-window))

There's no frame parameter minibuffer-window. I have changed that to

      (let ((minibuffer-frame (window-frame (minibuffer-window frame)))
            (minibuffer-window (frame-parameter frame 'minibuffer)))
        (cond
         ((and (windowp minibuffer-window)
               (window-minibuffer-p minibuffer-window))
          (setq minibuffer-frame (window-frame minibuffer-window))

Also,

>           (let ((default (eq minibuffer-frame default-minibuffer-frame))
>                 (this-count
>                  (cdr (frame-parameter minibuffer-frame 'desktop-mini))))

AFAICS, default is not used anywhere.

   J

Re: How to restore the layout?

[martin rudalics]

 > OK, but isn't one difference that fullscreen does not include borders
 > (including title bar)?  That is what I see here: no borders.

If you maximize another application on your system, do you see any
borders?  I don't here.

 > I thought
 > that fullscreen might also mean that, like maximized, you cannot move the
 > frame (it is "pinned" to the screen).

Yes.  But sending the window manager an explicit resizing request
lifts that restriction, IIUC.

 > Is this the behavior to be expected, that you can move a fullscreen frame
 > around and resize it (so it is, in effect, no longer "full screen"?  To be
 > clear, I don't care, a priori, either way; I'm just reporting what I see,
 > in case it helps.

It depends on how you move and resize it.

 >> Programmatically you should be able to move any frame.  It will become
 >> demaximized/defullscreenified in the course, I presume.
 >
 > Whatever that last sentence might mean (in terms of effect; the English
 > is clear).  The frame still has the same "full-screen" appearance (e.g.,
 > no borders); it simply is not "full screen" (in a naive sense).

I have to admit that such behavior sounds strange.  Does it have a title
bar though?

 > Note, BTW, that with MS Windows you cannot move or resize a maximized window.
 > Dunno about "programmatically", but you cannot do so using the "System Menu",
 > which is the way Windows users recuperate a stray window.  Menu items such
 > as `Move' are disabled for a maximized frame.

I suppose the same rules hold for the system menu and mouse-dragging.
So if you can move or resize a maximized/fullscreen frame via the system
menu, the OS is not aware that your frame is maximized/fullscreen.

martin

Re: How to restore the layout?

[martin rudalics]

 > There's no frame parameter minibuffer-window. I have changed that to

Sorry.  The nomenclature is very confusing.

 > Also,
 >
 >>           (let ((default (eq minibuffer-frame default-minibuffer-frame))
 >>                 (this-count
 >>                  (cdr (frame-parameter minibuffer-frame 'desktop-mini))))
 >
 > AFAICS, default is not used anywhere.

OK.

martin

RE: How to restore the layout?

[Drew Adams]

>  > OK, but isn't one difference that fullscreen does not include borders
>  > (including title bar)?  That is what I see here: no borders.
> 
> If you maximize another application on your system, do you see any
> borders?  I don't here.

On MS Windows, clicking the maximize button in the title bar (or maximizing
in some other way) makes the window take up the full screen space, but still
with its borders, including the title bar.  Maximize and "fullscreen" are not
the same thing, AFAIK.

>  > I thought that fullscreen might also mean that, like maximized, you cannot
>  > move the frame (it is "pinned" to the screen).
> 
> Yes.  But sending the window manager an explicit resizing request
> lifts that restriction, IIUC.

How would I/you check that outside of Emacs, with MS Windows?

>  > Is this the behavior to be expected, that you can move a fullscreen frame
>  > around and resize it (so it is, in effect, no longer "full screen"?  To
>  > be clear, I don't care, a priori, either way; I'm just reporting what I see,
>  > in case it helps.
> 
> It depends on how you move and resize it.

How so?  Please elaborate.  What is the design - the "behavior to be expected"
in the different cases of how you move/resize?

>  >> Programmatically you should be able to move any frame.  It will become
>  >> demaximized/defullscreenified in the course, I presume.
>  >
>  > Whatever that last sentence might mean (in terms of effect; the English
>  > is clear).  The frame still has the same "full-screen" appearance (e.g.,
>  > no borders); it simply is not "full screen" (in a naive sense).
> 
> I have to admit that such behavior sounds strange.  Does it have a title
> bar though?

No.  By "no borders" I meant the title bar too - no title bar.

I'm sure that someone else on Windows can confirm what I'm seeing and perhaps
describe it differently.  If you want to try, one way is to use frame-cmds.el.

>  > Note, BTW, that with MS Windows you cannot move or resize a maximized
>  > window.  Dunno about "programmatically", but you cannot do so using the
>  > "System Menu", which is the way Windows users recuperate a stray window.
>  > Menu items such as `Move' are disabled for a maximized frame.
> 
> I suppose the same rules hold for the system menu and mouse-dragging.
> So if you can move or resize a maximized/fullscreen frame via the system
> menu, the OS is not aware that your frame is maximized/fullscreen.

Dunno.  Not sure I follow.  As I said, you cannot get to the Move or resizing
items of the system menu for a maximized window.  The fact that you can move
or resize a "maximized" Emacs frame suggests that the Emacs "maximize" is
not quite the same thing as Windows maximize.

Re: How to restore the layout?

[martin rudalics]

 >> If you maximize another application on your system, do you see any
 >> borders?  I don't here.
 >
 > On MS Windows, clicking the maximize button in the title bar (or maximizing
 > in some other way) makes the window take up the full screen space, but still
 > with its borders, including the title bar.  Maximize and "fullscreen" are not
 > the same thing, AFAIK.

When I start an application like the Windows Explorer I see, above the
title bar, the upper border of its window.  When I maximize the
Explorer's window, I still see the title bar, but the upper border has
disappeared.  When I make the Explorer window fullscreen (via F11) title
bar and upper border both disappear.

 >> Yes.  But sending the window manager an explicit resizing request
 >> lifts that restriction, IIUC.
 >
 > How would I/you check that outside of Emacs, with MS Windows?

No idea.  But with Emacs I can maximize a frame and do

(set-frame-position (selected-frame) 12 12)

to move it, keeping its previous size, while

(set-frame-position (selected-frame) 0 0)

will move it just for a short moment and back to the previous state
afterwards.  In any case, I can clearly see that the frame keeps its
outer borders, confirming an earlier claim of Juanma.

 >>  > Is this the behavior to be expected, that you can move a fullscreen frame
 >>  > around and resize it (so it is, in effect, no longer "full screen"?  To
 >>  > be clear, I don't care, a priori, either way; I'm just reporting what I see,
 >>  > in case it helps.
 >>
 >> It depends on how you move and resize it.
 >
 > How so?  Please elaborate.  What is the design - the "behavior to be expected"
 > in the different cases of how you move/resize?

I can't elaborate because I don't know what you tried to do when you
reported what you saw.  Here I cannot move a maximized Emacse frame by
dragging the mouse or via the System Menu.  I can move it by evaluating

(set-frame-position (selected-frame) 12 12)

or resize it by doing

(set-frame-height (selected-frame) (1- (frame-height)))

though and there's still a button enabled telling me that I can "restore
its size" so Windows still thinks that the Emacs window is maximized.
There's one funny discrepancy: I can't mouse-drag the moved window but
can drag the resized one.

 > As I said, you cannot get to the Move or resizing
 > items of the system menu for a maximized window.  The fact that you can move
 > or resize a "maximized" Emacs frame suggests that the Emacs "maximize" is
 > not quite the same thing as Windows maximize.

Not necessarily.  I unfortunately lost my Emacs trunk version and am not
sure whether and when I'm able to recuperate it, but IIRC I had lots
of incoherent states after doing M-F10.  But, maximizing Emacs via the
button in the upper right corner (I never use that but call WinMaximize
via a key combination instead) always works as expected.

martin

RE: How to restore the layout?

[Drew Adams]

>  >> If you maximize another application on your system, do you see any
>  >> borders?  I don't here.
>  >
>  > On MS Windows, clicking the maximize button in the title bar (or
>  > maximizing in some other way) makes the window take up the full screen
>  > space, but still with its borders, including the title bar.  Maximize
>  > and "fullscreen" are not the same thing, AFAIK.
> 
> When I start an application like the Windows Explorer I see, above the
> title bar, the upper border of its window.

Yes, OK, there is a border above the title bar, of the same width as the
other borders (only a few pixels, in my case) and indistinguishable from
the title bar in color etc.  I considered the two together.

> When I maximize the Explorer's window, I still see the title bar, but
> the upper border has disappeared.  When I make the Explorer window
> fullscreen (via F11) title bar and upper border both disappear.

Yes, same here.  I kept mentioning the title bar explicitly.  That was
the point: the title bar, not the tiny border around it.  Maximize
continues to show the title bar, and the window is "pinned" to the screen.

The system menu options for moving or resizing the window are disabled.
Moving and resizing are not disabled for a "maximized" Emacs frame.
(I don't have a problem with that.  Just mentioning the difference.)

>  >>  > Is this the behavior to be expected, that you can move a
>  >>  > fullscreen frame around and resize it (so it is, in effect, no
>  >>  > longer "full screen"?  To be clear, I don't care, a priori,
>  >>  > either way; I'm just reporting what I see, in case it helps.
>  >>
>  >> It depends on how you move and resize it.
>  >
>  > How so?  Please elaborate.  What is the design - the "behavior to be
>  > expected" in the different cases of how you move/resize?
> 
> I can't elaborate because I don't know what you tried to do when you
> reported what you saw.  Here I cannot move a maximized Emacse frame by
> dragging the mouse or via the System Menu.  I can move it by evaluating
> ...

Fullscreen, not maximized (in that paragraph).  I explained clearly what
I did.  I pointed to the code that I used (to move & resize).  The code
uses things like `modify-frame-parameters'.

Anyway, I repeat that I really don't care.  I was just asking what the
design was: what you intended the behavior to be.  It is fine with me
that it might not correspond to Windows maximize/restore/fullscreen in
all respects.

> though and there's still a button enabled telling me that I can "restore
> its size" so Windows still thinks that the Emacs window is maximized.

Yes, we've been through that.  Again, you're talking about maximized, not
fullscreen - there is no maximize/restore button for a fullscreen frame.

> There's one funny discrepancy: I can't mouse-drag the moved window but
> can drag the resized one.

One more, you mean.

>  > As I said, you cannot get to the Move or resizing items of the system
>  > menu for a maximized window.  The fact that you can move or resize a
>  > "maximized" Emacs frame suggests that the Emacs "maximize" is
>  > not quite the same thing as Windows maximize.
> 
> Not necessarily.  I unfortunately lost my Emacs trunk version and am not
> sure whether and when I'm able to recuperate it, but IIRC I had lots
> of incoherent states after doing M-F10.  But, maximizing Emacs via the
> button in the upper right corner (I never use that but call WinMaximize
> via a key combination instead) always works as expected.

No one suggested that the Windows maximize/restore button works differently
for Emacs frames.  (We did say, however, that the button state does not
get updated in some scenarios.)

The point is that Emacs code (& commands written using it) can let users
move or resize a "maximized" or "fullscreen" Emacs frame.  Windows users
cannot move or resize a maximized frame interactively (AFAIK - no system
menu etc.).  That's all.

And again, that's not a problem for me.  I just reported the difference
and asked whether that difference was intended.  Likewise, wrt the lack
of sync between the maximize/restore button and the maximized/restored
frame state.