bug#16475: enhancement request: remove vertical scroll bar automatically when not needed

[Eli Zaretskii]

> Date: Wed, 25 Oct 2017 09:47:00 +0200
> From: martin rudalics <rudalics@gmx.at>
> 
>  > Here is a first draft with a simple test (modifying xdisp.c), which
>  > probably nukes more than just the selected window's scroll bars when
>  > removing them, but it may be sufficient to revive this enhancement
>  > request in the event anyone is interested.
> 
> Thanks for looking into this.  The test for the vertical scroll bar case
> is whether the buffer beginning and its end are both visible in the
> window, taking into account visibility, overlays and the like.  I'm not
> sure whether
> 
>          && ZV - BEGV > BUF_Z (XBUFFER (w->contents)) - w->window_end_pos - 
> marker_position (w->start))
> 
> can handle that.

It at least should be consistent about using BEGV/ZV vs
BUF_BEGV/BUF_ZV.  Either the code assumes that W displays the current
buffer, or it doesn't.

Also, I don't understand the need for this part:

>     else
>       {
>         (*FRAME_TERMINAL (f)->condemn_scroll_bars_hook) (f);
>         (*FRAME_TERMINAL (f)->judge_scroll_bars_hook) (f);
>       }

We already call condemn_scroll_bars_hook at the beginning of a
redisplay cycle, and call judge_scroll_bars_hook at its end.  So why
did you need to do it here again, for each window separately?

More importantly, removing the scroll bar resizes the external
dimensions of the frame, to keep the windows' dimensions unchanged
(otherwise, we couldn't remove the scroll bars at the very end of the
window's redisplay).  You can see this in action if you toggle
scroll-bar-mode on and off.  So when the window shows _almost_ all the
text of the buffer, the frame would annoyingly oscillate in its
horizontal dimension.  This could be caused, for example, by echo-area
messages that resize the mini-window from time to time, or by the user
adjusting the window size.

By contrast, other applications I saw that remove the scroll bar when
it is not needed leave the frame's dimensions alone, and instead leave
more space for text display.  That is much better, but doing this in
Emacs would require to restructure the code that deals with the scroll
bars, because we cannot change window dimensions after all the
redisplay decisions were made, without requiring one more redisplay
cycle.

> Auto-removal of horizontal scroll bars is more complicated.  Basically,
> we could remove the horizontal scroll bar when no line in the window had
> to be truncated.  But then we have space to display the next buffer line
> and that line could be awfully long.

Actually, I think what happens with the removal of the horizontal
scroll bar mirrors the vertical scroll bar, just in the other
dimension.  Namely, the frame's height is modified to leave the
windows' dimensions unaltered.  But again, this could easily cause
annoying "oscillations" of the frame borders.

So if we want to have this feature, it must be an opt-in, and I'd be
interested how many people will like it.