>> I'm saying that changing it to
>> (save-excursion (save-window-excursion (select-window (next-window))))
>> ought to solve the problem too, and the approach is less risky.
> That's true. But what about:
> (save-window-excursion (forward-char 1) (select-window (next-window)))
> I'd expect this to move the window's cursor by one char.
> No, that is not what it should do. (select-window (next-window))
> positions point at the position for the other window, and that is the
> value that should remain in effect.
> So I think there is no bug here.
I have a hard time believing you tyhink this behavior is desirable.
So just to double check: you do realize I'm talking about the window's
cursor. Not the buffer's point. Whether the buffer's point is changed or
not doesn't bother me.
Another way to look at the problem:
A save-selected-window around a save-window-excursion is redundant because
save-window-excursion saves/restores the selected window. I.e.
(save-selected-window (save-window-excursion BODY))
==
(save-window-excursion BODY)
Yet the "reverse" is not true (with the current code):
(save-window-excursion (save-selected-window BODY))
=/=
(save-window-excursion BODY)
I find this very unintuitive at least, and inconvenient in the above case.
Stefan
_______________________________________________
Emacs-pretest-bug mailing list
Emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
