show-enclosing-scopes

show-enclosing-scopes

[Jefferson Carpenter]

Just wrote a nifty little gadget that shows you the scopes you are 
inside of.  Eval this buffer:

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

Then move point around.  A map of the scopes you're in appears at the 
top of the window.  Useful for knowing where you are when you're paging 
up and down the file, or searching-forward for a text string, esp. in 
code with long functions.

Main problem is that it's very flickery -- not 100% sure why, but I'm 
pretty sure the (redisplay) are part of the reason.  I had to add those 
in order for (scroll-up) and (scroll-down) to interoperate properly with 
(goto-char).

show-enclosing-scopes

[Jefferson Carpenter]

Just wrote a nifty little gadget that shows you the scopes you are 
inside of.  Eval this buffer:

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

Then move point around.  A map of the scopes you're in appears at the 
top of the window.  Useful for knowing where you are when you're paging 
up and down the file, or searching-forward for a text string, esp. in 
code with long functions.

Main problem is that it's very flickery -- not 100% sure why, but I'm 
pretty sure the (redisplay) are part of the reason.  I had to add those 
in order for (scroll-up) and (scroll-down) to interoperate properly with 
(goto-char).

Re: show-enclosing-scopes

[Eli Zaretskii]

On May 16, 2018 9:41:20 AM GMT+03:00, Jefferson Carpenter <jeffersoncarpenter2@gmail.com> wrote:
> 
> Main problem is that it's very flickery -- not 100% sure why, but I'm 
> pretty sure the (redisplay) are part of the reason.  I had to add
> those 
> in order for (scroll-up) and (scroll-down) to interoperate properly
> with 
> (goto-char).

AFIU, you have there a function on pre-command-hook that
deletes a window and then forces redisplay.  So I'd say you get what
you asked for?

I don't think I understand why scroll commands rewuire that.

Re: show-enclosing-scopes

[Jefferson Carpenter]

replying to all

On 5/16/2018 8:03 AM, Eli Zaretskii wrote> AFIU, you have there a 
function on pre-command-hook that
> deletes a window and then forces redisplay.  So I'd say you get what
> you asked for?

Yeah, maybe :)

> I don't think I understand why scroll commands rewuire that.

Open a blank buffer and enter some text into it, for example "C-x ( F3 
<RET> C-x ) C-u 20 C-x e".  Then, run

(progn (scroll-up 1) (beginning-of-buffer))

The window scrolls up by 1 line and point is moved to the middle of the 
screen, even though (beginning-of-buffer) is sequenced after (scroll-up 
1).  Compare with:

(progn (scroll-up 1) (redisplay) (beginning-of-buffer))

This moves point to the beginning of the buffer, the (scroll-up 1) call 
essentially becoming a no-op.  This is why (redisplay) is used in my 
code: it appears to flush the internal state set by scroll-up and 
scroll-down, so that (beginning-of-buffer) has the intended effect.

Re: show-enclosing-scopes

[Stefan Monnier]

