From: martin rudalics <rudalics@gmx.at>
To: Eli Zaretskii <eliz@gnu.org>
Cc: 12170@debbugs.gnu.org, wbrodie@panix.com
Subject: bug#12170: save-excursion fails boundary case with recenter
Date: Sat, 11 Aug 2012 16:22:39 +0200 [thread overview]
Message-ID: <50266AAF.4000504@gmx.at> (raw)
In-Reply-To: <83sjbtd6p0.fsf@gnu.org>
> Your recipe also calls set-window-point, which moves point on its own,
> and also does this:
>
> /* We have to make sure that redisplay updates the window to show
> the new value of point. */
> if (!EQ (window, selected_window))
> ++windows_or_buffers_changed;
>
> The windows_or_buffers_changed flag will force a thorough redisplay.
>
> Given this, do we still have something unexplained?
Yes, because `set-window-point' doesn't set windows_or_buffers_changed
in the case at hand since the window is the selected window. Or am I
missing something?
>> If you agree, then we'd have to explain why a subsequent invocation of
>> `set-window-start' with NOFORCE t can override the setting of the window
>> start position implied by the last invocation of one of the functions
>> mentioned above.
>
> You didn't just call set-window-start, you also called
> set-window-point. If I remove that second call, the result of your
> code is very different, and the window start position as the macro set
> it is still in effect when control is returned.
But `set-window-point' should be equivalent to `goto-char' here because
the window is the selected window.
>> >> w->force_start 1 will cause redisplay to honor the start position set up
>> >> by `recenter'
>> >
>> > Only if point will be visible when window is displayed starting at
>> > startp.
>>
>> I completely miss you here.
>
> I meant this code:
>
> w->optional_new_start = 0;
> start_display (&it, w, startp);
> move_it_to (&it, PT, 0, it.last_visible_y, -1,
> MOVE_TO_POS | MOVE_TO_X | MOVE_TO_Y);
> if (IT_CHARPOS (it) == PT)
> w->force_start = 1;
> /* IT may overshoot PT if text at PT is invisible. */
> else if (IT_CHARPOS (it) > PT && CHARPOS (startp) <= PT)
> w->force_start = 1;
>
> It only sets the force_start flag if displaying the window starting at
> startp will show point visible inside the window. The call to
> move_it_to moves in a simulated display lines, and stops either at
> point or at the last pixel position visible in the window, whichever
> happens first. The subsequent test that IT_CHARPOS (it) == PT
> verifies that it stopped at point and not because it reached the end
> of the text displayed in the window.
>
> Ergo, sometimes setting the window start position will not be
> honored. That's what the comment above all this means when it says:
>
> /* If someone specified a new starting point but did not insist,
> check whether it can be used. */
>
> "Did not insist" means that whoever set w->optional_new_start did not
> also set w->force_start. The "check whether it can be used" part
> describes what I just explained.
I believe you. But it remains a mystery to me why `set-window-point'
should make a difference here. As a matter of fact, if I do
(progn
(defmacro save-this-window-excursion (&rest body)
"..."
(let ((start (make-symbol "start"))
(point (make-symbol "point")))
`(let ((,start (copy-marker (window-start)))
(,point (copy-marker (window-point))))
(save-selected-window
(progn ,@body))
(set-window-start (selected-window) ,start t)
(with-current-buffer (window-buffer (selected-window))
(goto-char ,point)))))
(defun f (n)
(save-this-window-excursion (forward-line (- n)) (recenter 0)))
(let ((buffer (switch-to-buffer "foo"))
(height (1- (window-height (get-buffer-window "foo")))))
(insert-char 10 (* height 2))
(let ((pt (point)))
(f height)
(redisplay)
(message "height %s old %s new %s" height pt (point)))))
I get the same results as with `set-window-point'. IMHO the
`set-window-start' call makes the difference but I don't understand why.
martin
next prev parent reply other threads:[~2012-08-11 14:22 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-08-10 1:23 bug#12170: save-excursion fails boundary case with recenter Bill Brodie
2012-08-10 9:34 ` martin rudalics
2012-08-10 9:50 ` Bastien
2012-08-10 13:03 ` martin rudalics
2012-08-10 13:40 ` Bill Brodie
2012-08-10 14:47 ` martin rudalics
2012-08-10 16:18 ` Stefan Monnier
2012-08-10 16:47 ` martin rudalics
2012-08-10 17:07 ` Stefan Monnier
2012-08-10 19:01 ` Eli Zaretskii
2012-08-11 9:32 ` martin rudalics
2012-08-11 11:11 ` Eli Zaretskii
2012-08-11 14:22 ` martin rudalics [this message]
2012-08-11 15:10 ` Eli Zaretskii
2012-08-11 16:05 ` martin rudalics
2012-08-11 16:31 ` Eli Zaretskii
2012-08-11 16:49 ` Eli Zaretskii
2012-08-12 10:31 ` martin rudalics
2012-08-11 16:27 ` Bill Brodie
2012-08-10 15:04 ` Stefan Monnier
2012-08-10 15:46 ` Bill Brodie
2012-08-10 16:46 ` martin rudalics
2012-08-10 16:46 ` martin rudalics
2012-08-10 18:58 ` Eli Zaretskii
2012-08-11 9:31 ` martin rudalics
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=50266AAF.4000504@gmx.at \
--to=rudalics@gmx.at \
--cc=12170@debbugs.gnu.org \
--cc=eliz@gnu.org \
--cc=wbrodie@panix.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.