unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
From: Eli Zaretskii <eliz@gnu.org>
To: martin rudalics <rudalics@gmx.at>
Cc: 16475@debbugs.gnu.org, esq@lawlist.com
Subject: bug#16475: enhancement request: remove vertical scroll bar automatically when not needed
Date: Wed, 25 Oct 2017 17:40:24 +0300	[thread overview]
Message-ID: <83po9b8f53.fsf@gnu.org> (raw)
In-Reply-To: <59F04174.6090601@gmx.at> (message from martin rudalics on Wed, 25 Oct 2017 09:47:00 +0200)

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





  reply	other threads:[~2017-10-25 14:40 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-01-17  4:42 bug#16475: 24.3.50; enhancement request: remove vertical scroll bar automatically when not needed Drew Adams
2014-01-17 14:35 ` Stefan Monnier
2016-02-12  2:46 ` Keith David Bershatsky
2017-10-25  5:27 ` bug#16475: " Keith David Bershatsky
2017-10-25  7:47   ` martin rudalics
2017-10-25 14:40     ` Eli Zaretskii [this message]
2017-10-26  7:56       ` martin rudalics
2017-10-26 15:59         ` Eli Zaretskii
2017-10-27  8:25           ` martin rudalics
2017-10-27  2:44         ` Richard Stallman
2017-10-25 22:25 ` Keith David Bershatsky
2017-10-26 16:30   ` Eli Zaretskii
2017-10-26 16:03 ` Keith David Bershatsky
2017-10-26 17:07   ` Eli Zaretskii
2017-10-27  8:26     ` martin rudalics

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=83po9b8f53.fsf@gnu.org \
    --to=eliz@gnu.org \
    --cc=16475@debbugs.gnu.org \
    --cc=esq@lawlist.com \
    --cc=rudalics@gmx.at \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).