> (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.

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.
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`.


        Stefan

Re: show-enclosing-scopes

[Eli Zaretskii]

> 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.

Re: show-enclosing-scopes

[Stefan Monnier]

> 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.

I was assuming a situation such as a post-command-hook that wants to
override the scroll that might have taken place during the
preceding command.


        Stefan

Re: show-enclosing-scopes

[Eli Zaretskii]

> From: Stefan Monnier <monnier@IRO.UMontreal.CA>
> Date: Thu, 17 May 2018 13:41:37 -0400
> Cc: emacs-devel@gnu.org
> 
> > 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.
> 
> I was assuming a situation such as a post-command-hook that wants to
> override the scroll that might have taken place during the
> preceding command.

No, the scroll command is part of the pre-command-hook set up by the
package.  Or at least that was my understanding.

Re: show-enclosing-scopes

[Stefan Monnier]

>> > 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.
>> I was assuming a situation such as a post-command-hook that wants to
>> override the scroll that might have taken place during the
>> preceding command.
> No, the scroll command is part of the pre-command-hook set up by the
> package.  Or at least that was my understanding.

Then indeed, most likely the better solution is to not scroll in the
first place.


        Stefan

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 
<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.

Re: show-enclosing-scopes

[Jefferson Carpenter]

On 5/18/2018 1:13 AM, Jefferson Carpenter wrote:
> However, I'll probably actually change 
> it to use either overlays or header-line-format

Definitely overlays, since header-line-format might already be used for 
something else.

Re: show-enclosing-scopes

[Stefan Monnier]

> would still be on-screen; if yes, it scrolls, if no, it calls (recenter).
                                                                 ^^^^^^^^
which calls redisplay.

Better use (let ((recenter-redisplay nil)) (recenter)) to avoid this flicker.


        Stefan

Re: show-enclosing-scopes

[Jefferson Carpenter]

On 5/18/2018 2:22 AM, Stefan Monnier wrote:
> Better use (let ((recenter-redisplay nil)) (recenter)) to avoid this flicker.

Did it, still flickering.

Also, (recenter-top-bottom) is behaving really bizarrely now.  I'll have 
to look into that.

Re: show-enclosing-scopes

[Eli Zaretskii]

> From: Jefferson Carpenter <jeffersoncarpenter2@gmail.com>
> Date: Fri, 18 May 2018 01:16:32 +0000
> 
> On 5/18/2018 1:13 AM, Jefferson Carpenter wrote:
> > However, I'll probably actually change 
> > it to use either overlays or header-line-format
> 
> Definitely overlays, since header-line-format might already be used for 
> something else.

FYI: Overlay strings at beginning of window have "issues" with
scrolling, see bug#31276.  Caveat emptor!

Re: show-enclosing-scopes

[Jefferson Carpenter]

On 5/18/2018 6:02 AM, Jefferson Carpenter wrote:> Also, 
(recenter-top-bottom) is behaving really bizarrely now.  I'll have
> to look into that.

I do think it would make sense for as many state changes as possible to 
happen during command execution, pending a redisplay once execution has 
completely finished.  (redisplay) shall not have to be added after 
(scroll-up) and (scroll-down) in order to set point subsequently, and 
functions that recenter point, alter the number of open windows, and so 
on, don't needlessly redisplay the buffer while synchronous elisp code 
is executing.

Pickles,
Jefferson

Re: show-enclosing-scopes

[Jefferson Carpenter]

-Pickles

On 5/18/2018 6:18 AM, Jefferson Carpenter wrote:
> On 5/18/2018 6:02 AM, Jefferson Carpenter wrote:> Also, 
> (recenter-top-bottom) is behaving really bizarrely now.  I'll have
>> to look into that.
> 
> I do think it would make sense for as many state changes as possible to 
> happen during command execution, pending a redisplay once execution has 
> completely finished.  (redisplay) shall not have to be added after 
> (scroll-up) and (scroll-down) in order to set point subsequently, and 
> functions that recenter point, alter the number of open windows, and so 
> on, don't needlessly redisplay the buffer while synchronous elisp code 
> is executing.
> 
> Pickles,
> Jefferson

Re: show-enclosing-scopes

[Eli Zaretskii]

> From: Jefferson Carpenter <jeffersoncarpenter2@gmail.com>
> Date: Fri, 18 May 2018 06:18:15 +0000
> 
> I do think it would make sense for as many state changes as possible to 
> happen during command execution, pending a redisplay once execution has 
> completely finished.  (redisplay) shall not have to be added after 
> (scroll-up) and (scroll-down) in order to set point subsequently, and 
> functions that recenter point, alter the number of open windows, and so 
> on, don't needlessly redisplay the buffer while synchronous elisp code 
> is executing.

With one exception, you describe what already happens.

The exception is the scroll commands: they are special, because they
need to tell redisplay where to put the window's starting point --
that's what scrolling commands do in Emacs.  If you care about point
position after scrolling, and if point position could move out of the
visible portion as result of the scrolling, your best bet is not to
use scrolling commands in your program at all, at least on those
cases.  (My advice is to stay away of scroll commands entirely in Lisp
programs, except in commands whose explicit purpose is to scroll.)

Re: show-enclosing-scopes

[Eli Zaretskii]

> From: Jefferson Carpenter <jeffersoncarpenter2@gmail.com>
> Date: Fri, 18 May 2018 06:02:48 +0000
> 
> On 5/18/2018 2:22 AM, Stefan Monnier wrote:
> > Better use (let ((recenter-redisplay nil)) (recenter)) to avoid this flicker.
> 
> Did it, still flickering.

Where's the latest version to take a look at?

Re: show-enclosing-scopes

[Eli Zaretskii]

> From: Jefferson Carpenter <jeffersoncarpenter2@gmail.com>
> Date: Fri, 18 May 2018 06:02:48 +0000
> 
> On 5/18/2018 2:22 AM, Stefan Monnier wrote:
> > Better use (let ((recenter-redisplay nil)) (recenter)) to avoid this flicker.
> 
> Did it, still flickering.

Here, it flickers only in the scroll-bar area, and that is expected,
since you delete the scopes window and then recreate it -- this has to
redraw the scroll bar, and will necessarily flicker.

Where does it flicker on your system?  And what OS is that, with what
toolkit?

Btw, you have a bug in show-enclosing-scope--split-window: it doesn't
call set-window-buffer on the "base window", so the fringe, and
probably also the right margin (if it has to be non-empty) are not
redrawn when the window is split.

Re: show-enclosing-scopes

[Jefferson Carpenter]

On 5/18/2018 8:46 AM, Eli Zaretskii wrote:
> 
> Where's the latest version to take a look at?
> 

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

Re: show-enclosing-scopes

[Eli Zaretskii]

> Cc: emacs-devel@gnu.org
> From: Jefferson Carpenter <jeffersoncarpenter2@gmail.com>
> Date: Sat, 19 May 2018 04:17:31 +0000
> 
> On 5/18/2018 8:46 AM, Eli Zaretskii wrote:
> > 
> > Where's the latest version to take a look at?
> > 
> 
> https://raw.githubusercontent.com/jeffersoncarpenter/emacs.d/master/show-enclosing-scope.el

Like I said: this only flickers for me in the scroll-bar area.

Re: show-enclosing-scopes

[Jefferson Carpenter]

On 5/19/2018 8:38 AM, Eli Zaretskii wrote:
> 
> Like I said: this only flickers for me in the scroll-bar area.
> 

I'll get back to you soon.

Re: show-enclosing-scopes

[Jefferson Carpenter]

Still busy moving from Minnesota to Montana

On 5/21/2018 3:31 AM, Jefferson Carpenter wrote:
> On 5/19/2018 8:38 AM, Eli Zaretskii wrote:
>>
>> Like I said: this only flickers for me in the scroll-bar area.
>>
> 
> I'll get back to you soon.

Re: show-enclosing-scopes

[Jefferson Carpenter]

On 5/18/2018 9:02 AM, Eli Zaretskii wrote:
> Here, it flickers only in the scroll-bar area, and that is expected,
> since you delete the scopes window and then recreate it -- this has to
> redraw the scroll bar, and will necessarily flicker.

Updated so that it no longer deletes the window and re-creates it quite 
so many times - namely it no longer requires a pre-command-hook.

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

> 
> Where does it flicker on your system?  And what OS is that, with what
> toolkit?

Good news, it doesn't flicker any more since I removed window deletion 
in the pre-command-hook.  In fact, there are no outstanding bugs as far 
as I know.

(The next step now is to make it more intelligent about what lines to 
show inside the minimap window.  Currently it does it purely based on 
indentation, which is not optimal in many cases.)

> 
> Btw, you have a bug in show-enclosing-scope--split-window: it doesn't
> call set-window-buffer on the "base window", so the fringe, and
> probably also the right margin (if it has to be non-empty) are not
> redrawn when the window is split.
> 

That's true -- don't tell anyone but I literally copied and pasted the 
code for creating and deleting the window from sublimity-mode, so I 
don't know if the code regarding margins and fringes is correct or not 
in my case.  I haven't had a problem with it, but I need to look into it.