bug#14598: 24.3; global-hl-line-mode + text-scale-adjust + next-line + scrolling

bug#14598: 24.3; global-hl-line-mode + text-scale-adjust + next-line + scrolling

[Phil Sainty]

With global-hl-line-mode enabled (but not local hl-line-mode,
which is implemented differently) and with a smaller font via
text-scale-adjust, scrolling off the bottom of the window with
next-line gets incredibly glitchy.

Recipe:

* emacs -Q
* Visit a file or add text with more lines than the current window
* M-x global-hl-line-mode
* C-x C--
* Hold down C-n




In GNU Emacs 24.3.1 (x86_64-pc-linux-gnu, GTK+ Version 3.4.2)
  of 2013-04-14 on chindi10, modified by Debian
Windowing system distributor `The X.Org Foundation', version 11.0.11300000
System Description:	Ubuntu 12.04.2 LTS

Configured using:
  `configure '--build' 'x86_64-linux-gnu' '--build' 'x86_64-linux-gnu'
  '--prefix=/usr' '--sharedstatedir=/var/lib' '--libexecdir=/usr/lib'
  '--localstatedir=/var/lib' '--infodir=/usr/share/info'
  '--mandir=/usr/share/man' '--with-pop=yes'
 
'--enable-locallisppath=/etc/emacs24:/etc/emacs:/usr/local/share/emacs/24.3/site-lisp:/usr/local/share/emacs/site-lisp:/usr/share/emacs/24.3/site-lisp:/usr/share/emacs/site-lisp'
  '--with-crt-dir=/usr/lib/x86_64-linux-gnu' '--with-x=yes'
  '--with-x-toolkit=gtk3' '--with-toolkit-scroll-bars'
  'build_alias=x86_64-linux-gnu' 'CFLAGS=-g -O2 -fstack-protector
  --param=ssp-buffer-size=4 -Wformat -Wformat-security
  -Werror=format-security -Wall' 'LDFLAGS=-Wl,-Bsymbolic-functions
  -Wl,-z,relro' 'CPPFLAGS=-D_FORTIFY_SOURCE=2''

Important settings:
   value of $LANG: en_NZ.UTF-8
   locale-coding-system: utf-8-unix
   default enable-multibyte-characters: t

Major mode: Emacs-Lisp

Minor modes in effect:
   text-scale-mode: t
   global-hl-line-mode: t
   tooltip-mode: t
   mouse-wheel-mode: t
   tool-bar-mode: t
   menu-bar-mode: t
   file-name-shadow-mode: t
   global-font-lock-mode: t
   font-lock-mode: t
   blink-cursor-mode: t
   auto-composition-mode: t
   auto-encryption-mode: t
   auto-compression-mode: t
   buffer-read-only: t
   line-number-mode: t
   transient-mark-mode: t

Recent input:
C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n
C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n
C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n
C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n
C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n
C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n
C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n
C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n
C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n
C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n
C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n
C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n
C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n
C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n
C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n
C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n
C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n
C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n
C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n
C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n
C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n
C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n
C-n C-n C-n <down> <down> M-x r e p o r t <tab> <r
eturn>

Recent messages:
Auto-saving...
<down> runs the command next-line
uncompressing simple.el.gz...done
Note: file is write protected
Mark set
Mark saved where search started
Type C-x 1 to delete the help window.
<down> runs the command next-line
Auto-saving...
Use +,-,0 for further adjustment

Load-path shadows:
None found.

Features:
(help-fns misearch multi-isearch jka-compr find-func shadow sort
gnus-util mail-extr emacsbug message format-spec rfc822 mml mml-sec
mm-decode mm-bodies mm-encode mail-parse rfc2231 mailabbrev gmm-utils
mailheader sendmail rfc2047 rfc2045 ietf-drums mm-util mail-prsvr
mail-utils face-remap cus-start cus-load hl-line js byte-opt bytecomp
byte-compile cconv json imenu thingatpt cc-mode cc-fonts cc-guess
cc-menus cc-cmds cc-styles cc-align cc-engine cc-vars cc-defs sh-script
smie executable dired help-mode easymenu time-date tooltip ediff-hook
vc-hooks lisp-float-type mwheel x-win x-dnd tool-bar dnd fontset image
regexp-opt fringe tabulated-list newcomment lisp-mode register page
menu-bar rfn-eshadow timer select scroll-bar mouse jit-lock font-lock
syntax facemenu font-core frame cham georgian utf-8-lang misc-lang
vietnamese tibetan thai tai-viet lao korean japanese hebrew greek
romanian slovak czech european ethiopic indian cyrillic chinese
case-table epa-hook jka-cmpr-hook help simple abbrev minibuffer loaddefs
button faces cus-face macroexp files text-properties overlay sha1 md5
base64 format env code-pages mule custom widget hashtable-print-readable
backquote make-network-process dbusbind dynamic-setting
system-font-setting font-render-setting move-toolbar gtk x-toolkit x
multi-tty emacs)

