GNU bug report logs -
#24240
25.1.50; window-state-put, image-mode and window scrolling
Previous Next
Full log
View this message in rfc822 format
>> But do you mean that setting NOFORCE alone will handle your bug already
>> and we don't need ‘frame-after-make-frame’ after all?
>
> Yes, it would.
OK. Pushed to master. In any case it fixes a scenario like the following:
(let (window state point start)
(find-file "../lisp/window.el")
(forward-line 30)
(setq window (selected-window))
(setq state (window-state-get window))
(setq start (window-start window))
(setq point (window-point window))
(message "Before split - %s ... start: %s ... point: %s" window start point) (sit-for 3)
(split-window window)
(message "After split - %s ... start: %s ... point: %s" window start point) (sit-for 3)
(window-state-put state window)
(sit-for 0)
(message
"Final - %s ... start: %s -> %s ... point: %s -> %s"
window start (window-start window) point (window-point window)))
> At least in the case of image-mode, it would actually be preferable to
> let window-state-put override image-mode-reapply-winprops's scrolling,
> because it has the correct value. I don't know how familiar you are
> with image-mode,
Not at all.
> but if it has no record for a particular window, it
> restores the value last set in any window. The difference would be
> visible in case the buffer is shown in more than one window (with
> different scroll values).
And you mean that the situation after your fix is as expected and the
single, final call of ‘window-configuration-change-hook’ I proposed
earlier would spoil that? Technically spoken, it would fail because
‘window-state-put’ creates windows anew and for a new window image-mode
has no record of the previous position of the image in that window? Do
you agree with that interpretation?
martin
This bug report was last modified 8 years and 209 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.