--- Begin Message ---
|
Subject: |
27.0.50; window-swap-states doesn't swap window prev/next-buffers |
|
Date: |
Thu, 27 Sep 2018 02:39:35 +0300 |
|
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (x86_64-pc-linux-gnu) |
For a long time I've been using my own implementation that swaps window states:
(defun rotate-window-buffers (&optional n)
"Exchange buffers in all windows N times.
With positive N, it uses the window order of `window-list'.
With negative N, does this in the reverse order."
(interactive "p")
(let* ((ws (window-list))
(ls (mapcar (lambda (w)
(list (window-buffer w)
(window-point w)
(window-next-buffers w)
(window-prev-buffers w)))
ws))
(n (mod (or n 1) (length ws))))
(dolist (w (append (last ws n) (butlast ws n)))
(let ((l (pop ls)))
(set-window-buffer w (nth 0 l))
(set-window-point w (nth 1 l))
(set-window-next-buffers w (nth 2 l))
(set-window-prev-buffers w (nth 3 l))))))
Now I wanted to throw it away and to use window-swap-states
from Emacs core that should do the same. But after trying
I see that window-swap-states breaks the order of window buffers
for 'C-x <C-left>' (previous-buffer) and 'C-x <C-right>' (next-buffer)
because it doesn't swap window-prev-buffers and window-next-buffers.
Shouldn't window-swap-states also swap prev/next buffers?
--- End Message ---
--- Begin Message ---
|
Subject: |
Re: bug#32850: 27.0.50; window-swap-states doesn't swap window prev/next-buffers |
|
Date: |
Wed, 17 Oct 2018 01:37:03 +0300 |
|
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (x86_64-pc-linux-gnu) |
> But if you are sure that it won't harm anyone to make it unconditional
> leave it well alone. We can always add a customization later if
> someone needs it. Personally, I don't care.
I'd like to make it customizable by using the existing customization in
the arg WRITABLE of window-state-get and window-persistent-parameters,
even though formally prev/next-buffers is not a window parameter (maybe
it should be, I don't know).
>> This patch handles killed buffers, so it works for desktop saving as well
>> (because the desktop restores the frameset only after it reads all buffers):
>
> Please install so we can see whether there are any problems (in
> particular with the desktop which I don't use).
Done, with a small change: even though set-marker is idempotent in regard
to its POSITION arg (i.e. if POSITION is a marker, it creates an identical
marker), I added a check to not create a new one. OTOH, get-buffer is
idempotent too, but it seems window-state-put never receives a structure
with buffer objects, and I'm not sure why window-state-get should always
use buffer-name regardless of the value WRITABLE, i.e. why should it return
buffer names as strings instead of buffer objects even when WRITABLE is nil?
--- End Message ---