Re: show-enclosing-scopes

[Jefferson Carpenter]

Updated based on suggestions from this thread, thank you all! :D

* Delete-window no longer scrolls the view at all (rather sets a 
variable storing the scopes window's height that can be used to scroll 
the correct amount later).
* Split-window now checks whether, after scrolling the needed amount, 
point would still be on-screen; if yes, it scrolls, if no, it calls 
(recenter).
* All (goto-char) and (redisplay) calls are removed.

It still flickers, though.

For posterity, here's a link to the original:

https://raw.githubusercontent.com/jeffersoncarpenter/emacs.d/cff2aada902e15affd51b79a0cd16de693f6c4bc/show-enclosing-scope.el

New version:

https://raw.githubusercontent.com/jeffersoncarpenter/emacs.d/f9dcbe2d7636acedcf60ecb41baa1b3b4650e9a7/show-enclosing-scope.el

On 5/17/2018 2:31 PM, Stefan Monnier wrote:
>
> 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.
>
> Now the question is why does your package end up in situations with such
> ambiguous specifications?
>
> 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.

That makes sense.  Setting the window's `start` position and setting 
`force_start` to true is probably precisely why scroll-up seems to have 
effects outside of the elisp thunk is in, since these variables are 
never un-set, and are read come the next redisplay cycle.

On 5/17/2018 3:07 PM, Eli Zaretskii wrote:>> From: Stefan Monnier 
<address@hidden>
>> Date: Thu, 17 May 2018 10:31:44 -0400
>
>> 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.)

Correct, scroll-up/down is used to prevent text in the main window from 
moving vertically when the scopes window is deleted or resized.

The window is deleted in pre-command-hook so that commands like 
(switch-window), (balance-windows), and so on do not switch to or 
balance with the scopes window.  However, I'll probably actually change 
it to use either overlays or header-line-format, since those seem 
lighter, and I strongly suspect that deleting and recreating the window 
is what causes the remaining flickering.

Why it's shown above and not below is strictly UX - it's because in the 
source file, the text that is shown in the scopes window is above your 
buffer position and not below it.