bug#14598: 24.3; global-hl-line-mode + text-scale-adjust + next-line + scrolling

[Eli Zaretskii]

> Date: Thu, 13 Jun 2013 00:05:48 +1200
> From: Phil Sainty <psainty@orcon.net.nz>
> 
> With global-hl-line-mode enabled (but not local hl-line-mode,
> which is implemented differently) and with a smaller font via
> text-scale-adjust, scrolling off the bottom of the window with
> next-line gets incredibly glitchy.

Unfortunately, my only suggestion is "don't do that": either don't use
global-hl-line-mode, or don't make your default face smaller using
text-scale-adjust.  Emacs does all scroll calculations assuming the
original default face size, which was in effect when the frame was
created.  This design assumes that the frame mostly uses that size,
with occasional smaller or larger characters here and there; resizing
_all_ of the text breaks that assumption.  On top of that,
global-hl-line-mode installs both pre-command-hook and
post-command-hook which manipulate overlays, which kills all of the
clever tricks Emacs has up its sleeve to deal with variable fonts and
partially visible lines.  What you see as result is basically a
recenter on every C-n, except that sometimes Emacs scrolls by just a
few pixels to make a line fully visible.

Fixing this would mean a major redesign of the scrolling support in
the display engine.  Patches are welcome, as always.  Until then, this
will remain a wishlist, I'm afraid.

Sorry.

bug#14598: 24.3; global-hl-line-mode + text-scale-adjust + next-line + scrolling

[E Sabof]

