GNU bug report logs - #72323
31.0.50; line-move unconditionally resets vscroll to 0

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 72323 in the body.
You can then email your comments to 72323 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Steven Allen <steven <at> stebalien.com>
To: bug-gnu-emacs <at> gnu.org
Cc: "Kim F. Storm" <storm <at> cua.dk>
Subject: 31.0.50; line-move unconditionally resets vscroll to 0
Date: Sat, 27 Jul 2024 10:57:44 -0700

Per the title, `line-move' unconditionally sets vscroll to 0:

    (set-window-vscroll nil 0 t)

Unfortunately, this causes several issues when using
`pixel-scroll-precision-mode':

1. Moving the cursor up/down, to the beginning of the line, or to the
end of the line resets vscroll causing the entire window to "jump".
2. It breaks `pixel-scroll-precision-mode' in Evil because
`evil-adjust-cursor' calls `move-end-of-line' internally. Whenever the
cursor is in a blank line, scrolling "sticks" unless you scroll fast
enough to scroll more than a partial line.

I'm submitting a patch to Evil to work around the second issue, but
having the entire window jump whenever I first move the cursor
up/down/end/home immediately after scrolling is still a bit annoying.

Fixing home/end (beginning of line, end of line) case seems trivial:
don't call `line-move' in these cases (or have `line-move' short-circuit
when `arg' is 0). However, even after reading all the comments about
scrolling images, I'm still not sure why it's necessary to reset vscroll
to 0. After commenting this line out, I can't tell a difference, even
when scrolling images with and without `auto-window-vscroll' and
`try-vscroll'. I was hoping Kim could shed some light on this.

In GNU Emacs 31.0.50 (build 1, x86_64-pc-linux-gnu, cairo version
 1.18.0) of 2024-07-24 built on Laptop
Repository revision: 2f5af5cab3869af426631735f12acf30798136bf
Repository branch: master
Windowing system distributor 'The X.Org Foundation', version 11.0.12101013
System Description: Arch Linux

Configured using:
 'configure --prefix=/usr --sysconfdir=/etc --libexecdir=/usr/lib
 --localstatedir=/var --mandir=/usr/share/man --with-gameuser=:games
 --with-modules --without-m17n-flt --without-selinux --without-pop
 --without-gconf --enable-link-time-optimization
 --with-native-compilation=yes --with-xinput2 --with-x-toolkit=no
 --without-toolkit-scroll-bars --without-xft --without-xaw3d
 --without-gsettings --with-cairo-xcb --with-sound=no --with-tree-sitter
 --without-gpm --without-compress-install
 '--program-transform-name=s/\([ec]tags\)/\1.emacs/'
 'CFLAGS=-march=native -mtune=native -O2 -pipe -fno-plt -fexceptions
 -Wp,-D_FORTIFY_SOURCE=3 -Wformat -Werror=format-security
 -fstack-clash-protection -fcf-protection -flto=auto' 'LDFLAGS=-Wl,-O1
 -Wl,--sort-common -Wl,--as-needed -Wl,-z,relro -Wl,-z,now
 -Wl,-z,pack-relative-relocs -Wl,-z,noexecstack -flto=auto''

Configured features:
ACL CAIRO DBUS FREETYPE GIF GLIB GMP GNUTLS HARFBUZZ JPEG LCMS2 LIBOTF
LIBSYSTEMD LIBXML2 MODULES NATIVE_COMP NOTIFY INOTIFY OLDXMENU PDUMPER
PNG RSVG SECCOMP SQLITE3 THREADS TIFF TREE_SITTER WEBP X11 XDBE XIM
XINPUT2 XPM ZLIB

Important settings:
  value of $LANG: en_US.UTF-8
  locale-coding-system: utf-8-unix

Major mode: notmuch-show

Minor modes in effect:
  notmuch-bookmarks-mode: t
  windmove-mode: t
  global-atomic-chrome-edit-mode: t
  i3bar-mode: t
  ednc-mode: t
  exwm-xsettings-mode: t
  exwm-background-mode: t
  exwm-systemtray-mode: t
  exwm-randr-mode: t
  visual-wrap-prefix-mode: t
  visual-fill-column-mode: t
  ligature-mode: t
  auto-compile-on-load-mode: t
  auto-compile-on-save-mode: t
  save-place-mode: t
  savehist-mode: t
  org-super-agenda-mode: t
  global-org-modern-mode: t
  eat-eshell-mode: t
  magit-todos-mode: t
  magit-wip-initial-backup-mode: t
  magit-wip-before-change-mode: t
  magit-wip-after-apply-mode: t
  magit-wip-after-save-mode: t
  magit-wip-mode: t
  global-git-commit-mode: t
  magit-auto-revert-mode: t
  server-mode: t
  recentf-mode: t
  global-treesit-auto-mode: t
  editorconfig-mode: t
  yas-global-mode: t
  yas-minor-mode: t
  async-bytecomp-package-mode: t
  sudo-edit-indicator-mode: t
  global-auto-revert-mode: t
  vertico-mode: t
  corfu-popupinfo-mode: t
  global-corfu-mode: t
  corfu-mode: t
  isearch-mb-mode: t
  pixel-scroll-precision-mode: t
  global-hl-todo-mode: t
  all-the-icons-completion-mode: t
  marginalia-mode: t
  global-form-feed-st-mode: t
  global-anzu-mode: t
  anzu-mode: t
  global-jinx-mode: t
  evil-goggles-mode: t
  global-evil-surround-mode: t
  evil-surround-mode: t
  global-evil-collection-unimpaired-mode: t
  evil-collection-unimpaired-mode: t
  evil-mode: t
  evil-local-mode: t
  desktop-environment-mode: t
  global-eldoc-mode: t
  show-paren-mode: t
  electric-indent-mode: t
  mouse-wheel-mode: t
  tab-bar-history-mode: t
  tab-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  window-divider-mode: t
  minibuffer-regexp-mode: t
  buffer-read-only: t
  column-number-mode: t
  line-number-mode: t
  visual-line-mode: t
  transient-mark-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t

Load-path shadows:
/home/steb/.cache/emacs/elpa/protobuf-mode-20240222.1652/protobuf-mode hides /usr/share/emacs/site-lisp/protobuf-mode
/home/steb/.cache/emacs/elpa/notmuch-20240725.1037/notmuch hides /usr/share/emacs/site-lisp/notmuch
/home/steb/.cache/emacs/elpa/notmuch-20240725.1037/notmuch-wash hides /usr/share/emacs/site-lisp/notmuch-wash
/home/steb/.cache/emacs/elpa/notmuch-20240725.1037/notmuch-tree hides /usr/share/emacs/site-lisp/notmuch-tree
/home/steb/.cache/emacs/elpa/notmuch-20240725.1037/notmuch-tag hides /usr/share/emacs/site-lisp/notmuch-tag
/home/steb/.cache/emacs/elpa/notmuch-20240725.1037/notmuch-show hides /usr/share/emacs/site-lisp/notmuch-show
/home/steb/.cache/emacs/elpa/notmuch-20240725.1037/notmuch-query hides /usr/share/emacs/site-lisp/notmuch-query
/home/steb/.cache/emacs/elpa/notmuch-20240725.1037/notmuch-print hides /usr/share/emacs/site-lisp/notmuch-print
/home/steb/.cache/emacs/elpa/notmuch-20240725.1037/notmuch-parser hides /usr/share/emacs/site-lisp/notmuch-parser
/home/steb/.cache/emacs/elpa/notmuch-20240725.1037/notmuch-mua hides /usr/share/emacs/site-lisp/notmuch-mua
/home/steb/.cache/emacs/elpa/notmuch-20240725.1037/notmuch-message hides /usr/share/emacs/site-lisp/notmuch-message
/home/steb/.cache/emacs/elpa/notmuch-20240725.1037/notmuch-maildir-fcc hides /usr/share/emacs/site-lisp/notmuch-maildir-fcc
/home/steb/.cache/emacs/elpa/notmuch-20240725.1037/notmuch-lib hides /usr/share/emacs/site-lisp/notmuch-lib
/home/steb/.cache/emacs/elpa/notmuch-20240725.1037/notmuch-jump hides /usr/share/emacs/site-lisp/notmuch-jump
/home/steb/.cache/emacs/elpa/notmuch-20240725.1037/notmuch-hello hides /usr/share/emacs/site-lisp/notmuch-hello
/home/steb/.cache/emacs/elpa/notmuch-20240725.1037/notmuch-draft hides /usr/share/emacs/site-lisp/notmuch-draft
/home/steb/.cache/emacs/elpa/notmuch-20240725.1037/notmuch-crypto hides /usr/share/emacs/site-lisp/notmuch-crypto
/home/steb/.cache/emacs/elpa/notmuch-20240725.1037/notmuch-compat hides /usr/share/emacs/site-lisp/notmuch-compat
/home/steb/.cache/emacs/elpa/notmuch-20240725.1037/notmuch-company hides /usr/share/emacs/site-lisp/notmuch-company
/home/steb/.cache/emacs/elpa/notmuch-20240725.1037/notmuch-address hides /usr/share/emacs/site-lisp/notmuch-address
/home/steb/.cache/emacs/elpa/notmuch-20240725.1037/coolj hides /usr/share/emacs/site-lisp/coolj
/home/steb/.cache/emacs/elpa/transient-20240713.2102/transient hides /usr/share/emacs/31.0.50/lisp/transient
/home/steb/.cache/emacs/elpa/modus-themes-20240227.715/theme-loaddefs hides /usr/share/emacs/31.0.50/lisp/theme-loaddefs

Features:
(shadow ecomplete sort mail-extr magit-patch emacsbug consult-info
emacsql-sqlite-builtin sqlite tramp-rclone tramp-fuse tramp-archive
tramp-gvfs semantic/symref/grep semantic/symref semantic/util-modes
semantic/util semantic semantic/tag semantic/lex semantic/fw cedet
hippie-exp textsec uni-scripts idna-mapping ucs-normalize uni-confusable
textsec-check evil-collection-embark embark-org embark-consult embark
ffap cc-awk cc-mode cc-fonts cc-guess cc-menus cc-cmds rng-xsd
xsd-regexp rng-cmpct rng-nxml rng-valid nxml-mode nxml-outln nxml-rap
flymake-ruff css-mode sgml-mode facemenu evil-collection-eww eww
url-queue shr pixel-fill kinsoku url-file mm-url evil-collection-gnus
gnus nnheader range bash-completion consult-xref checkdoc
package-lint-flymake package-lint evil-collection-finder finder lisp-mnt
tramp-cmds tabify app-launcher misearch multi-isearch vc-hg vc-bzr
vc-src vc-sccs vc-svn vc-cvs vc-rcs evil-collection-log-view log-view vc
buffer-move info-colors mule-util evil-collection-helpful helpful
cc-langs trace cl-print evil-collection-edebug edebug info-look help-fns
radix-tree evil-collection-elisp-refs elisp-refs evil-collection-eglot
eglot external-completion jsonrpc evil-collection-ert ert ewoc
evil-collection-debug debug backtrace rainbow-mode rainbow-delimiters
evil-collection-flymake flymake image-file image-converter
evil-collection-consult consult magit-bookmark org-bookmark-heading
notmuch-bookmarks evil-collection-bookmark bookmark windmove
eshell-syntax-highlighting evil-collection-vc-git vc-git vc-dispatcher
em-elecslash em-glob em-extpipe em-basic em-alias vertico-repeat
pinentry evil-collection-atomic-chrome atomic-chrome websocket bindat
i3bar ednc filechooser dbus exwm-xsettings xcb-xsettings exwm-background
exwm-systemtray xcb-systemtray xcb-xembed exwm-randr xcb-randr exwm
exwm-input xcb-keysyms xcb-xkb exwm-manage exwm-floating xcb-cursor
xcb-render exwm-layout exwm-workspace exwm-core xcb-ewmh xcb-icccm xcb
xcb-xproto xcb-types xcb-debug cus-start posframe visual-wrap face-remap
visual-fill-column ligature evil-org org-appear ws-butler oc-basic
bibtex ol-man ol-info ol-docview evil-collection-doc-view doc-view
jka-compr evil-collection-image image-mode exif auto-compile saveplace
savehist ready-player org-super-agenda ts ht org-habit org-crypt
org-protocol ob-http ob-http-mode org-modern ob-dot ob-latex ob-python
evil-collection-python python ob-gnuplot ox-odt rng-loc rng-uri
rng-parse rng-match rng-dt rng-util rng-pttrn nxml-parse nxml-ns
nxml-enc xmltok nxml-util ox-latex ox-icalendar evil-org-agenda
org-agenda ox-html table ox-ascii ox-publish ox org-element org-persist
org-id org-refile org-element-ast inline avl-tree ob-calc calc-store
calc-trail calc-ext evil-collection-calc calc calc-loaddefs calc-macs
ob-shell evil-collection-org org ob ob-tangle ob-ref ob-lob ob-table
ob-exp org-macro evil-collection-xref xref org-src
evil-collection-sh-script sh-script smie executable ob-comint
org-pcomplete org-list org-footnote org-faces org-entities ob-emacs-lisp
ob-core ob-eval org-cycle org-table ol org-fold org-fold-core org-keys
oc org-loaddefs org-compat org-version org-macs notmuch-addr
evil-collection-notmuch notmuch notmuch-tree notmuch-jump notmuch-hello
notmuch-show notmuch-print notmuch-crypto notmuch-mua notmuch-message
notmuch-draft notmuch-maildir-fcc notmuch-address notmuch-company
notmuch-parser notmuch-wash coolj goto-addr icalendar diary-lib
diary-loaddefs evil-collection-calendar cal-menu calendar cal-loaddefs
notmuch-tag notmuch-lib notmuch-compat mm-view mml-smime smime dig
eshell-prompt-extras em-dirs em-ls em-prompt em-hist em-unix em-pred
esh-mode esh-var evil-collection-eat eat evil-collection-term term
disp-table ehelp eshell esh-cmd generator esh-ext esh-proc esh-opt
esh-io esh-arg esh-module esh-module-loaddefs esh-util
evil-collection-forge forge-repos forge-tablist hl-line forge-topics
forge-commands forge-semi forge-bitbucket buck forge-gogs gogs
forge-gitea gtea forge-gitlab glab forge-github ghub-graphql treepy
gsexp ghub url-http url-gw nsm url-auth let-alist gnutls forge-notify
forge-revnote forge-pullreq forge-issue forge-topic yaml eieio-custom
bug-reference forge-post evil-collection-markdown-mode markdown-mode
edit-indirect evil-collection-outline noutline outline forge-repo forge
forge-core forge-db closql emacsql-sqlite-common emacsql
emacsql-compiler eieio-base evil-collection-magit-todos magit-todos
pcre2el rxt re-builder f s evil-collection-grep grep
evil-collection-compile compile evil-collection-magit magit-submodule
magit-blame magit-stash magit-reflog magit-bisect magit-push magit-pull
magit-fetch magit-clone magit-remote magit-commit magit-sequence
magit-notes magit-worktree magit-tag magit-merge magit-branch
magit-reset magit-files magit-refs magit-status magit
evil-collection-magit-repos magit-repos magit-apply magit-wip magit-log
which-func evil-collection-imenu imenu magit-diff smerge-mode diff
diff-mode track-changes git-commit evil-collection-log-edit log-edit
message sendmail yank-media puny evil-collection-dired dired
dired-loaddefs rfc822 mml mml-sec evil-collection-epa epa derived epg
rfc6068 epg-config gnus-util text-property-search mm-decode mm-bodies
mm-encode mail-parse rfc2231 rfc2047 rfc2045 mm-util ietf-drums
mail-prsvr mailabbrev mail-utils gmm-utils mailheader pcvs-util add-log
magit-core magit-autorevert magit-margin magit-transient magit-process
with-editor server magit-mode transient benchmark magit-git magit-base
evil-collection-magit-section magit-section cursor-sensor crm tramp-sh
recentf tree-widget easy-mmode treesit-auto editorconfig
editorconfig-core editorconfig-core-handle editorconfig-fnmatch
yasnippet async-bytecomp async sudo-edit tramp trampver
tramp-integration files-x tramp-message tramp-compat shell pcomplete
evil-collection-comint comint ansi-osc parse-time iso8601 time-date
format-spec ansi-color tramp-loaddefs autorevert filenotify project
vertico corfu-popupinfo evil-collection-corfu corfu orderless isearch-mb
pixel-scroll cua-base hl-todo all-the-icons-completion all-the-icons
all-the-icons-faces all-the-icons-data-material-icons
all-the-icons-data-fluentui-system-icons
all-the-icons-data-fontawesome-4 all-the-icons-data-weather-icons
all-the-icons-data-vscode-codicons all-the-icons-data-octicons
all-the-icons-data-mfixx all-the-icons-data-file-icons
all-the-icons-data-devopicons all-the-icons-data-alltheicons svg dom xml
marginalia form-feed-st anzu modus-vivendi-theme modus-themes jinx
evil-goggles pulse color evil-textobj-tree-sitter
evil-textobj-tree-sitter-thing-at-point evil-textobj-tree-sitter-core
treesit evil-args evil-surround evil-collection-unimpaired
evil-collection-tabulated-list evil-collection-tab-bar
evil-collection-simple evil-collection-replace
evil-collection-process-menu evil-collection-package-menu
evil-collection-kmacro evil-collection-info evil-collection-indent
evil-collection-help evil-collection-elisp-mode evil-collection-eldoc
evil-collection-custom evil-collection-buff-menu evil-collection
annalist evil evil-integration evil-maps evil-commands evil-digraphs
pcase reveal evil-jumps evil-command-window evil-types evil-search
evil-ex evil-macros evil-repeat evil-states evil-core comp-run advice
evil-common thingatpt rect evil-vars ring edmacro kmacro general dash
mode-local find-func no-littering compat finder-inf notmuch-version info
all-the-icons-completion-autoloads all-the-icons-dired-autoloads
all-the-icons-ibuffer-autoloads all-the-icons-autoloads
app-launcher-autoloads aria2-autoloads atomic-chrome-autoloads
auto-compile-autoloads bash-completion-autoloads bluetooth-autoloads
buffer-move-autoloads calibre-autoloads cape-autoloads
casual-calc-autoloads casual-dired-autoloads casual-ibuffer-autoloads
casual-info-autoloads casual-lib-autoloads clojure-mode-autoloads
comint-mime-autoloads consult-eglot-autoloads
consult-project-extra-autoloads corfu-autoloads coverage-autoloads
csv-mode-autoloads dape-autoloads devdocs-autoloads
dired-filter-autoloads dired-hacks-utils-autoloads dired-k-autoloads
discomfort-autoloads debase-autoloads disk-usage-autoloads eat-autoloads
edit-indirect-autoloads ednc-autoloads eff-autoloads ellama-autoloads
embark-consult-autoloads consult-autoloads embark-autoloads
ement-autoloads eshell-prompt-extras-autoloads
eshell-syntax-highlighting-autoloads evil-anzu-autoloads anzu-autoloads
evil-args-autoloads evil-collection-autoloads annalist-autoloads
evil-goggles-autoloads evil-nerd-commenter-autoloads evil-org-autoloads
evil-surround-autoloads evil-textobj-tree-sitter-autoloads
evm-mode-autoloads expand-region-autoloads exwm-autoloads
filechooser-autoloads flymake-ruff-autoloads form-feed-st-autoloads
general-autoloads git-link-autoloads git-modes-autoloads
gnuplot-autoloads graphviz-dot-mode-autoloads helpful-autoloads
elisp-refs-autoloads htmlize-autoloads i3bar-autoloads igist-autoloads
info-colors-autoloads isearch-mb-autoloads iwindow-autoloads
jinx-autoloads journalctl-autoloads kotlin-mode-autoloads
kubernetes-evil-autoloads evil-autoloads goto-chg-autoloads
kubernetes-autoloads ligature-autoloads link-hint-autoloads
avy-autoloads llm-autoloads magit-popup-autoloads magit-todos-autoloads
hl-todo-autoloads f-autoloads marginalia-autoloads mastodon-autoloads
microdata-autoloads modus-themes-autoloads named-pipe-autoloads
nftables-mode-autoloads no-littering-autoloads notmuch-addr-autoloads
notmuch-transient-autoloads nov-autoloads esxml-autoloads kv-autoloads
ob-async-autoloads ob-http-autoloads ol-notmuch-autoloads
notmuch-autoloads orderless-autoloads org-appear-autoloads
org-bookmark-heading-autoloads org-download-autoloads async-autoloads
org-modern-autoloads org-super-agenda-autoloads orgit-forge-autoloads
orgit-autoloads forge-autoloads markdown-mode-autoloads magit-autoloads
git-commit-autoloads ghub-autoloads closql-autoloads emacsql-autoloads
ox-pandoc-autoloads ht-autoloads package-lint-flymake-autoloads
package-lint-autoloads password-store-autoloads pcre2el-autoloads
pdf-tools-autoloads persist-autoloads pinentry-autoloads
pkgbuild-mode-autoloads playerctl-autoloads plz-autoloads
posframe-autoloads proced-narrow-autoloads protobuf-mode-autoloads
pulseaudio-control-autoloads qrencode-autoloads
rainbow-delimiters-autoloads rainbow-mode-autoloads
ready-player-autoloads request-autoloads rg-autoloads rmsbolt-autoloads
rust-playground-autoloads snapshot-timemachine-autoloads
solidity-mode-autoloads spinner-autoloads ssh-config-mode-autoloads
sudo-edit-autoloads svg-lib-autoloads syncthing-autoloads
systemctl-autoloads systemd-autoloads tablist-autoloads
taxy-magit-section-autoloads taxy-autoloads magit-section-autoloads
tmr-autoloads transient-autoloads treepy-autoloads
treesit-auto-autoloads ts-autoloads s-autoloads dash-autoloads
tzc-autoloads udev-mode-autoloads vala-mode-autoloads cc-styles cc-align
cc-engine cc-vars cc-defs vertico-autoloads vimrc-mode-autoloads
visual-fill-column-autoloads vundo-autoloads wat-ts-mode-autoloads
watch-autoloads web-mode-autoloads websocket-autoloads wgrep-autoloads
whisper-autoloads with-editor-autoloads wordnut-autoloads
ws-butler-autoloads xelb-autoloads yaml-autoloads yasnippet-autoloads
comp comp-cstr cl-extra help-mode comp-common warnings rx xdg package
browse-url url url-proxy url-privacy url-expand url-methods url-history
url-cookie generate-lisp-file url-domsuf url-util mailcap url-handlers
url-parse auth-source cl-seq eieio eieio-core cl-macs password-cache
json subr-x map byte-opt gv bytecomp byte-compile url-vars cus-edit pp
cus-load icons wid-edit cl-loaddefs cl-lib rmc iso-transl tooltip cconv
eldoc paren electric uniquify ediff-hook vc-hooks lisp-float-type
elisp-mode mwheel term/x-win x-win term/common-win x-dnd touch-screen
tool-bar dnd fontset image regexp-opt fringe tabulated-list replace
newcomment text-mode lisp-mode prog-mode register page tab-bar menu-bar
rfn-eshadow isearch easymenu timer select scroll-bar mouse jit-lock
font-lock syntax font-core term/tty-colors frame minibuffer nadvice seq
simple cl-generic indonesian philippine cham georgian utf-8-lang
misc-lang vietnamese tibetan thai tai-viet lao korean japanese eucjp-ms
cp51932 hebrew greek romanian slovak czech european ethiopic indian
cyrillic chinese composite emoji-zwj charscript charprop case-table
epa-hook jka-cmpr-hook help abbrev obarray oclosure cl-preloaded button
loaddefs theme-loaddefs faces cus-face macroexp files window
text-properties overlay sha1 md5 base64 format env code-pages mule
custom widget keymap hashtable-print-readable backquote threads dbusbind
inotify lcms2 dynamic-setting font-render-setting cairo xinput2 x
multi-tty move-toolbar make-network-process native-compile emacs)

Memory information:
((conses 16 3220055 2243012) (symbols 48 103120 166) (strings 32 562693 102722)
 (string-bytes 1 18216704) (vectors 16 196012) (vector-slots 8 3208841 1034054) (floats 8 960 11509)
 (intervals 56 146966 72829) (buffers 992 72))

Message #8 received at 72323 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Steven Allen <steven <at> stebalien.com>
Cc: 72323 <at> debbugs.gnu.org, storm <at> cua.dk
Subject: Re: bug#72323: 31.0.50; line-move unconditionally resets vscroll to 0
Date: Sat, 27 Jul 2024 21:11:21 +0300

> Cc: "Kim F. Storm" <storm <at> cua.dk>
> Date: Sat, 27 Jul 2024 10:57:44 -0700
> From:  Steven Allen via "Bug reports for GNU Emacs,
>  the Swiss army knife of text editors" <bug-gnu-emacs <at> gnu.org>
> 
> Fixing home/end (beginning of line, end of line) case seems trivial:
> don't call `line-move' in these cases (or have `line-move' short-circuit
> when `arg' is 0). However, even after reading all the comments about
> scrolling images, I'm still not sure why it's necessary to reset vscroll
> to 0.

Because otherwise what line-move does cannot be described in sensible
terms.  If vscroll is not reset, then what would be the reference for
such a "line move"?  By its very definition, line-move moves N screen
lines wrt the line which was its starting point, but with vscroll
non-zero that starting point could be anywhere.

In addition, when we move to another screen line, the value of vscroll
cannot be meaningfully kept, because its meaning is tightly coupled to
the screen line where it was applied.  In essence, vscroll is a trick
to allow display of a tall display element (image, text using a large
fonts, etc.) in a window whose height is too small to show all of the
display element at once.

> After commenting this line out, I can't tell a difference, even
> when scrolling images with and without `auto-window-vscroll' and
> `try-vscroll'.

line-move is not just for scrolling across images, it is also about
scrolling across tall text lines and other display elements.  In any
case, asking for removal of that reset is a non-starter, for the
reasons explained above, so it isn't going to happen.  The solution
for any Lisp program that doesn't want vscroll to be rest is not to
call line-move.

> I was hoping Kim could shed some light on this.

I'd be thrilled to hear from Kim, but I'm as guilty of the code in
line-move as he is, so "blame" me if you want.

Message #11 received at 72323 <at> debbugs.gnu.org (full text, mbox):

From: Steven Allen <steven <at> stebalien.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 72323 <at> debbugs.gnu.org, storm <at> cua.dk
Subject: Re: bug#72323: 31.0.50; line-move unconditionally resets vscroll to 0
Date: Sat, 27 Jul 2024 13:10:03 -0700

[Message part 1 (text/plain, inline)]

Eli Zaretskii <eliz <at> gnu.org> writes:

>> Cc: "Kim F. Storm" <storm <at> cua.dk>
>> Date: Sat, 27 Jul 2024 10:57:44 -0700
>> From:  Steven Allen via "Bug reports for GNU Emacs,
>>  the Swiss army knife of text editors" <bug-gnu-emacs <at> gnu.org>
>> 
>> Fixing home/end (beginning of line, end of line) case seems trivial:
>> don't call `line-move' in these cases (or have `line-move' short-circuit
>> when `arg' is 0). However, even after reading all the comments about
>> scrolling images, I'm still not sure why it's necessary to reset vscroll
>> to 0.
>
> Because otherwise what line-move does cannot be described in sensible
> terms.  If vscroll is not reset, then what would be the reference for
> such a "line move"?  By its very definition, line-move moves N screen
> lines wrt the line which was its starting point, but with vscroll
> non-zero that starting point could be anywhere.

I'm a bit confused because vscroll is about scrolling the window and
`line-move' is about moving point (only incidentally scrolling the
window if the point leaves it). Clearly `set-window-start' needs to
reset `vscroll', but I'm not sure I understand why `line-move' does.

Is this about detecting the correct column?

> In addition, when we move to another screen line, the value of vscroll
> cannot be meaningfully kept, because its meaning is tightly coupled to
> the screen line where it was applied.  In essence, vscroll is a trick
> to allow display of a tall display element (image, text using a large
> fonts, etc.) in a window whose height is too small to show all of the
> display element at once.
>
>> After commenting this line out, I can't tell a difference, even
>> when scrolling images with and without `auto-window-vscroll' and
>> `try-vscroll'.
>
> line-move is not just for scrolling across images, it is also about
> scrolling across tall text lines and other display elements.  In any
> case, asking for removal of that reset is a non-starter, for the
> reasons explained above, so it isn't going to happen.  The solution
> for any Lisp program that doesn't want vscroll to be rest is not to
> call line-move.

Now that I do more testing, I can see how removing that line breaks
`line-move' although I'm still not sure why.

Would it be acceptable to restore the vertical scroll position as long
as `line-move' hasn't otherwise scrolled the screen? See attached patch.

>> I was hoping Kim could shed some light on this.
>
> I'd be thrilled to hear from Kim, but I'm as guilty of the code in
> line-move as he is, so "blame" me if you want.

Ah, sorry, should have gone back further in the blame history.

[0001-Restore-vertical-scroll-offset-after-line-move.patch (text/x-patch, inline)]

From 2f028e30b2e5ba3a3cd9fd2ecaeaff7c3d02b62f Mon Sep 17 00:00:00 2001
From: Steven Allen <steven <at> stebalien.com>
Date: Sat, 27 Jul 2024 12:54:31 -0700
Subject: [PATCH] Restore vertical-scroll offset after line-move

Restore the vertical-scroll offset after moving lines unless the window
was otherwise scrolled and/or altering the vertical scroll would move
the point off-screen.

* lisp/simple.el (line-move): restore `window-vscroll' when
appropriate (Bug#72323).
---
 lisp/simple.el | 85 ++++++++++++++++++++++++++++----------------------
 1 file changed, 48 insertions(+), 37 deletions(-)

diff --git a/lisp/simple.el b/lisp/simple.el
index a9f8b5845d8..71ae175d198 100644
--- a/lisp/simple.el
+++ b/lisp/simple.el
@@ -7930,43 +7930,54 @@ line-move
                    ;; doesn't have very long lines.
                    (long-line-optimizations-p)))
 		 (line-move-partial arg noerror))
-      (set-window-vscroll nil 0 t)
-      (if (and line-move-visual
-	       ;; Display-based column are incompatible with goal-column.
-	       (not goal-column)
-               ;; Lines aren't truncated.
-               (not
-                (and
-                 (or truncate-lines (truncated-partial-width-window-p))
-                 (long-line-optimizations-p)))
-	       ;; When the text in the window is scrolled to the left,
-	       ;; display-based motion doesn't make sense (because each
-	       ;; logical line occupies exactly one screen line).
-	       (not (> (window-hscroll) 0))
-	       ;; Likewise when the text _was_ scrolled to the left
-	       ;; when the current run of vertical motion commands
-	       ;; started.
-	       (not (and (memq last-command
-			       `(next-line previous-line ,this-command))
-			 auto-hscroll-mode
-			 (numberp temporary-goal-column)
-			 (>= temporary-goal-column
-			    (- (window-width) hscroll-margin)))))
-	  (prog1 (line-move-visual arg noerror)
-	    ;; If we moved into a tall line, set vscroll to make
-	    ;; scrolling through tall images more smooth.
-	    (let ((lh (line-pixel-height))
-		  (edges (window-inside-pixel-edges))
-		  (dlh (default-line-height))
-		  winh)
-	      (setq winh (- (nth 3 edges) (nth 1 edges) 1))
-	      (if (and (< arg 0)
-		       (< (point) (window-start))
-		       (> lh winh))
-		  (set-window-vscroll
-		   nil
-		   (- lh dlh) t))))
-	(line-move-1 arg noerror)))))
+      (let ((initial-vscroll (window-vscroll nil t))
+            (initial-window-start (window-start)))
+            (set-window-vscroll nil 0 t)
+            (prog1
+                (if (and line-move-visual
+                         ;; Display-based column are incompatible with goal-column.
+                         (not goal-column)
+                         ;; Lines aren't truncated.
+                         (not
+                          (and
+                           (or truncate-lines (truncated-partial-width-window-p))
+                           (long-line-optimizations-p)))
+                         ;; When the text in the window is scrolled to the left,
+                         ;; display-based motion doesn't make sense (because each
+                         ;; logical line occupies exactly one screen line).
+                         (not (> (window-hscroll) 0))
+                         ;; Likewise when the text _was_ scrolled to the left
+                         ;; when the current run of vertical motion commands
+                         ;; started.
+                         (not (and (memq last-command
+                                         `(next-line previous-line ,this-command))
+                                   auto-hscroll-mode
+                                   (numberp temporary-goal-column)
+                                   (>= temporary-goal-column
+                                       (- (window-width) hscroll-margin)))))
+                    (prog1 (line-move-visual arg noerror)
+                      ;; If we moved into a tall line, set vscroll to make
+                      ;; scrolling through tall images more smooth.
+                      (let ((lh (line-pixel-height))
+                            (edges (window-inside-pixel-edges))
+                            (dlh (default-line-height))
+                            winh)
+                        (setq winh (- (nth 3 edges) (nth 1 edges) 1))
+                        (if (and (< arg 0)
+                                 (< (point) (window-start))
+                                 (> lh winh))
+                            (set-window-vscroll
+                             nil
+                             (- lh dlh) t))))
+                  (line-move-1 arg noerror))
+              ;; Restore the vscroll position, if any.
+              (when (and (not (zerop initial-vscroll))
+                         ;; But not if scrolling would hide the point.
+                         (< initial-vscroll (cdr (posn-x-y (posn-at-point))))
+                         ;; Or if line-move otherwise scrolled the window.
+                         (= initial-window-start (window-start))
+                         (zerop (window-vscroll nil t)))
+                (set-window-vscroll nil initial-vscroll t)))))))
 
 ;; Display-based alternative to line-move-1.
 ;; Arg says how many lines to move.  The value is t if we can move the
-- 
2.45.2

Message #14 received at 72323 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Steven Allen <steven <at> stebalien.com>, Po Lu <luangruo <at> yahoo.com>
Cc: 72323 <at> debbugs.gnu.org, storm <at> cua.dk
Subject: Re: bug#72323: 31.0.50; line-move unconditionally resets vscroll to 0
Date: Sun, 28 Jul 2024 07:50:57 +0300

> From: Steven Allen <steven <at> stebalien.com>
> Cc: 72323 <at> debbugs.gnu.org, storm <at> cua.dk
> Date: Sat, 27 Jul 2024 13:10:03 -0700
> 
> >> Fixing home/end (beginning of line, end of line) case seems trivial:
> >> don't call `line-move' in these cases (or have `line-move' short-circuit
> >> when `arg' is 0). However, even after reading all the comments about
> >> scrolling images, I'm still not sure why it's necessary to reset vscroll
> >> to 0.
> >
> > Because otherwise what line-move does cannot be described in sensible
> > terms.  If vscroll is not reset, then what would be the reference for
> > such a "line move"?  By its very definition, line-move moves N screen
> > lines wrt the line which was its starting point, but with vscroll
> > non-zero that starting point could be anywhere.
> 
> I'm a bit confused because vscroll is about scrolling the window and
> `line-move' is about moving point (only incidentally scrolling the
> window if the point leaves it). Clearly `set-window-start' needs to
> reset `vscroll', but I'm not sure I understand why `line-move' does.

vscroll is not just about scrolling the window.  It is basically a
vertical offset from the screen line that shows window-start to the
top-most pixel shown in the window.  It is meant to enable to see the
tall screen line at window-start in its entirety.  Once point moves
off that screen line, vscroll is no longer pertinent, since the
important line, for which vscroll has been determined, has changed.
For example, imagine that the line into which point moves cannot be
displayed in its entirety with this vscroll, because it starts at a
different vertical coordinate (so its lower part could be below the
window bottom).

> Is this about detecting the correct column?

No, I don't think columns are related.

> > line-move is not just for scrolling across images, it is also about
> > scrolling across tall text lines and other display elements.  In any
> > case, asking for removal of that reset is a non-starter, for the
> > reasons explained above, so it isn't going to happen.  The solution
> > for any Lisp program that doesn't want vscroll to be rest is not to
> > call line-move.
> 
> Now that I do more testing, I can see how removing that line breaks
> `line-move' although I'm still not sure why.
> 
> Would it be acceptable to restore the vertical scroll position as long
> as `line-move' hasn't otherwise scrolled the screen? See attached patch.

Sorry, I don't want to make changes in that function whose purpose is
to serve use cases which this function is not designed to support.
The code there is quite fragile and it needs to support a large number
of use cases, some of which with subtle aspects (e.g., did you try
line truncation? did you try visual-line-mode? etc.).  In addition,
the code there is too tightly-coupled with code in the related
functions: line-move-1, line-move-partial, and line-move-finish.  They
all work in unison to support the various use cases, and changing one
without the others is very risky.  It took us a long time to arrive at
what we have there, solving quite a few bugs as we went.  Making
significant changes that at this point in support of application-level
issues would be unimaginable from where I stand.

Problems with pixel-scroll-precision-mode should be solved in that
mode.  I'm against modifying line-move and related subroutines in
order to solve problems in Lisp programs that are not bugs in the
algorithm of line-move.

I've added Po Lu to this discussion in the hope that he could have
comments and suggestions for solving the problems in
pixel-scroll-precision-mode you mentioned in the original message.

Message #17 received at 72323 <at> debbugs.gnu.org (full text, mbox):

From: Steven Allen <steven <at> stebalien.com>
To: Eli Zaretskii <eliz <at> gnu.org>, Po Lu <luangruo <at> yahoo.com>
Cc: 72323 <at> debbugs.gnu.org, storm <at> cua.dk
Subject: Re: bug#72323: 31.0.50; line-move unconditionally resets vscroll to 0
Date: Sun, 28 Jul 2024 13:07:09 -0700

Eli Zaretskii <eliz <at> gnu.org> writes:

>> From: Steven Allen <steven <at> stebalien.com>
>> Cc: 72323 <at> debbugs.gnu.org, storm <at> cua.dk
>> Date: Sat, 27 Jul 2024 13:10:03 -0700
>> 
>> >> Fixing home/end (beginning of line, end of line) case seems trivial:
>> >> don't call `line-move' in these cases (or have `line-move' short-circuit
>> >> when `arg' is 0). However, even after reading all the comments about
>> >> scrolling images, I'm still not sure why it's necessary to reset vscroll
>> >> to 0.
>> >
>> > Because otherwise what line-move does cannot be described in sensible
>> > terms.  If vscroll is not reset, then what would be the reference for
>> > such a "line move"?  By its very definition, line-move moves N screen
>> > lines wrt the line which was its starting point, but with vscroll
>> > non-zero that starting point could be anywhere.
>> 
>> I'm a bit confused because vscroll is about scrolling the window and
>> `line-move' is about moving point (only incidentally scrolling the
>> window if the point leaves it). Clearly `set-window-start' needs to
>> reset `vscroll', but I'm not sure I understand why `line-move' does.
>
> vscroll is not just about scrolling the window.  It is basically a
> vertical offset from the screen line that shows window-start to the
> top-most pixel shown in the window.  It is meant to enable to see the
> tall screen line at window-start in its entirety.  Once point moves
> off that screen line, vscroll is no longer pertinent, since the
> important line, for which vscroll has been determined, has changed.
> For example, imagine that the line into which point moves cannot be
> displayed in its entirety with this vscroll, because it starts at a
> different vertical coordinate (so its lower part could be below the
> window bottom).

No? E.g., if I have half a line (or half an image) visible and move my
point off that line, I wouldn't expect that line to suddenly scroll out
of view _unless_ the entire screen needs to scroll because the
text/image is larger than the entire screen.

>> Is this about detecting the correct column?
>
> No, I don't think columns are related.
>
>> > line-move is not just for scrolling across images, it is also about
>> > scrolling across tall text lines and other display elements.  In any
>> > case, asking for removal of that reset is a non-starter, for the
>> > reasons explained above, so it isn't going to happen.  The solution
>> > for any Lisp program that doesn't want vscroll to be rest is not to
>> > call line-move.
>> 
>> Now that I do more testing, I can see how removing that line breaks
>> `line-move' although I'm still not sure why.
>> 
>> Would it be acceptable to restore the vertical scroll position as long
>> as `line-move' hasn't otherwise scrolled the screen? See attached patch.
>
> Sorry, I don't want to make changes in that function whose purpose is
> to serve use cases which this function is not designed to support.
> The code there is quite fragile and it needs to support a large number
> of use cases, some of which with subtle aspects (e.g., did you try
> line truncation? did you try visual-line-mode? etc.).  In addition,
> the code there is too tightly-coupled with code in the related
> functions: line-move-1, line-move-partial, and line-move-finish.  They
> all work in unison to support the various use cases, and changing one
> without the others is very risky.  It took us a long time to arrive at
> what we have there, solving quite a few bugs as we went.  Making
> significant changes that at this point in support of application-level
> issues would be unimaginable from where I stand.

I'm not sure how visual-line-mode and/or truncation might be affected, I
tried both and they seemed to work. All this patch does is restore the
vertical scroll position after moving point (`line-move' is, first and
foremost, a function to move point).

> Problems with pixel-scroll-precision-mode should be solved in that
> mode.  I'm against modifying line-move and related subroutines in
> order to solve problems in Lisp programs that are not bugs in the
> algorithm of line-move.

It sounds like vscroll may not have been intended to be used this way,
but (a) it's now used this way by a package shipped with Emacs and (b)
smooth pixel-scrolling is a feature expected of all modern GUIs. It
would be a pity to have a half-broken implementation.

The only options I can see for `pixel-scroll-precision-mode' are:

1. Advising `line-move' to restore the vertical scroll position.
2. Forcibly aligning the vertical scroll on touch end (which kind of
defeats the point of the mode).
3. Leaving things as-is and accepting that the window will scroll a bit
when the user calls a command that eventually calls `line-move'.

None of these options are acceptable, in my opinion.

> I've added Po Lu to this discussion in the hope that he could have
> comments and suggestions for solving the problems in
> pixel-scroll-precision-mode you mentioned in the original message.

See the comment above that function:

;; This is like line-move-1 except that it also performs
;; vertical scrolling of tall images if appropriate.
;; That is not really a clean thing to do, since it mixes
;; scrolling with cursor motion.  But so far we don't have
;; a cleaner solution to the problem of making C-n do something
;; useful given a tall image.

This function is very clearly about cursor motion, not scrolling, and
shouldn't mess with the current scroll position.

Message #20 received at 72323 <at> debbugs.gnu.org (full text, mbox):

From: Steven Allen <steven <at> stebalien.com>
To: Eli Zaretskii <eliz <at> gnu.org>, Po Lu <luangruo <at> yahoo.com>
Cc: 72323 <at> debbugs.gnu.org, storm <at> cua.dk
Subject: Re: bug#72323: 31.0.50; line-move unconditionally resets vscroll to 0
Date: Sun, 28 Jul 2024 13:10:55 -0700

To be clear, I'm not particularly happy with my solution of restoring
vscroll as it does feel rather hacky. I'd rather avoid altering vscroll
at all, but I wanted to demonstrate that there's nothing inherent
unsolvable about this issue.

Message #23 received at 72323 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Steven Allen <steven <at> stebalien.com>
Cc: luangruo <at> yahoo.com, 72323 <at> debbugs.gnu.org, storm <at> cua.dk
Subject: Re: bug#72323: 31.0.50; line-move unconditionally resets vscroll to 0
Date: Mon, 29 Jul 2024 14:12:23 +0300

> From: Steven Allen <steven <at> stebalien.com>
> Cc: 72323 <at> debbugs.gnu.org, storm <at> cua.dk
> Date: Sun, 28 Jul 2024 13:07:09 -0700
> 
> Eli Zaretskii <eliz <at> gnu.org> writes:
> 
> > vscroll is not just about scrolling the window.  It is basically a
> > vertical offset from the screen line that shows window-start to the
> > top-most pixel shown in the window.  It is meant to enable to see the
> > tall screen line at window-start in its entirety.  Once point moves
> > off that screen line, vscroll is no longer pertinent, since the
> > important line, for which vscroll has been determined, has changed.
> > For example, imagine that the line into which point moves cannot be
> > displayed in its entirety with this vscroll, because it starts at a
> > different vertical coordinate (so its lower part could be below the
> > window bottom).
> 
> No? E.g., if I have half a line (or half an image) visible and move my
> point off that line, I wouldn't expect that line to suddenly scroll out
> of view _unless_ the entire screen needs to scroll because the
> text/image is larger than the entire screen.

It depends on the details of the line from which you move cursor and
the one into which you move.  For example, if the former takes up
almost the entire window, then moving into the next one could cause
that next line to be only partially visible, and that is unacceptable
for the Emacs redisplay.

Once again: the vscroll value is pertinent only for the screen line
for which it was computed, because the way it is computed uses the
metrics of that line.  Once you move to another line, the value is no
longer pertinent.

> > Sorry, I don't want to make changes in that function whose purpose is
> > to serve use cases which this function is not designed to support.
> > The code there is quite fragile and it needs to support a large number
> > of use cases, some of which with subtle aspects (e.g., did you try
> > line truncation? did you try visual-line-mode? etc.).  In addition,
> > the code there is too tightly-coupled with code in the related
> > functions: line-move-1, line-move-partial, and line-move-finish.  They
> > all work in unison to support the various use cases, and changing one
> > without the others is very risky.  It took us a long time to arrive at
> > what we have there, solving quite a few bugs as we went.  Making
> > significant changes that at this point in support of application-level
> > issues would be unimaginable from where I stand.
> 
> I'm not sure how visual-line-mode and/or truncation might be affected

They are relevant because the workhorse of vertical cursor movement is
vertical-motion, which needs special handling for each of these (and
other) use cases.  The fundamental reason is that each of these
features affects the layout of physical lines differently.

> I tried both and they seemed to work.

I believe you.  But I have too much gray hair from changes there that
then cause subtle problems in rare enough cases.

> > Problems with pixel-scroll-precision-mode should be solved in that
> > mode.  I'm against modifying line-move and related subroutines in
> > order to solve problems in Lisp programs that are not bugs in the
> > algorithm of line-move.
> 
> It sounds like vscroll may not have been intended to be used this way,
> but (a) it's now used this way by a package shipped with Emacs and (b)
> smooth pixel-scrolling is a feature expected of all modern GUIs. It
> would be a pity to have a half-broken implementation.

Emacs supports smooth scrolling only within a single screen line, and
that uses vscroll.  That's the original design intent of vscroll.
Smooth scrolling between lines is not really supported.
pixel-scrolling attempts to solve that, and does it well, but it does
have some problematic corners.  Those corners need to be solved inside
pixel-scroll code.

> 1. Advising `line-move' to restore the vertical scroll position.

That's not necessary.  If someone can come up with a version of
line-move that is specific to pixel-scroll, we can always call it
instead of line-move when pixel-scroll is in effect.

> 2. Forcibly aligning the vertical scroll on touch end (which kind of
> defeats the point of the mode).
> 3. Leaving things as-is and accepting that the window will scroll a bit
> when the user calls a command that eventually calls `line-move'.
> 
> None of these options are acceptable, in my opinion.

I don't understand the latter two alternatives, but the first one
should show a way of fixing these issues without affecting all the
users of line-move.

> > I've added Po Lu to this discussion in the hope that he could have
> > comments and suggestions for solving the problems in
> > pixel-scroll-precision-mode you mentioned in the original message.
> 
> See the comment above that function:
> 
> ;; This is like line-move-1 except that it also performs
> ;; vertical scrolling of tall images if appropriate.
> ;; That is not really a clean thing to do, since it mixes
> ;; scrolling with cursor motion.  But so far we don't have
> ;; a cleaner solution to the problem of making C-n do something
> ;; useful given a tall image.
> 
> This function is very clearly about cursor motion, not scrolling, and
> shouldn't mess with the current scroll position.

Po Lu will tell, but my understanding of the comment is that it does
what it does out of necessity.

Message #26 received at 72323 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Steven Allen <steven <at> stebalien.com>
Cc: luangruo <at> yahoo.com, 72323 <at> debbugs.gnu.org, storm <at> cua.dk
Subject: Re: bug#72323: 31.0.50; line-move unconditionally resets vscroll to 0
Date: Mon, 29 Jul 2024 14:14:40 +0300

> From: Steven Allen <steven <at> stebalien.com>
> Cc: 72323 <at> debbugs.gnu.org, storm <at> cua.dk
> Date: Sun, 28 Jul 2024 13:10:55 -0700
> 
> 
> To be clear, I'm not particularly happy with my solution of restoring
> vscroll as it does feel rather hacky. I'd rather avoid altering vscroll
> at all, but I wanted to demonstrate that there's nothing inherent
> unsolvable about this issue.

I never said this cannot be solved.  I'm quite sure it can be.  I only
object to significant changes in line-move to solve that.  With all
dues respect to pixel-scroll-precision-mode, it is a minor feature, so
making such low-level changes to cater to it is IMO tantamount to the
tail wagging the dog.

Message #29 received at 72323 <at> debbugs.gnu.org (full text, mbox):

From: Po Lu <luangruo <at> yahoo.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 72323 <at> debbugs.gnu.org, Steven Allen <steven <at> stebalien.com>, storm <at> cua.dk
Subject: Re: bug#72323: 31.0.50; line-move unconditionally resets vscroll to 0
Date: Mon, 29 Jul 2024 22:30:50 +0800

Eli Zaretskii <eliz <at> gnu.org> writes:

>> This function is very clearly about cursor motion, not scrolling, and
>> shouldn't mess with the current scroll position.
>
> Po Lu will tell, but my understanding of the comment is that it does
> what it does out of necessity.

I don't understand why it is inherently improper that line motion
commands should reset vscroll, which is never set to a large value by
precision scrolling.

Message #32 received at 72323 <at> debbugs.gnu.org (full text, mbox):

From: Steven Allen <steven <at> stebalien.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: luangruo <at> yahoo.com, 72323 <at> debbugs.gnu.org, storm <at> cua.dk
Subject: Re: bug#72323: 31.0.50; line-move unconditionally resets vscroll to 0
Date: Sun, 18 Aug 2024 10:38:29 -0700

Eli Zaretskii <eliz <at> gnu.org> writes:

>> From: Steven Allen <steven <at> stebalien.com>
>> Cc: 72323 <at> debbugs.gnu.org, storm <at> cua.dk
>> Date: Sun, 28 Jul 2024 13:07:09 -0700
>> 
>> Eli Zaretskii <eliz <at> gnu.org> writes:
>> 
>> > vscroll is not just about scrolling the window.  It is basically a
>> > vertical offset from the screen line that shows window-start to the
>> > top-most pixel shown in the window.  It is meant to enable to see the
>> > tall screen line at window-start in its entirety.  Once point moves
>> > off that screen line, vscroll is no longer pertinent, since the
>> > important line, for which vscroll has been determined, has changed.
>> > For example, imagine that the line into which point moves cannot be
>> > displayed in its entirety with this vscroll, because it starts at a
>> > different vertical coordinate (so its lower part could be below the
>> > window bottom).
>> 
>> No? E.g., if I have half a line (or half an image) visible and move my
>> point off that line, I wouldn't expect that line to suddenly scroll out
>> of view _unless_ the entire screen needs to scroll because the
>> text/image is larger than the entire screen.
>
> It depends on the details of the line from which you move cursor and
> the one into which you move.  For example, if the former takes up
> almost the entire window, then moving into the next one could cause
> that next line to be only partially visible, and that is unacceptable
> for the Emacs redisplay.

In that case I completely agree. If point moves to a partially displayed
line, vscroll needs to be adjusted and/or reset.

> Once again: the vscroll value is pertinent only for the screen line
> for which it was computed, because the way it is computed uses the
> metrics of that line.  Once you move to another line, the value is no
> longer pertinent.

Let's be precise about "move to another line":

- When window-start changes, vscroll becomes invalid because the lines at
  the top of the screen (to which vscroll applies) has changed. I agree
  that it must be reset in this case.
- When point is moved up and down in such a way that window-start isn't
  changed, vscroll is still perfectly valid as the top line in the
  window hasn't changed. vscroll is relative to the top line, not point.

> Emacs supports smooth scrolling only within a single screen line, and
> that uses vscroll.  That's the original design intent of vscroll.
> Smooth scrolling between lines is not really supported.
> pixel-scrolling attempts to solve that, and does it well, but it does
> have some problematic corners.  Those corners need to be solved inside
> pixel-scroll code.

Honestly, scrolling between lines is working perfectly. I'm not running
into issues when scrolling, I'm running into issues when changing lines
after partially scrolling a line.

Message #35 received at 72323 <at> debbugs.gnu.org (full text, mbox):

From: Steven Allen <steven <at> stebalien.com>
To: Po Lu <luangruo <at> yahoo.com>, Eli Zaretskii <eliz <at> gnu.org>
Cc: 72323 <at> debbugs.gnu.org, storm <at> cua.dk
Subject: Re: bug#72323: 31.0.50; line-move unconditionally resets vscroll to 0
Date: Sun, 18 Aug 2024 10:42:25 -0700

Po Lu <luangruo <at> yahoo.com> writes:

> Eli Zaretskii <eliz <at> gnu.org> writes:
>
>>> This function is very clearly about cursor motion, not scrolling, and
>>> shouldn't mess with the current scroll position.
>>
>> Po Lu will tell, but my understanding of the comment is that it does
>> what it does out of necessity.
>
> I don't understand why it is inherently improper that line motion
> commands should reset vscroll, which is never set to a large value by
> precision scrolling.

E.g., let's say I'm viewing an org-mode file with embedded images. With
pixel-scroll-precision-mode, I can scroll through this file, letting the
images scroll off-screen by using the vscroll offset instead of having
them suddenly "jump" off screen as I scroll by them.

However, once I start typing, the second I try to change lines the
entire screen jumps because the entire image is now forced on-screen (if
it fits) or offscreen (if it doesn't). This is extremely jarring.

Message #38 received at 72323 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Steven Allen <steven <at> stebalien.com>
Cc: luangruo <at> yahoo.com, 72323 <at> debbugs.gnu.org, storm <at> cua.dk
Subject: Re: bug#72323: 31.0.50; line-move unconditionally resets vscroll to 0
Date: Sun, 18 Aug 2024 21:21:42 +0300

> From: Steven Allen <steven <at> stebalien.com>
> Cc: luangruo <at> yahoo.com, 72323 <at> debbugs.gnu.org, storm <at> cua.dk
> Date: Sun, 18 Aug 2024 10:38:29 -0700
> 
> Eli Zaretskii <eliz <at> gnu.org> writes:
> 
> > Once again: the vscroll value is pertinent only for the screen line
> > for which it was computed, because the way it is computed uses the
> > metrics of that line.  Once you move to another line, the value is no
> > longer pertinent.
> 
> Let's be precise about "move to another line":
> 
> - When window-start changes, vscroll becomes invalid because the lines at
>   the top of the screen (to which vscroll applies) has changed. I agree
>   that it must be reset in this case.
> - When point is moved up and down in such a way that window-start isn't
>   changed, vscroll is still perfectly valid as the top line in the
>   window hasn't changed.

I disagree.  When point moves to another screen line without moving
window-start, vscroll may or may not be valid.  Whether it is depends
on the details of what is on display.

>  vscroll is relative to the top line, not point.

No, vscroll is global for the entire window.  It affects the Y
coordinate of every screen line, not just that of the first screen
line.

> > Emacs supports smooth scrolling only within a single screen line, and
> > that uses vscroll.  That's the original design intent of vscroll.
> > Smooth scrolling between lines is not really supported.
> > pixel-scrolling attempts to solve that, and does it well, but it does
> > have some problematic corners.  Those corners need to be solved inside
> > pixel-scroll code.
> 
> Honestly, scrolling between lines is working perfectly.

It's a kludge that is very fragile, and sometimes breaks.

Message #41 received at 72323 <at> debbugs.gnu.org (full text, mbox):

From: Steven Allen <steven <at> stebalien.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: luangruo <at> yahoo.com, 72323 <at> debbugs.gnu.org, storm <at> cua.dk
Subject: Re: bug#72323: 31.0.50; line-move unconditionally resets vscroll to 0
Date: Sun, 18 Aug 2024 11:40:42 -0700

Eli Zaretskii <eliz <at> gnu.org> writes:

>> From: Steven Allen <steven <at> stebalien.com>
>> Cc: luangruo <at> yahoo.com, 72323 <at> debbugs.gnu.org, storm <at> cua.dk
>> Date: Sun, 18 Aug 2024 10:38:29 -0700
>> 
>> Eli Zaretskii <eliz <at> gnu.org> writes:
>> 
>> > Once again: the vscroll value is pertinent only for the screen line
>> > for which it was computed, because the way it is computed uses the
>> > metrics of that line.  Once you move to another line, the value is no
>> > longer pertinent.
>> 
>> Let's be precise about "move to another line":
>> 
>> - When window-start changes, vscroll becomes invalid because the lines at
>>   the top of the screen (to which vscroll applies) has changed. I agree
>>   that it must be reset in this case.
>> - When point is moved up and down in such a way that window-start isn't
>>   changed, vscroll is still perfectly valid as the top line in the
>>   window hasn't changed.
>
> I disagree.  When point moves to another screen line without moving
> window-start, vscroll may or may not be valid.  Whether it is depends
> on the details of what is on display.

Can you give me an example example where moving point invalidates
vscroll (except when point would move partially or fully off screen)?

Message #44 received at 72323 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Steven Allen <steven <at> stebalien.com>
Cc: luangruo <at> yahoo.com, 72323 <at> debbugs.gnu.org, storm <at> cua.dk
Subject: Re: bug#72323: 31.0.50; line-move unconditionally resets vscroll to 0
Date: Sun, 18 Aug 2024 22:01:46 +0300

> From: Steven Allen <steven <at> stebalien.com>
> Cc: luangruo <at> yahoo.com, 72323 <at> debbugs.gnu.org, storm <at> cua.dk
> Date: Sun, 18 Aug 2024 11:40:42 -0700
> 
> Eli Zaretskii <eliz <at> gnu.org> writes:
> 
> >> From: Steven Allen <steven <at> stebalien.com>
> >> Cc: luangruo <at> yahoo.com, 72323 <at> debbugs.gnu.org, storm <at> cua.dk
> >> Date: Sun, 18 Aug 2024 10:38:29 -0700
> >> 
> >> Eli Zaretskii <eliz <at> gnu.org> writes:
> >> 
> >> > Once again: the vscroll value is pertinent only for the screen line
> >> > for which it was computed, because the way it is computed uses the
> >> > metrics of that line.  Once you move to another line, the value is no
> >> > longer pertinent.
> >> 
> >> Let's be precise about "move to another line":
> >> 
> >> - When window-start changes, vscroll becomes invalid because the lines at
> >>   the top of the screen (to which vscroll applies) has changed. I agree
> >>   that it must be reset in this case.
> >> - When point is moved up and down in such a way that window-start isn't
> >>   changed, vscroll is still perfectly valid as the top line in the
> >>   window hasn't changed.
> >
> > I disagree.  When point moves to another screen line without moving
> > window-start, vscroll may or may not be valid.  Whether it is depends
> > on the details of what is on display.
> 
> Can you give me an example example where moving point invalidates
> vscroll (except when point would move partially or fully off screen)?

Why isn't the one example I gave enough?

The code in question doesn't know whether this is or isn't the case,
at least not in all cases and not without a lot of tedious layout
calculations.  Whether the current line will be fully visible is only
known after the window is redisplayed.  At which time we also check
that we didn't enter the scroll margins and other conditions that
require to scroll the window.  Keeping the vscroll would make all this
much more complicated, so we play it safe.

Message #47 received at 72323 <at> debbugs.gnu.org (full text, mbox):

From: Steven Allen <steven <at> stebalien.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: luangruo <at> yahoo.com, 72323 <at> debbugs.gnu.org, storm <at> cua.dk
Subject: Re: bug#72323: 31.0.50; line-move unconditionally resets vscroll to 0
Date: Sun, 18 Aug 2024 15:17:48 -0700

Eli Zaretskii <eliz <at> gnu.org> writes:

>> > I disagree.  When point moves to another screen line without moving
>> > window-start, vscroll may or may not be valid.  Whether it is depends
>> > on the details of what is on display.
>> 
>> Can you give me an example example where moving point invalidates
>> vscroll (except when point would move partially or fully off screen)?
>
> Why isn't the one example I gave enough?
>
> The code in question doesn't know whether this is or isn't the case,
> at least not in all cases and not without a lot of tedious layout
> calculations.  Whether the current line will be fully visible is only
> known after the window is redisplayed.  At which time we also check
> that we didn't enter the scroll margins and other conditions that
> require to scroll the window.  Keeping the vscroll would make all this
> much more complicated, so we play it safe.

I just wanted to confirm that the issue is specifically about the being
fully visible and not something else I'm missing. If that's the case,
I'll see if I can hack something up for my own use and, if usable, see
if it's possible to integrate into pixel-scroll-precision-mode. But
it'll have to be an advice as line-move is called all over the place.

It really sounds like you just don't want to mess with this function
which is a reasonable stance as the maintainer. But it was really hard
to tell if there was something I was fundamentally misunderstanding or
if you were just being cautious and not wanting to touch a complex piece
of machinery if it's working "well enough".

Message #50 received at 72323 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Steven Allen <steven <at> stebalien.com>
Cc: luangruo <at> yahoo.com, 72323 <at> debbugs.gnu.org, storm <at> cua.dk
Subject: Re: bug#72323: 31.0.50; line-move unconditionally resets vscroll to 0
Date: Mon, 19 Aug 2024 14:06:52 +0300

> From: Steven Allen <steven <at> stebalien.com>
> Cc: luangruo <at> yahoo.com, 72323 <at> debbugs.gnu.org, storm <at> cua.dk
> Date: Sun, 18 Aug 2024 15:17:48 -0700
> 
> Eli Zaretskii <eliz <at> gnu.org> writes:
> 
> >> > I disagree.  When point moves to another screen line without moving
> >> > window-start, vscroll may or may not be valid.  Whether it is depends
> >> > on the details of what is on display.
> >> 
> >> Can you give me an example example where moving point invalidates
> >> vscroll (except when point would move partially or fully off screen)?
> >
> > Why isn't the one example I gave enough?
> >
> > The code in question doesn't know whether this is or isn't the case,
> > at least not in all cases and not without a lot of tedious layout
> > calculations.  Whether the current line will be fully visible is only
> > known after the window is redisplayed.  At which time we also check
> > that we didn't enter the scroll margins and other conditions that
> > require to scroll the window.  Keeping the vscroll would make all this
> > much more complicated, so we play it safe.
> 
> I just wanted to confirm that the issue is specifically about the being
> fully visible and not something else I'm missing. If that's the case,
> I'll see if I can hack something up for my own use and, if usable, see
> if it's possible to integrate into pixel-scroll-precision-mode. But
> it'll have to be an advice as line-move is called all over the place.

That was the first thing on my mind.  It might be the only one, but I
cannot guarantee that: the Emacs display and display-related
capabilities are almost infinite in the features and combinations of
features they are expected to support; I'm hacking this code for the
last 20 years, and still learn new aspects every now and then.

> It really sounds like you just don't want to mess with this function
> which is a reasonable stance as the maintainer.

That's right: I spent so many hours debugging and fixing it in various
tricky situations that I very much dislike the idea of removing one of
its main assumptions which was there since before my time.  Please
keep in mind that it isn't just this function that resets vscroll, the
same is done under certain conditions by the display code in C as
well.  So if we are going to change that, we may need to make
corresponding changes there also.

> But it was really hard to tell if there was something I was
> fundamentally misunderstanding or if you were just being cautious
> and not wanting to touch a complex piece of machinery if it's
> working "well enough".

It's mainly the latter.  But I have a lot of gray hair to back that
up.

Message #53 received at 72323 <at> debbugs.gnu.org (full text, mbox):

From: Steven Allen <steven <at> stebalien.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: luangruo <at> yahoo.com, 72323 <at> debbugs.gnu.org, storm <at> cua.dk
Subject: Re: bug#72323: 31.0.50; line-move unconditionally resets vscroll to 0
Date: Mon, 19 Aug 2024 10:30:41 -0700

Ok, makes sense. Then I guess we can close this issue.

Message #58 received at 72323-done <at> debbugs.gnu.org (full text, mbox):

From: Stefan Kangas <stefankangas <at> gmail.com>
To: Steven Allen <steven <at> stebalien.com>, Eli Zaretskii <eliz <at> gnu.org>
Cc: luangruo <at> yahoo.com, 72323-done <at> debbugs.gnu.org, storm <at> cua.dk
Subject: Re: bug#72323: 31.0.50; line-move unconditionally resets vscroll to 0
Date: Sun, 29 Sep 2024 17:51:30 -0700

Steven Allen via "Bug reports for GNU Emacs, the Swiss army knife of
text editors" <bug-gnu-emacs <at> gnu.org> writes:

> Ok, makes sense. Then I guess we can close this issue.

Done.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.