Re: show-enclosing-scopes

[Eli Zaretskii <eliz@gnu.org>]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Date: Thu, 17 May 2018 10:31:44 -0400
> 
> > (progn (scroll-up 1) (beginning-of-buffer))
> 
> So you have here an ambiguous specification: on the one hand you
> specified the window-start via scroll-up, on the other you specified
> point with beginning-of-buffer.  Since point needs to be within the
> visible part of the buffer, the redisplay engine has to choose which of
> the two requests to override.

Right.  And using scroll commands forces redisplay to obey the
window-start setting.

> Now the question is why does your package end up in situations with such
> ambiguous specifications?

I don't understand that, either.  I looked at the relevant code in the
package, and my interpretation is this:

  . scroll-up/down is used to prevent text in the window from moving
    vertically when the window showing the scopes is deleted: without
    the scroll, text would move up, since the window to be deleted is
    above the window showing the current buffer.  (Why the scopes
    window needs to be deleted and recreated anew each command, and
    why is it shown above and not below, are two other relevant
    questions, but let's assume it's indeed required.)
  . goto-char is called in the same function that calls scroll-up/down
    so that point is kept where it was before

Assuming that my interpretation is accurate, I have two questions:

  . why is there a need to call goto-char at all?  Since all the text
    that was visible before the scroll will also be visible after it,
    point should be visible as well, and there should be no need to
    move it.

  . if indeed there is a need to move point due to some factor I'm
    missing, that goto-char should bring point back into the window,
    in which case redisplay will not need to move point again.  IOW,
    using beginning-of-buffer in the short recipe posted to explain
    the problem does not seem to be representative of the real-life
    use, and I again don't understand the need for calling 'redisplay'
    to avoid something.

> Assuming you don't have any control over the scroll-up part and you want
> to override it via beginning-of-buffer, there is indeed currently no
> easy way to get that, AFAICT: this is controlled by the `force_start`
> field in the window which will have been set by scroll-up (and can be
> set via set-window-start) but can't be "unset" directly.
> Maybe you can try
> 
>     (defun my-unset-window-force-start ()
>       (cl-assert (eq (current-buffer) (window-buffer)))
>       (save-excursion
>         (let ((buf (current-buffer)))
>           (with-temp-buffer
>             (set-window-buffer (selected-window) (current-buffer) 'keep-margins)
>             (set-window-buffer (selected-window) buf 'keep-margins)))))
> 
> since it seems that set-window-buffer does unset `force-start`.
> It will also cause undesirable side-effects, but maybe in your case they
> will be less annoying than those of `redisplay`.

I'd say if it is known that the goal point is not inside the visible
portion of the buffer after scrolling, don't scroll at all; instead,
just move point to the goal.

But as I said above, I don't think I understand the details well
enough yet.