* bug#15382: desktop restores buffers in wrong order
@ 2013-09-15 8:51 Juri Linkov
2013-09-15 16:10 ` martin rudalics
2013-12-15 21:44 ` Juri Linkov
0 siblings, 2 replies; 13+ messages in thread
From: Juri Linkov @ 2013-09-15 8:51 UTC (permalink / raw)
To: 15382
The wrong order of restored desktop buffers is caused
by addition of these two conditions in `desktop-read':
(unless (desktop-restoring-frameset-p)
Removing this condition in two places in `desktop-read'
restores the right order.
Were these conditions intended to fix some problems?
Another bug is that point of the top restored buffer
is placed to a wrong position because `desktop-saved-frameset'
saves point of one buffer (possibly non-persistent), but
after restoring the desktop, `window-state-put' restores that point
to another buffer (persistent and restored from the desktop file),
thus applying the value of point of one buffer to another buffer.
^ permalink raw reply [flat|nested] 13+ messages in thread
* bug#15382: desktop restores buffers in wrong order
2013-09-15 8:51 bug#15382: desktop restores buffers in wrong order Juri Linkov
@ 2013-09-15 16:10 ` martin rudalics
2013-09-16 21:17 ` Juri Linkov
2013-12-15 21:44 ` Juri Linkov
1 sibling, 1 reply; 13+ messages in thread
From: martin rudalics @ 2013-09-15 16:10 UTC (permalink / raw)
To: Juri Linkov; +Cc: 15382
> Another bug is that point of the top restored buffer
> is placed to a wrong position because `desktop-saved-frameset'
> saves point of one buffer (possibly non-persistent), but
> after restoring the desktop, `window-state-put' restores that point
> to another buffer (persistent and restored from the desktop file),
> thus applying the value of point of one buffer to another buffer.
IIUC this can happen only if a buffer doesn't exist when restoring. I
tried to address this issue in revision#114294. Please have a look.
martin
^ permalink raw reply [flat|nested] 13+ messages in thread
* bug#15382: desktop restores buffers in wrong order
2013-09-15 16:10 ` martin rudalics
@ 2013-09-16 21:17 ` Juri Linkov
2013-09-17 6:45 ` martin rudalics
0 siblings, 1 reply; 13+ messages in thread
From: Juri Linkov @ 2013-09-16 21:17 UTC (permalink / raw)
To: martin rudalics; +Cc: 15382
>> Another bug is that point of the top restored buffer
>> is placed to a wrong position because `desktop-saved-frameset'
>> saves point of one buffer (possibly non-persistent), but
>> after restoring the desktop, `window-state-put' restores that point
>> to another buffer (persistent and restored from the desktop file),
>> thus applying the value of point of one buffer to another buffer.
>
> IIUC this can happen only if a buffer doesn't exist when restoring. I
> tried to address this issue in revision#114294. Please have a look.
Thanks, I verified that now it doesn't restore point in wrong buffer
from a non-existent buffer.
A question whether such non-existent buffers should be also
saved/restored is a separate question. Maybe they should,
with some empty placeholder buffers if buffer content
can't be restored?
^ permalink raw reply [flat|nested] 13+ messages in thread
* bug#15382: desktop restores buffers in wrong order
2013-09-16 21:17 ` Juri Linkov
@ 2013-09-17 6:45 ` martin rudalics
0 siblings, 0 replies; 13+ messages in thread
From: martin rudalics @ 2013-09-17 6:45 UTC (permalink / raw)
To: Juri Linkov; +Cc: 15382
> A question whether such non-existent buffers should be also
> saved/restored is a separate question. Maybe they should,
> with some empty placeholder buffers if buffer content
> can't be restored?
That's how it behaved initially using `get-buffer-create' IIRC. But
then people complained ...
martin
^ permalink raw reply [flat|nested] 13+ messages in thread
* bug#15382: desktop restores buffers in wrong order
2013-09-15 8:51 bug#15382: desktop restores buffers in wrong order Juri Linkov
2013-09-15 16:10 ` martin rudalics
@ 2013-12-15 21:44 ` Juri Linkov
2013-12-15 21:58 ` Juanma Barranquero
1 sibling, 1 reply; 13+ messages in thread
From: Juri Linkov @ 2013-12-15 21:44 UTC (permalink / raw)
To: 15382
> The wrong order of restored desktop buffers is caused
> by addition of these two conditions in `desktop-read':
>
> (unless (desktop-restoring-frameset-p)
>
> Removing this condition in two places in `desktop-read'
> restores the right order.
>
> Were these conditions intended to fix some problems?
It seems these conditions were intended only for multi-frame case.
So they should be removed in single-frame case. Then in multi-frame
case the right thing to do would be to save and restore the frame
parameters `buffer-list' and `buried-buffer-list' for every frame.
^ permalink raw reply [flat|nested] 13+ messages in thread
* bug#15382: desktop restores buffers in wrong order
2013-12-15 21:44 ` Juri Linkov
@ 2013-12-15 21:58 ` Juanma Barranquero
2013-12-16 21:05 ` Juri Linkov
0 siblings, 1 reply; 13+ messages in thread
From: Juanma Barranquero @ 2013-12-15 21:58 UTC (permalink / raw)
To: Juri Linkov; +Cc: 15382
On Sun, Dec 15, 2013 at 10:44 PM, Juri Linkov <juri@jurta.org> wrote:
>> (unless (desktop-restoring-frameset-p)
> It seems these conditions were intended only for multi-frame case.
Why do you think so?
J
^ permalink raw reply [flat|nested] 13+ messages in thread
* bug#15382: desktop restores buffers in wrong order
2013-12-15 21:58 ` Juanma Barranquero
@ 2013-12-16 21:05 ` Juri Linkov
2013-12-17 16:07 ` Juanma Barranquero
2013-12-17 17:31 ` martin rudalics
0 siblings, 2 replies; 13+ messages in thread
From: Juri Linkov @ 2013-12-16 21:05 UTC (permalink / raw)
To: Juanma Barranquero; +Cc: 15382
>>> (unless (desktop-restoring-frameset-p)
>
>> It seems these conditions were intended only for multi-frame case.
>
> Why do you think so?
Because I see no other explanation. This was added by your revno:113483
2013-07-21 Juanma Barranquero <lekktu@gmail.com>
* desktop.el (desktop-saved-frame-states):
...
(desktop-read): Use desktop-restoring-frames-p. Do not try to fix
buffer-lists when restoring frames. Suggested by Martin Rudalics.
Maybe Martin knows the purpose of not fixing buffer-lists in desktop-read?
^ permalink raw reply [flat|nested] 13+ messages in thread
* bug#15382: desktop restores buffers in wrong order
2013-12-16 21:05 ` Juri Linkov
@ 2013-12-17 16:07 ` Juanma Barranquero
2013-12-17 17:31 ` martin rudalics
2013-12-17 19:58 ` Juri Linkov
2013-12-17 17:31 ` martin rudalics
1 sibling, 2 replies; 13+ messages in thread
From: Juanma Barranquero @ 2013-12-17 16:07 UTC (permalink / raw)
To: Juri Linkov; +Cc: 15382
On Mon, Dec 16, 2013 at 10:05 PM, Juri Linkov <juri@jurta.org> wrote:
> Because I see no other explanation. This was added by your revno:113483
>
> 2013-07-21 Juanma Barranquero <lekktu@gmail.com>
>
> * desktop.el (desktop-saved-frame-states):
> ...
> (desktop-read): Use desktop-restoring-frames-p. Do not try to fix
> buffer-lists when restoring frames. Suggested by Martin Rudalics.
I understand why my change is related to not restoring the buffer list
order. I do not see why do you think that it is intended only for the
multi-frame case. Restoring framesets is not intended just for
multi-frame setups, I use it all the time in my single-frame setup.
> Maybe Martin knows the purpose of not fixing buffer-lists in desktop-read?
Correctly restoring the frames requires restoring the window-buffer
correspondence, so if you run the (mapc #'bury-buffer ...) code
afterwards, you destroy that correspondence. A way would be required
to reset buffer-list's without affecting how buffers are displayed...
J
^ permalink raw reply [flat|nested] 13+ messages in thread
* bug#15382: desktop restores buffers in wrong order
2013-12-16 21:05 ` Juri Linkov
2013-12-17 16:07 ` Juanma Barranquero
@ 2013-12-17 17:31 ` martin rudalics
1 sibling, 0 replies; 13+ messages in thread
From: martin rudalics @ 2013-12-17 17:31 UTC (permalink / raw)
To: Juri Linkov; +Cc: Juanma Barranquero, 15382
> (desktop-read): Use desktop-restoring-frames-p. Do not try to fix
> buffer-lists when restoring frames. Suggested by Martin Rudalics.
>
> Maybe Martin knows the purpose of not fixing buffer-lists in desktop-read?
I forgot. Probably because we have no interface to set these lists
manually. Replaying the order in which buffers were displayed looks
quite tedious.
martin
^ permalink raw reply [flat|nested] 13+ messages in thread
* bug#15382: desktop restores buffers in wrong order
2013-12-17 16:07 ` Juanma Barranquero
@ 2013-12-17 17:31 ` martin rudalics
2013-12-17 19:58 ` Juri Linkov
1 sibling, 0 replies; 13+ messages in thread
From: martin rudalics @ 2013-12-17 17:31 UTC (permalink / raw)
To: Juanma Barranquero; +Cc: 15382
> Correctly restoring the frames requires restoring the window-buffer
> correspondence, so if you run the (mapc #'bury-buffer ...) code
> afterwards, you destroy that correspondence. A way would be required
> to reset buffer-list's without affecting how buffers are displayed...
We would have to show and bury buffers to get the appropriate order for
frames. However, with multiple frames this might clobber the order of
the global buffer list. `set-window-prev-buffers' and
`set-window-next-buffers' should suffice to fix the window buffer lists
afterwards. In any case, this doesn't sound like a trivial task.
martin
^ permalink raw reply [flat|nested] 13+ messages in thread
* bug#15382: desktop restores buffers in wrong order
2013-12-17 16:07 ` Juanma Barranquero
2013-12-17 17:31 ` martin rudalics
@ 2013-12-17 19:58 ` Juri Linkov
2013-12-17 21:01 ` Juanma Barranquero
1 sibling, 1 reply; 13+ messages in thread
From: Juri Linkov @ 2013-12-17 19:58 UTC (permalink / raw)
To: Juanma Barranquero; +Cc: 15382
> I do not see why do you think that it is intended only for the
> multi-frame case. Restoring framesets is not intended just for
> multi-frame setups, I use it all the time in my single-frame setup.
I don't understand this condition:
(unless (desktop-restoring-frameset-p)
Why buffers should be restored in right order only when
restoring a single-frame (without restoring a frameset)
but not when restoring a single-frame from a frameset?
I think restoring the original order is needed in both cases.
> Correctly restoring the frames requires restoring the window-buffer
> correspondence, so if you run the (mapc #'bury-buffer ...) code
> afterwards, you destroy that correspondence. A way would be required
> to reset buffer-list's without affecting how buffers are displayed...
Maybe buffers should be saved in the desktop in reverse order?
This will restore the original order of the global buffer list.
And frame-local and window-local buffer lists needs to be saved too.
^ permalink raw reply [flat|nested] 13+ messages in thread
* bug#15382: desktop restores buffers in wrong order
2013-12-17 19:58 ` Juri Linkov
@ 2013-12-17 21:01 ` Juanma Barranquero
2014-02-05 8:07 ` Juri Linkov
0 siblings, 1 reply; 13+ messages in thread
From: Juanma Barranquero @ 2013-12-17 21:01 UTC (permalink / raw)
To: Juri Linkov; +Cc: 15382
On Tue, Dec 17, 2013 at 8:58 PM, Juri Linkov <juri@jurta.org> wrote:
> (unless (desktop-restoring-frameset-p)
>
> Why buffers should be restored in right order only when
> restoring a single-frame (without restoring a frameset)
> but not when restoring a single-frame from a frameset?
When desktop-restoring-frameset-p is nil you're not really "restoring
a single frame", because nothing about the frame (dimensions,
position, minibufferless state, window tree) is restored. You're
creating a new frame and restoring the buffers. In that case, the
window/buffer correspondence is not maintained so you can do whatever
you want with the buffer list order.
> Maybe buffers should be saved in the desktop in reverse order?
> This will restore the original order of the global buffer list.
You could try it with and without desktop-restore-frames and report back.
> And frame-local and window-local buffer lists needs to be saved too.
IIUC Martin's last comment, that's far from trivial.
J
^ permalink raw reply [flat|nested] 13+ messages in thread
* bug#15382: desktop restores buffers in wrong order
2013-12-17 21:01 ` Juanma Barranquero
@ 2014-02-05 8:07 ` Juri Linkov
0 siblings, 0 replies; 13+ messages in thread
From: Juri Linkov @ 2014-02-05 8:07 UTC (permalink / raw)
To: Juanma Barranquero; +Cc: 15382
>> Maybe buffers should be saved in the desktop in reverse order?
>> This will restore the original order of the global buffer list.
>
> You could try it with and without desktop-restore-frames and report back.
I tried to replace
(dolist (l (mapcar 'desktop-buffer-info (buffer-list)))
with
(dolist (l (mapcar 'desktop-buffer-info (nreverse (buffer-list))))
but it breaks the desktop saving by inserting the desktop file
to the current buffer. Then I tried to replace it with
(dolist (l (nreverse (mapcar 'desktop-buffer-info (buffer-list))))
and it saves the desktop in the natural order that could be replayed back
when restoring the desktop to get the buffer list in the same order.
But more code prevents from restoring in the same order, e.g.
;; Restore buffer list order with new buffer at end. Don't change
;; the order for old desktop files (old desktop module behavior).
(unless (< desktop-file-version 206)
(mapc 'bury-buffer buffer-list)
(when result (bury-buffer result)))
I'm afraid that changing the order of buffers in the desktop file
might require incrementing the version number in desktop-file-version.
^ permalink raw reply [flat|nested] 13+ messages in thread
end of thread, other threads:[~2014-02-05 8:07 UTC | newest]
Thread overview: 13+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2013-09-15 8:51 bug#15382: desktop restores buffers in wrong order Juri Linkov
2013-09-15 16:10 ` martin rudalics
2013-09-16 21:17 ` Juri Linkov
2013-09-17 6:45 ` martin rudalics
2013-12-15 21:44 ` Juri Linkov
2013-12-15 21:58 ` Juanma Barranquero
2013-12-16 21:05 ` Juri Linkov
2013-12-17 16:07 ` Juanma Barranquero
2013-12-17 17:31 ` martin rudalics
2013-12-17 19:58 ` Juri Linkov
2013-12-17 21:01 ` Juanma Barranquero
2014-02-05 8:07 ` Juri Linkov
2013-12-17 17:31 ` martin rudalics
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).