[-- Attachment #1: Type: text/plain, Size: 235 bytes --]

(setq auto-window-vscroll nil) seems to fix the particular problem. Would
it make sense to make it nil by default, and only turn it on in modes that
use images? In other contexts it tends to make the behavior less
predictable.

Evgeni

[-- Attachment #2: Type: text/html, Size: 283 bytes --]

bug#14598: 24.3; global-hl-line-mode + text-scale-adjust + next-line + scrolling

[Eli Zaretskii]

> Date: Sat, 15 Jun 2013 12:45:43 +0100
> From: E Sabof <esabof@gmail.com>
> 
> (setq auto-window-vscroll nil) seems to fix the particular problem. Would
> it make sense to make it nil by default, and only turn it on in modes that
> use images?

I have no opinion on that.  In my experience, arguing about defaults
is a waste of time.  Please note, however, that Emacs can display
images in any mode, so I wouldn't know how to identify the "modes that
use images".

bug#14598: 24.3; global-hl-line-mode + text-scale-adjust + next-line + scrolling

[E Sabof]

[-- Attachment #1: Type: text/plain, Size: 836 bytes --]

On Sat, Jun 15, 2013 at 12:55 PM, Eli Zaretskii <eliz@gnu.org> wrote:

> > Date: Sat, 15 Jun 2013 12:45:43 +0100
> > From: E Sabof <esabof@gmail.com>
> >
> > (setq auto-window-vscroll nil) seems to fix the particular problem. Would
> > it make sense to make it nil by default, and only turn it on in modes
> that
> > use images?
>
> I have no opinion on that.  In my experience, arguing about defaults
> is a waste of time.  Please note, however, that Emacs can display
> images in any mode, so I wouldn't know how to identify the "modes that
> use images".
>

One way to do it would be for modes to identify themselves, by setting
auto-window-vscroll to t.

A perhaps better approach might be to make auto-window-vscroll only act on
lines significantly larger than default height (x4?), and not on any line
with a non-standard height.

[-- Attachment #2: Type: text/html, Size: 1621 bytes --]

bug#14598: 24.3; global-hl-line-mode + text-scale-adjust + next-line + scrolling

[Eli Zaretskii]

> Date: Sat, 15 Jun 2013 13:10:22 +0100
> From: E Sabof <esabof@gmail.com>
> Cc: psainty@orcon.net.nz, 14598@debbugs.gnu.org
> 
> > I have no opinion on that.  In my experience, arguing about defaults
> > is a waste of time.  Please note, however, that Emacs can display
> > images in any mode, so I wouldn't know how to identify the "modes that
> > use images".
> >
> 
> One way to do it would be for modes to identify themselves, by setting
> auto-window-vscroll to t.

Then every mode will need to do that.

> A perhaps better approach might be to make auto-window-vscroll only act on
> lines significantly larger than default height (x4?), and not on any line
> with a non-standard height.

You need to consider the window height as well (or only that), not
just the default font size.  And if we go that way, I'd argue that
vscroll should be used regardless of the value of auto-window-vscroll.

bug#14598: 24.3; global-hl-line-mode + text-scale-adjust + next-line + scrolling

[E Sabof]

[-- Attachment #1: Type: text/plain, Size: 1495 bytes --]

On Sat, Jun 15, 2013 at 1:45 PM, Eli Zaretskii <eliz@gnu.org> wrote:

> > Date: Sat, 15 Jun 2013 13:10:22 +0100
> > From: E Sabof <esabof@gmail.com>
> > Cc: psainty@orcon.net.nz, 14598@debbugs.gnu.org
> >
> > > I have no opinion on that.  In my experience, arguing about defaults
> > > is a waste of time.  Please note, however, that Emacs can display
> > > images in any mode, so I wouldn't know how to identify the "modes that
> > > use images".
> > >
> >
> > One way to do it would be for modes to identify themselves, by setting
> > auto-window-vscroll to t.
>
> Then every mode will need to do that.
>

The idea is that in practice, the functionality isn't needed most of the
time, but backfires with text-scale-adjust. The only two modes that I use
that mix images and text are org-mode and w3m. I'm not sure if I like the
idea myself, but it might deserve a place on the side of the table.


>
> > A perhaps better approach might be to make auto-window-vscroll only act
> on
> > lines significantly larger than default height (x4?), and not on any line
> > with a non-standard height.
>
> You need to consider the window height as well (or only that), not
> just the default font size.  And if we go that way, I'd argue that
> vscroll should be used regardless of the value of auto-window-vscroll.
>

At the moment I'm a bit confused as to how auto-window-vscroll works right
now. I might try to dig a bit deeper at some point, and put together a
prototype of how I think it should work.

[-- Attachment #2: Type: text/html, Size: 2445 bytes --]

bug#14598: 24.3; global-hl-line-mode + text-scale-adjust + next-line + scrolling

[Eli Zaretskii]

> Date: Sat, 15 Jun 2013 23:48:51 +0100
> From: E Sabof <esabof@gmail.com>
> Cc: psainty@orcon.net.nz, 14598@debbugs.gnu.org
> 
> > > One way to do it would be for modes to identify themselves, by setting
> > > auto-window-vscroll to t.
> >
> > Then every mode will need to do that.
> >
> 
> The idea is that in practice, the functionality isn't needed most of the
> time, but backfires with text-scale-adjust. The only two modes that I use
> that mix images and text are org-mode and w3m.

There are many more, and I expect more and more to do so.

> > > A perhaps better approach might be to make auto-window-vscroll only act
> > on
> > > lines significantly larger than default height (x4?), and not on any line
> > > with a non-standard height.
> >
> > You need to consider the window height as well (or only that), not
> > just the default font size.  And if we go that way, I'd argue that
> > vscroll should be used regardless of the value of auto-window-vscroll.
> >
> 
> At the moment I'm a bit confused as to how auto-window-vscroll works right
> now. I might try to dig a bit deeper at some point, and put together a
> prototype of how I think it should work.

What do you mean by "how auto-window-vscroll works"?  If you mean how
its value is taken into account, look at line-move-partial.  If you
mean anything else, please ask.

bug#14598: 24.3; global-hl-line-mode + text-scale-adjust + next-line + scrolling

[E Sabof]

[-- Attachment #1: Type: text/plain, Size: 503 bytes --]

> > At the moment I'm a bit confused as to how auto-window-vscroll works
> right
> > now. I might try to dig a bit deeper at some point, and put together a
> > prototype of how I think it should work.
>
> What do you mean by "how auto-window-vscroll works"?  If you mean how
> its value is taken into account, look at line-move-partial.  If you
> mean anything else, please ask.
>

No, I've found the relevant source. I just want to test different
scenarios, and
see how it behaves in each one of them.

[-- Attachment #2: Type: text/html, Size: 840 bytes --]