GNU bug report logs -
#32850
27.0.50; window-swap-states doesn't swap window prev/next-buffers
Previous Next
Reported by: Juri Linkov <juri <at> linkov.net>
Date: Thu, 27 Sep 2018 00:06:02 UTC
Severity: minor
Found in version 27.0.50
Done: Juri Linkov <juri <at> linkov.net>
Bug is archived. No further changes may be made.
Full log
View this message in rfc822 format
[Message part 1 (text/plain, inline)]
Your message dated Wed, 17 Oct 2018 01:37:03 +0300
with message-id <8736t57jcs.fsf <at> mail.linkov.net>
and subject line Re: bug#32850: 27.0.50; window-swap-states doesn't swap window prev/next-buffers
has caused the debbugs.gnu.org bug report #32850,
regarding 27.0.50; window-swap-states doesn't swap window prev/next-buffers
to be marked as done.
(If you believe you have received this mail in error, please contact
help-debbugs <at> gnu.org.)
--
32850: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=32850
GNU Bug Tracking System
Contact help-debbugs <at> gnu.org with problems
[Message part 2 (message/rfc822, inline)]
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?
[Message part 3 (message/rfc822, inline)]
> 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?
This bug report was last modified 6 years and 183 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.