GNU bug report logs - #24240
25.1.50; window-state-put, image-mode and window scrolling

Previous Next

Package: emacs;

Reported by: Andreas Politz <politza <at> hochschule-trier.de>

Date: Mon, 15 Aug 2016 23:06:02 UTC

Severity: normal

Found in version 25.1.50

Done: martin rudalics <rudalics <at> gmx.at>

Bug is archived. No further changes may be made.

Full log


Message #26 received at 24240 <at> debbugs.gnu.org (full text, mbox):

From: martin rudalics <rudalics <at> gmx.at>
To: Andreas Politz <politza <at> hochschule-trier.de>
Cc: 24240 <at> debbugs.gnu.org
Subject: Re: bug#24240: 25.1.50;
 window-state-put, image-mode and window scrolling
Date: Thu, 18 Aug 2016 10:42:06 +0200
>> 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.