Re: show-enclosing-scopes

[Jefferson Carpenter <jeffersoncarpenter2@gmail.com>]

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 
<monnier@iro.umontreal.ca>
 >> 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.