GNU bug report logs -
#78474
31.0.50; Wrong char insertion in rxvt
Previous Next
To reply to this bug, email your comments to 78474 AT debbugs.gnu.org.
There is no need to reopen the bug first.
Toggle the display of automated, internal messages from the tracker.
Report forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#78474; Package
emacs.
(Sat, 17 May 2025 22:56:02 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
Bastien Guerry <bzg <at> gnu.org>:
New bug report received and forwarded. Copy sent to
bug-gnu-emacs <at> gnu.org.
(Sat, 17 May 2025 22:56:02 GMT)
Full text and
rfc822 format available.
Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
With Emacs >= 24 in rxvt (not urxvt), steps to reproduce:
1. find a new buffer and write "Coucou"
2. hit SPC
3. see the space inserted: it is too large.
https://dept-info.labri.fr/~thibault/tmp/coucou.png illustrates the bug.
Quoting Samuel: "Emacs, instead of sending a rightward cursor movement
(\e[C), sends \009\008 (a tabulation and a leftward cursor movement)"
This char insertion problem confuses assistive technologies for the
visually impaired.
Sebastien reported this problem and both Samuel and Sebastien might help
with further information on how to reproduce this, if needed.
In GNU Emacs 31.0.50 (build 1, x86_64-pc-linux-gnu, GTK+ Version
3.24.38, cairo version 1.16.0) of 2025-05-16 built on guerry
Repository revision: 7d7d821c495abcd740fd20f6a8df6da5bd920cd3
Repository branch: master
Windowing system distributor 'The X.Org Foundation', version 11.0.12101007
System Description: Debian GNU/Linux 12 (bookworm)
Configured using:
'configure --with-native-compilation --without-compress-install
--with-mailutils --with-tree-sitter --with-imagemagick'
Configured features:
CAIRO DBUS FREETYPE GIF GLIB GMP GNUTLS GPM GSETTINGS HARFBUZZ
IMAGEMAGICK JPEG LCMS2 LIBSELINUX LIBXML2 MODULES NATIVE_COMP NOTIFY
INOTIFY PDUMPER PNG RSVG SECCOMP SOUND SQLITE3 THREADS TIFF
TOOLKIT_SCROLL_BARS TREE_SITTER WEBP X11 XDBE XIM XINERAMA XINPUT2 XPM
XRANDR GTK3 ZLIB
Important settings:
value of $LANG: fr_FR.UTF-8
value of $XMODIFIERS: @im=ibus
locale-coding-system: utf-8-unix
Major mode: IBuffer
Minor modes in effect:
global-git-commit-mode: t
magit-auto-revert-mode: t
server-mode: t
pdf-occur-ibuffer-minor-mode: t
pdf-occur-global-minor-mode: t
envrc-global-mode: t
envrc-mode: t
which-key-mode: t
hidden-mode-line-mode: t
bzg-big-fringe-mode: t
global-hl-line-mode: t
pixel-scroll-mode: t
auto-insert-mode: t
global-eldoc-mode: t
eldoc-mode: t
electric-indent-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
minibuffer-regexp-mode: t
buffer-read-only: t
line-number-mode: t
indent-tabs-mode: t
transient-mark-mode: t
auto-composition-mode: t
auto-encryption-mode: t
auto-compression-mode: t
Load-path shadows:
/home/bzg/.emacs.d/elpa/transient-20250511.1808/transient hides /usr/local/share/emacs/31.0.50/lisp/transient
/home/bzg/.emacs.d/elpa/bind-key-20230203.2004/bind-key hides /usr/local/share/emacs/31.0.50/lisp/bind-key
/home/bzg/.emacs.d/elpa/which-key-20240620.2145/which-key hides /usr/local/share/emacs/31.0.50/lisp/which-key
/home/bzg/.emacs.d/elpa/use-package-20230426.2324/use-package-ensure hides /usr/local/share/emacs/31.0.50/lisp/use-package/use-package-ensure
/home/bzg/.emacs.d/elpa/use-package-20230426.2324/use-package-core hides /usr/local/share/emacs/31.0.50/lisp/use-package/use-package-core
/home/bzg/.emacs.d/elpa/use-package-20230426.2324/use-package hides /usr/local/share/emacs/31.0.50/lisp/use-package/use-package
/home/bzg/.emacs.d/elpa/use-package-20230426.2324/use-package-diminish hides /usr/local/share/emacs/31.0.50/lisp/use-package/use-package-diminish
/home/bzg/.emacs.d/elpa/use-package-20230426.2324/use-package-delight hides /usr/local/share/emacs/31.0.50/lisp/use-package/use-package-delight
/home/bzg/.emacs.d/elpa/use-package-20230426.2324/use-package-bind-key hides /usr/local/share/emacs/31.0.50/lisp/use-package/use-package-bind-key
/home/bzg/.emacs.d/elpa/use-package-20230426.2324/use-package-jump hides /usr/local/share/emacs/31.0.50/lisp/use-package/use-package-jump
/home/bzg/.emacs.d/elpa/use-package-20230426.2324/use-package-lint hides /usr/local/share/emacs/31.0.50/lisp/use-package/use-package-lint
/home/bzg/.emacs.d/elpa/markdown-ts-mode-20240422.2329/markdown-ts-mode hides /usr/local/share/emacs/31.0.50/lisp/textmodes/markdown-ts-mode
/home/bzg/.emacs.d/elpa/peg-20150708.641/peg hides /usr/local/share/emacs/31.0.50/lisp/progmodes/peg
~/install/git/org/org-mode/lisp/org-colview hides /usr/local/share/emacs/31.0.50/lisp/org/org-colview
~/install/git/org/org-mode/lisp/org-mouse hides /usr/local/share/emacs/31.0.50/lisp/org/org-mouse
~/install/git/org/org-mode/lisp/ox-org hides /usr/local/share/emacs/31.0.50/lisp/org/ox-org
~/install/git/org/org-mode/lisp/ol-docview hides /usr/local/share/emacs/31.0.50/lisp/org/ol-docview
~/install/git/org/org-mode/lisp/ob-calc hides /usr/local/share/emacs/31.0.50/lisp/org/ob-calc
~/install/git/org/org-mode/lisp/org-mobile hides /usr/local/share/emacs/31.0.50/lisp/org/org-mobile
~/install/git/org/org-mode/lisp/ob-lua hides /usr/local/share/emacs/31.0.50/lisp/org/ob-lua
~/install/git/org/org-mode/lisp/ob-lisp hides /usr/local/share/emacs/31.0.50/lisp/org/ob-lisp
~/install/git/org/org-mode/lisp/org-archive hides /usr/local/share/emacs/31.0.50/lisp/org/org-archive
~/install/git/org/org-mode/lisp/ol-info hides /usr/local/share/emacs/31.0.50/lisp/org/ol-info
~/install/git/org/org-mode/lisp/ob-julia hides /usr/local/share/emacs/31.0.50/lisp/org/ob-julia
~/install/git/org/org-mode/lisp/org hides /usr/local/share/emacs/31.0.50/lisp/org/org
~/install/git/org/org-mode/lisp/ob-awk hides /usr/local/share/emacs/31.0.50/lisp/org/ob-awk
~/install/git/org/org-mode/lisp/ol-gnus hides /usr/local/share/emacs/31.0.50/lisp/org/ol-gnus
~/install/git/org/org-mode/lisp/ob-sass hides /usr/local/share/emacs/31.0.50/lisp/org/ob-sass
~/install/git/org/org-mode/lisp/org-attach-git hides /usr/local/share/emacs/31.0.50/lisp/org/org-attach-git
~/install/git/org/org-mode/lisp/org-list hides /usr/local/share/emacs/31.0.50/lisp/org/org-list
~/install/git/org/org-mode/lisp/org-agenda hides /usr/local/share/emacs/31.0.50/lisp/org/org-agenda
~/install/git/org/org-mode/lisp/ol-w3m hides /usr/local/share/emacs/31.0.50/lisp/org/ol-w3m
~/install/git/org/org-mode/lisp/ob-haskell hides /usr/local/share/emacs/31.0.50/lisp/org/ob-haskell
~/install/git/org/org-mode/lisp/ox-koma-letter hides /usr/local/share/emacs/31.0.50/lisp/org/ox-koma-letter
~/install/git/org/org-mode/lisp/ob-sed hides /usr/local/share/emacs/31.0.50/lisp/org/ob-sed
~/install/git/org/org-mode/lisp/ob-clojure hides /usr/local/share/emacs/31.0.50/lisp/org/ob-clojure
~/install/git/org/org-mode/lisp/ox-ascii hides /usr/local/share/emacs/31.0.50/lisp/org/ox-ascii
~/install/git/org/org-mode/lisp/ox-texinfo hides /usr/local/share/emacs/31.0.50/lisp/org/ox-texinfo
~/install/git/org/org-mode/lisp/ob-exp hides /usr/local/share/emacs/31.0.50/lisp/org/ob-exp
~/install/git/org/org-mode/lisp/ob-plantuml hides /usr/local/share/emacs/31.0.50/lisp/org/ob-plantuml
~/install/git/org/org-mode/lisp/org-id hides /usr/local/share/emacs/31.0.50/lisp/org/org-id
~/install/git/org/org-mode/lisp/ob-comint hides /usr/local/share/emacs/31.0.50/lisp/org/ob-comint
~/install/git/org/org-mode/lisp/ol-irc hides /usr/local/share/emacs/31.0.50/lisp/org/ol-irc
~/install/git/org/org-mode/lisp/ox-publish hides /usr/local/share/emacs/31.0.50/lisp/org/ox-publish
~/install/git/org/org-mode/lisp/ob-processing hides /usr/local/share/emacs/31.0.50/lisp/org/ob-processing
~/install/git/org/org-mode/lisp/org-faces hides /usr/local/share/emacs/31.0.50/lisp/org/org-faces
~/install/git/org/org-mode/lisp/ob-sqlite hides /usr/local/share/emacs/31.0.50/lisp/org/ob-sqlite
~/install/git/org/org-mode/lisp/org-attach hides /usr/local/share/emacs/31.0.50/lisp/org/org-attach
~/install/git/org/org-mode/lisp/ob-lob hides /usr/local/share/emacs/31.0.50/lisp/org/ob-lob
~/install/git/org/org-mode/lisp/ox-beamer hides /usr/local/share/emacs/31.0.50/lisp/org/ox-beamer
~/install/git/org/org-mode/lisp/ox-latex hides /usr/local/share/emacs/31.0.50/lisp/org/ox-latex
~/install/git/org/org-mode/lisp/ob-core hides /usr/local/share/emacs/31.0.50/lisp/org/ob-core
~/install/git/org/org-mode/lisp/org-persist hides /usr/local/share/emacs/31.0.50/lisp/org/org-persist
~/install/git/org/org-mode/lisp/ob-octave hides /usr/local/share/emacs/31.0.50/lisp/org/ob-octave
~/install/git/org/org-mode/lisp/ob-gnuplot hides /usr/local/share/emacs/31.0.50/lisp/org/ob-gnuplot
~/install/git/org/org-mode/lisp/org-element-ast hides /usr/local/share/emacs/31.0.50/lisp/org/org-element-ast
~/install/git/org/org-mode/lisp/oc-natbib hides /usr/local/share/emacs/31.0.50/lisp/org/oc-natbib
~/install/git/org/org-mode/lisp/org-capture hides /usr/local/share/emacs/31.0.50/lisp/org/org-capture
~/install/git/org/org-mode/lisp/org-timer hides /usr/local/share/emacs/31.0.50/lisp/org/org-timer
~/install/git/org/org-mode/lisp/ob-scheme hides /usr/local/share/emacs/31.0.50/lisp/org/ob-scheme
~/install/git/org/org-mode/lisp/ob-ditaa hides /usr/local/share/emacs/31.0.50/lisp/org/ob-ditaa
~/install/git/org/org-mode/lisp/ol-mhe hides /usr/local/share/emacs/31.0.50/lisp/org/ol-mhe
~/install/git/org/org-mode/lisp/org-feed hides /usr/local/share/emacs/31.0.50/lisp/org/org-feed
~/install/git/org/org-mode/lisp/ol-man hides /usr/local/share/emacs/31.0.50/lisp/org/ol-man
~/install/git/org/org-mode/lisp/org-macro hides /usr/local/share/emacs/31.0.50/lisp/org/org-macro
~/install/git/org/org-mode/lisp/ol hides /usr/local/share/emacs/31.0.50/lisp/org/ol
~/install/git/org/org-mode/lisp/ob-makefile hides /usr/local/share/emacs/31.0.50/lisp/org/ob-makefile
~/install/git/org/org-mode/lisp/oc-basic hides /usr/local/share/emacs/31.0.50/lisp/org/oc-basic
~/install/git/org/org-mode/lisp/ob-ocaml hides /usr/local/share/emacs/31.0.50/lisp/org/ob-ocaml
~/install/git/org/org-mode/lisp/org-table hides /usr/local/share/emacs/31.0.50/lisp/org/org-table
~/install/git/org/org-mode/lisp/ob-groovy hides /usr/local/share/emacs/31.0.50/lisp/org/ob-groovy
~/install/git/org/org-mode/lisp/ox-man hides /usr/local/share/emacs/31.0.50/lisp/org/ox-man
~/install/git/org/org-mode/lisp/org-footnote hides /usr/local/share/emacs/31.0.50/lisp/org/org-footnote
~/install/git/org/org-mode/lisp/org-clock hides /usr/local/share/emacs/31.0.50/lisp/org/org-clock
~/install/git/org/org-mode/lisp/ob-tangle hides /usr/local/share/emacs/31.0.50/lisp/org/ob-tangle
~/install/git/org/org-mode/lisp/ob-screen hides /usr/local/share/emacs/31.0.50/lisp/org/ob-screen
~/install/git/org/org-mode/lisp/ob-forth hides /usr/local/share/emacs/31.0.50/lisp/org/ob-forth
~/install/git/org/org-mode/lisp/oc-biblatex hides /usr/local/share/emacs/31.0.50/lisp/org/oc-biblatex
~/install/git/org/org-mode/lisp/ol-bibtex hides /usr/local/share/emacs/31.0.50/lisp/org/ol-bibtex
~/install/git/org/org-mode/lisp/org-duration hides /usr/local/share/emacs/31.0.50/lisp/org/org-duration
~/install/git/org/org-mode/lisp/org-pcomplete hides /usr/local/share/emacs/31.0.50/lisp/org/org-pcomplete
~/install/git/org/org-mode/lisp/ob-css hides /usr/local/share/emacs/31.0.50/lisp/org/ob-css
~/install/git/org/org-mode/lisp/ob-C hides /usr/local/share/emacs/31.0.50/lisp/org/ob-C
~/install/git/org/org-mode/lisp/ob-matlab hides /usr/local/share/emacs/31.0.50/lisp/org/ob-matlab
~/install/git/org/org-mode/lisp/ob-latex hides /usr/local/share/emacs/31.0.50/lisp/org/ob-latex
~/install/git/org/org-mode/lisp/org-tempo hides /usr/local/share/emacs/31.0.50/lisp/org/org-tempo
~/install/git/org/org-mode/lisp/org-protocol hides /usr/local/share/emacs/31.0.50/lisp/org/org-protocol
~/install/git/org/org-mode/lisp/org-macs hides /usr/local/share/emacs/31.0.50/lisp/org/org-macs
~/install/git/org/org-mode/lisp/ol-eww hides /usr/local/share/emacs/31.0.50/lisp/org/ol-eww
~/install/git/org/org-mode/lisp/ob-R hides /usr/local/share/emacs/31.0.50/lisp/org/ob-R
~/install/git/org/org-mode/lisp/ob-dot hides /usr/local/share/emacs/31.0.50/lisp/org/ob-dot
~/install/git/org/org-mode/lisp/ol-bbdb hides /usr/local/share/emacs/31.0.50/lisp/org/ol-bbdb
~/install/git/org/org-mode/lisp/org-datetree hides /usr/local/share/emacs/31.0.50/lisp/org/org-datetree
~/install/git/org/org-mode/lisp/org-fold hides /usr/local/share/emacs/31.0.50/lisp/org/org-fold
~/install/git/org/org-mode/lisp/ob-emacs-lisp hides /usr/local/share/emacs/31.0.50/lisp/org/ob-emacs-lisp
~/install/git/org/org-mode/lisp/ob-fortran hides /usr/local/share/emacs/31.0.50/lisp/org/ob-fortran
~/install/git/org/org-mode/lisp/org-habit hides /usr/local/share/emacs/31.0.50/lisp/org/org-habit
~/install/git/org/org-mode/lisp/ob-lilypond hides /usr/local/share/emacs/31.0.50/lisp/org/ob-lilypond
~/install/git/org/org-mode/lisp/org-loaddefs hides /usr/local/share/emacs/31.0.50/lisp/org/org-loaddefs
~/install/git/org/org-mode/lisp/oc hides /usr/local/share/emacs/31.0.50/lisp/org/oc
~/install/git/org/org-mode/lisp/org-keys hides /usr/local/share/emacs/31.0.50/lisp/org/org-keys
~/install/git/org/org-mode/lisp/ob-org hides /usr/local/share/emacs/31.0.50/lisp/org/ob-org
~/install/git/org/org-mode/lisp/ol-doi hides /usr/local/share/emacs/31.0.50/lisp/org/ol-doi
~/install/git/org/org-mode/lisp/org-element hides /usr/local/share/emacs/31.0.50/lisp/org/org-element
~/install/git/org/org-mode/lisp/ob-sql hides /usr/local/share/emacs/31.0.50/lisp/org/ob-sql
~/install/git/org/org-mode/lisp/ox-md hides /usr/local/share/emacs/31.0.50/lisp/org/ox-md
~/install/git/org/org-mode/lisp/ob-eshell hides /usr/local/share/emacs/31.0.50/lisp/org/ob-eshell
~/install/git/org/org-mode/lisp/org-ctags hides /usr/local/share/emacs/31.0.50/lisp/org/org-ctags
~/install/git/org/org-mode/lisp/ob-shell hides /usr/local/share/emacs/31.0.50/lisp/org/ob-shell
~/install/git/org/org-mode/lisp/oc-csl hides /usr/local/share/emacs/31.0.50/lisp/org/oc-csl
~/install/git/org/org-mode/lisp/ox hides /usr/local/share/emacs/31.0.50/lisp/org/ox
~/install/git/org/org-mode/lisp/org-indent hides /usr/local/share/emacs/31.0.50/lisp/org/org-indent
~/install/git/org/org-mode/lisp/org-plot hides /usr/local/share/emacs/31.0.50/lisp/org/org-plot
~/install/git/org/org-mode/lisp/org-fold-core hides /usr/local/share/emacs/31.0.50/lisp/org/org-fold-core
~/install/git/org/org-mode/lisp/org-inlinetask hides /usr/local/share/emacs/31.0.50/lisp/org/org-inlinetask
~/install/git/org/org-mode/lisp/org-refile hides /usr/local/share/emacs/31.0.50/lisp/org/org-refile
~/install/git/org/org-mode/lisp/ob-ruby hides /usr/local/share/emacs/31.0.50/lisp/org/ob-ruby
~/install/git/org/org-mode/lisp/ob-java hides /usr/local/share/emacs/31.0.50/lisp/org/ob-java
~/install/git/org/org-mode/lisp/ob-maxima hides /usr/local/share/emacs/31.0.50/lisp/org/ob-maxima
~/install/git/org/org-mode/lisp/org-cycle hides /usr/local/share/emacs/31.0.50/lisp/org/org-cycle
~/install/git/org/org-mode/lisp/org-lint hides /usr/local/share/emacs/31.0.50/lisp/org/org-lint
~/install/git/org/org-mode/lisp/ox-html hides /usr/local/share/emacs/31.0.50/lisp/org/ox-html
~/install/git/org/org-mode/lisp/ob-perl hides /usr/local/share/emacs/31.0.50/lisp/org/ob-perl
~/install/git/org/org-mode/lisp/ob-eval hides /usr/local/share/emacs/31.0.50/lisp/org/ob-eval
~/install/git/org/org-mode/lisp/org-entities hides /usr/local/share/emacs/31.0.50/lisp/org/org-entities
~/install/git/org/org-mode/lisp/org-crypt hides /usr/local/share/emacs/31.0.50/lisp/org/org-crypt
~/install/git/org/org-mode/lisp/org-compat hides /usr/local/share/emacs/31.0.50/lisp/org/org-compat
~/install/git/org/org-mode/lisp/org-num hides /usr/local/share/emacs/31.0.50/lisp/org/org-num
~/install/git/org/org-mode/lisp/ob-js hides /usr/local/share/emacs/31.0.50/lisp/org/ob-js
~/install/git/org/org-mode/lisp/oc-bibtex hides /usr/local/share/emacs/31.0.50/lisp/org/oc-bibtex
~/install/git/org/org-mode/lisp/ob-table hides /usr/local/share/emacs/31.0.50/lisp/org/ob-table
~/install/git/org/org-mode/lisp/ol-rmail hides /usr/local/share/emacs/31.0.50/lisp/org/ol-rmail
~/install/git/org/org-mode/lisp/ob-python hides /usr/local/share/emacs/31.0.50/lisp/org/ob-python
~/install/git/org/org-mode/lisp/ol-eshell hides /usr/local/share/emacs/31.0.50/lisp/org/ol-eshell
~/install/git/org/org-mode/lisp/ob-ref hides /usr/local/share/emacs/31.0.50/lisp/org/ob-ref
~/install/git/org/org-mode/lisp/org-goto hides /usr/local/share/emacs/31.0.50/lisp/org/org-goto
~/install/git/org/org-mode/lisp/org-src hides /usr/local/share/emacs/31.0.50/lisp/org/org-src
~/install/git/org/org-mode/lisp/ox-icalendar hides /usr/local/share/emacs/31.0.50/lisp/org/ox-icalendar
~/install/git/org/org-mode/lisp/org-version hides /usr/local/share/emacs/31.0.50/lisp/org/org-version
~/install/git/org/org-mode/lisp/ox-odt hides /usr/local/share/emacs/31.0.50/lisp/org/ox-odt
~/install/git/org/org-mode/lisp/ob hides /usr/local/share/emacs/31.0.50/lisp/org/ob
Features:
(shadow emacs-news-mode emacsbug cc-mode cc-fonts cc-guess cc-menus
cc-cmds cc-styles cc-align cc-engine helpful cc-langs cc-vars cc-defs
trace edebug info-look elisp-refs helpful-autoloads elisp-refs-autoloads
loaddefs-gen tar-mode display-line-numbers finder-inf macros hippie-exp
vc-filewise tramp-cmds tramp-cache time-stamp pdf-sync pdf-annot
pdf-outline pdf-links pdf-history gnus-search eieio-opt speedbar ezimage
dframe lsp-zig lsp-yang lsp-yaml lsp-xml lsp-wgsl lsp-volar
lsp-vimscript lsp-vhdl lsp-vetur lsp-html lsp-verilog lsp-vala lsp-v
lsp-typespec lsp-typeprof lsp-ttcn3 lsp-ts-query lsp-trunk lsp-toml
lsp-tilt lsp-tex lsp-terraform lsp-svelte lsp-steep lsp-sqls lsp-sql
lsp-sorbet lsp-solidity lsp-solargraph lsp-semgrep lsp-rust lsp-ruff
lsp-ruby-syntax-tree lsp-ruby-lsp lsp-rubocop lsp-roslyn lsp-roc lsp-rf
lsp-remark lsp-racket lsp-r lsp-qml lsp-pylsp lsp-pyls lsp-pwsh
lsp-purescript lsp-postgres lsp-pls lsp-php lsp-perlnavigator lsp-perl
lsp-openscad lsp-ocaml find-file lsp-nushell lsp-nix lsp-nim lsp-nginx
lsp-nextflow lsp-move lsp-mojo lsp-mint lsp-meson lsp-mdx lsp-matlab
lsp-marksman lsp-markdown lsp-magik lsp-fennel lsp-lua lsp-lisp
lsp-kubernetes-helm lsp-kotlin lsp-json lsp-jq lsp-javascript lsp-idris
lsp-haxe lsp-hack lsp-groovy lsp-graphql lsp-golangci-lint lsp-glsl
lsp-gleam lsp-gdscript lsp-fsharp lsp-futhark lsp-fortran lsp-eslint
lsp-erlang lsp-emmet lsp-elm lsp-elixir lsp-earthly lsp-dockerfile
lsp-dhall lsp-d lsp-cypher lsp-cucumber lsp-copilot lsp-css lsp-c3
lsp-csharp lsp-crystal lsp-credo lsp-cobol lsp-cmake lsp-clojure
lsp-clangd lsp-bufls lsp-go lsp-completion lsp-beancount lsp-bash
lsp-awk lsp-autotools lsp-astro lsp-asm lsp-ansible lsp-angular lsp-ada
lsp-semantic-tokens lsp-actionscript lsp-mode lsp-protocol tree-widget
markdown-mode ht f ewoc company-oddmuse company-keywords company-etags
etags fileloop company-gtags company-dabbrev-code company-dabbrev
company-files company-clang company-capf company-cmake company-semantic
company-template company-bbdb company origami origami-parsers cl s
org-duration help-fns radix-tree cl-print debug backtrace cal-iso
cal-china lunar solar cal-dst cal-bahai cal-islam cal-hebrew holidays
holiday-loaddefs cal-move tabify elfeed-link elfeed-show elfeed-search
elfeed-csv elfeed elfeed-curl elfeed-log xml-query elfeed-db elfeed-lib
bbdb-message mailalias flow-fill vc-hg vc-bzr vc-src vc-sccs vc-svn
vc-cvs vc-rcs log-view bug-reference magit-extras face-remap
magit-bookmark 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 magit-repos magit-apply magit-wip magit-log which-func magit-diff
smerge-mode diff git-commit log-edit pcvs-util add-log magit-core
magit-autorevert autorevert magit-margin magit-transient magit-process
with-editor server magit-mode transient benchmark magit-git magit-base
magit-section llama dabbrev url-http url-gw url-cache url-auth char-fold
misearch multi-isearch sort gnus-cite smiley mm-archive mail-extr qp
textsec uni-scripts idna-mapping ucs-normalize uni-confusable
textsec-check gnus-async gnus-bcklg gnus-dup gnus-ml cursor-sensor nndoc
utf-7 network-stream nsm nnfolder nnnil gptel-curl gptel-org cus-start
gptel-anthropic gptel gptel-openai compat pdf-occur ibuf-ext tablist
tablist-filter semantic/wisent/comp semantic/wisent
semantic/wisent/wisent semantic/util-modes semantic/util semantic
semantic/tag semantic/lex semantic/fw mode-local cedet pdf-isearch
let-alist pdf-misc pdf-tools pdf-view bookmark pdf-cache pdf-info tq
pdf-util pdf-macs dired-subtree dired-hacks-utils dired-aux dash envrc
inheritenv which-key register-list ibuffer ibuffer-loaddefs whitespace
flycheck-clj-kondo flycheck clojure-ts-mode clj-refactor cap-words
superword subword hydra lv inflections mc-hide-unmatched-lines-mode
mc-mark-more sgml-mode facemenu mc-cycle-cursors multiple-cursors-core
rect yasnippet cider tramp-sh cider-debug cider-browse-ns cider-mode
cider-xref-backend cider-find cider-completion cider-profile
cider-inspector cider-eval cider-jar arc-mode archive-mode compile
cider-repl-history pulse cider-repl cider-resolve cider-test
cider-overlays cider-stacktrace cider-doc cider-browse-spec
cider-clojuredocs cider-eldoc cider-docstring cider-client cider-common
xref project cider-completion-context cider-connection cider-popup
sesman-browser nrepl-client sesman vc queue nrepl-dict cider-util color
spinner parseedn parseclj-parser parseclj-lex parseclj-alist
clojure-mode lisp-mnt imenu align paredit edmacro kmacro dired-x 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 notmuch-tag notmuch-lib notmuch-compat
hl-line bbdb-gnus bbdb-mua bbdb-anniv bbdb-com crm bbdb bbdb-site
timezone gnus-dired gnus-icalendar org-capture icalendar gnus-alias
advice gnus-delay gnus-draft gnus-agent gnus-srvr gnus-score score-mode
nnvirtual nntp gnus-cache gnus-msg nndraft nnmh use-package-core appt
diary-lib diary-loaddefs vc-git diff-mode track-changes vc-dispatcher
oc-basic disp-table ol-eww eww vtable mule-util url-queue mm-url
ol-rmail ol-mhe ol-irc ol-info ol-docview doc-view filenotify jka-compr
image-mode exif ol-bibtex bibtex ol-bbdb ol-w3m ol-doi org-link-doi
ox-koma-letter ox-beamer ox-md 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 org-agenda ox-html table ox-ascii
ox-publish ox org-attach ob-gnuplot ob-R ob-plantuml ob-scheme ob-ledger
ob-ditaa ob-org ob-clojure ob-dot ob-shell org-clock org-element
org-persist org-id org-refile avl-tree generator ol-gnus nnselect
gnus-art mm-uu mml2015 mm-view mml-smime smime gnutls dig gnus-sum shr
pixel-fill kinsoku url-file svg dom gnus-group gnus-undo gnus-start
gnus-dbus dbus xml gnus-cloud nnimap nnmail mail-source utf7 nnoo
gnus-spec gnus-int gnus-range message sendmail yank-media puny dired
dired-loaddefs rfc822 mml mml-sec epa epg rfc6068 epg-config mm-decode
mm-bodies mm-encode mail-parse rfc2231 rfc2047 rfc2045 ietf-drums
mailabbrev gmm-utils gnus-win gnus nnheader gnus-util
text-property-search range mm-util mail-prsvr org-bullets org-tempo
tempo txl easy-mmode guess-language flyspell ispell org ob ob-tangle
ob-ref ob-lob ob-table ob-exp org-macro org-src sh-script smie treesit
executable ob-comint org-element-ast inline org-pcomplete org-list
org-footnote org-faces org-entities noutline outline ob-emacs-lisp
ob-core ob-eval org-cycle org-table ol org-fold org-fold-core org-keys
oc org-loaddefs thingatpt find-func cal-menu calendar cal-loaddefs
org-version org-compat org-macs request mailheader mail-utils
modus-operandi-theme modus-themes derived pixel-scroll cua-base time
autoinsert comp comp-cstr cl-extra comp-run comp-common tramp trampver
tramp-integration files-x tramp-message help-mode tramp-compat shell
pcomplete comint ansi-osc ring parse-time iso8601 time-date format-spec
ansi-color tramp-loaddefs cus-edit pp cus-load wid-edit affe-autoloads
aggressive-indent-autoloads async-autoloads bbdb-autoloads
browse-kill-ring-autoloads clj-refactor-autoloads
clojure-ts-mode-autoloads company-autoloads consult-autoloads
csv-mode-autoloads deadgrep-autoloads debbugs-autoloads
diff-hl-autoloads dired-narrow-autoloads dired-ranger-autoloads
dired-subtree-autoloads dired-hacks-utils-autoloads docker-autoloads
aio-autoloads elfeed-autoloads elpher-autoloads envrc-autoloads
exec-path-from-shell-autoloads fd-dired-autoloads
flycheck-clj-kondo-autoloads flycheck-clojure-autoloads
flycheck-autoloads cider-autoloads fzf-autoloads
git-timemachine-autoloads gnus-alias-autoloads gptel-autoloads
guide-key-autoloads htmlize-autoloads inf-clojure-autoloads
clojure-mode-autoloads inheritenv-autoloads jinx-autoloads
json-mode-autoloads rx json-reformat-autoloads
know-your-http-well-autoloads lsp-ui-autoloads lsp-mode-autoloads
ht-autoloads f-autoloads magit-autoloads pcase markdown-mode-autoloads
markdown-ts-mode-autoloads multiple-cursors-autoloads
nginx-mode-autoloads notmuch-autoloads org-noter-autoloads
orgalist-autoloads ox-json-autoloads pandoc-mode-autoloads
hydra-autoloads lv-autoloads paredit-autoloads parseedn-autoloads
parseclj-autoloads pdf-tools-autoloads dash-autoloads po-mode-autoloads
popwin-autoloads warnings relint-autoloads restclient-autoloads
rg-autoloads s-autoloads sesman-autoloads tablist-autoloads
taxy-magit-section-autoloads taxy-autoloads magit-section-autoloads
llama-autoloads transient-autoloads txl-autoloads
guess-language-autoloads request-autoloads use-package-autoloads
bind-key-autoloads varuga-autoloads vterm-autoloads web-mode-autoloads
wgrep-autoloads which-key-autoloads info with-editor-autoloads
xr-autoloads yasnippet-autoloads package browse-url xdg 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 icons password-cache json
subr-x map byte-opt gv bytecomp byte-compile url-vars 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 system-font-setting
font-render-setting cairo gtk x-toolkit xinput2 x multi-tty move-toolbar
make-network-process tty-child-frames native-compile emacs)
Memory information:
((conses 16 3611857 536322) (symbols 48 113233 45)
(strings 32 1093966 148111) (string-bytes 1 38051469)
(vectors 16 319894) (vector-slots 8 4352010 963665)
(floats 8 4560 13360) (intervals 56 217767 5934) (buffers 1064 100))
--
Bastien
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#78474; Package
emacs.
(Sun, 18 May 2025 05:15:02 GMT)
Full text and
rfc822 format available.
Message #8 received at 78474 <at> debbugs.gnu.org (full text, mbox):
> Cc: Sébastien Hinderer <Sebastien.Hinderer <at> inria.fr>,
> Samuel Thibault <samuel.thibault <at> gnu.org>
> From: Bastien Guerry <bzg <at> gnu.org>
> Date: Sun, 18 May 2025 00:53:13 +0200
>
>
> With Emacs >= 24 in rxvt (not urxvt), steps to reproduce:
>
> 1. find a new buffer and write "Coucou"
> 2. hit SPC
> 3. see the space inserted: it is too large.
>
> https://dept-info.labri.fr/~thibault/tmp/coucou.png illustrates the bug.
>
> Quoting Samuel: "Emacs, instead of sending a rightward cursor movement
> (\e[C), sends \009\008 (a tabulation and a leftward cursor movement)"
>
> This char insertion problem confuses assistive technologies for the
> visually impaired.
>
> Sebastien reported this problem and both Samuel and Sebastien might help
> with further information on how to reproduce this, if needed.
Emacs has code to estimate the cost of the various ways of getting the
same effect on a text-only terminal and choose the least expensive
one, see cm.c. If some of the calculations there need to be augmented
to avoid confusing the technologies you mention, someone who knows
about those technologies should study the code and tell us how to
modify the calculations. Then we could have those modifications
either optional (subject to some user option), or even unconditional.
If Sébastien or Samuel (or someone else) can help us understand how to
modify the cost calculations and/or what optimizations of cursor
motion to avoid when these technologies for the visually impaired are
used, we could see how to fix this.
Thanks.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#78474; Package
emacs.
(Sun, 18 May 2025 08:02:02 GMT)
Full text and
rfc822 format available.
Message #11 received at 78474 <at> debbugs.gnu.org (full text, mbox):
Hello,
Eli Zaretskii, le dim. 18 mai 2025 08:13:58 +0300, a ecrit:
> > Quoting Samuel: "Emacs, instead of sending a rightward cursor movement
> > (\e[C), sends \009\008 (a tabulation and a leftward cursor movement)"
>
> If Sébastien or Samuel (or someone else) can help us understand how to
> modify the cost calculations and/or what optimizations of cursor
> motion to avoid when these technologies for the visually impaired are
> used, we could see how to fix this.
That is exactly what is written above.
Samuel
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#78474; Package
emacs.
(Sun, 18 May 2025 08:06:01 GMT)
Full text and
rfc822 format available.
Message #14 received at 78474 <at> debbugs.gnu.org (full text, mbox):
> Date: Sun, 18 May 2025 10:01:17 +0200
> From: Samuel Thibault <samuel.thibault <at> gnu.org>
> Cc: Bastien Guerry <bzg <at> gnu.org>, 78474 <at> debbugs.gnu.org,
> Sebastien.Hinderer <at> inria.fr
>
> Hello,
>
> Eli Zaretskii, le dim. 18 mai 2025 08:13:58 +0300, a ecrit:
> > > Quoting Samuel: "Emacs, instead of sending a rightward cursor movement
> > > (\e[C), sends \009\008 (a tabulation and a leftward cursor movement)"
> >
> > If Sébastien or Samuel (or someone else) can help us understand how to
> > modify the cost calculations and/or what optimizations of cursor
> > motion to avoid when these technologies for the visually impaired are
> > used, we could see how to fix this.
>
> That is exactly what is written above.
Sorry, I don't understand: what is written above?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#78474; Package
emacs.
(Sun, 18 May 2025 08:31:02 GMT)
Full text and
rfc822 format available.
Message #17 received at 78474 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii, le dim. 18 mai 2025 11:05:49 +0300, a ecrit:
> > Eli Zaretskii, le dim. 18 mai 2025 08:13:58 +0300, a ecrit:
> > > > Quoting Samuel: "Emacs, instead of sending a rightward cursor movement
> > > > (\e[C), sends \009\008 (a tabulation and a leftward cursor movement)"
> > >
> > > If Sébastien or Samuel (or someone else) can help us understand how to
> > > modify the cost calculations and/or what optimizations of cursor
> > > motion to avoid when these technologies for the visually impaired are
> > > used, we could see how to fix this.
> >
> > That is exactly what is written above.
>
> Sorry, I don't understand: what is written above?
?
"Emacs, instead of sending a rightward cursor movement
(\e[C), sends \009\008 (a tabulation and a leftward cursor movement)"
that is the optimization that disturbs some terminals such as rxvt or
vte.
Samuel
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#78474; Package
emacs.
(Sun, 18 May 2025 08:58:02 GMT)
Full text and
rfc822 format available.
Message #20 received at 78474 <at> debbugs.gnu.org (full text, mbox):
Samuel Thibault <samuel.thibault <at> gnu.org> writes:
> "Emacs, instead of sending a rightward cursor movement
> (\e[C), sends \009\008 (a tabulation and a leftward cursor movement)"
I'd describe it as the result of the "optimization" rather than the
optimization itself...
Line 90 of cm.c, there is this if clause that leads to a comment:
if (tty->Wcm->cm_magicwrap)
; /* "limbo" */
I guess rxvt and vte implement a variant of magicwrap that is not
handled by addcol, which leaves the cursor in "limbo" state.
Maybe Samuel you can give details on how rxvt vte handle auto/magic
wrapping and, perhaps, how addcol should be fixed?
I don't see any interaction between addcol and evalcost but I might
be wrong.
--
Bastien
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#78474; Package
emacs.
(Sun, 18 May 2025 09:19:01 GMT)
Full text and
rfc822 format available.
Message #23 received at 78474 <at> debbugs.gnu.org (full text, mbox):
> Date: Sun, 18 May 2025 10:30:01 +0200
> From: Samuel Thibault <samuel.thibault <at> gnu.org>
> Cc: bzg <at> gnu.org, 78474 <at> debbugs.gnu.org, Sebastien.Hinderer <at> inria.fr
>
> Eli Zaretskii, le dim. 18 mai 2025 11:05:49 +0300, a ecrit:
> > > Eli Zaretskii, le dim. 18 mai 2025 08:13:58 +0300, a ecrit:
> > > > > Quoting Samuel: "Emacs, instead of sending a rightward cursor movement
> > > > > (\e[C), sends \009\008 (a tabulation and a leftward cursor movement)"
> > > >
> > > > If Sébastien or Samuel (or someone else) can help us understand how to
> > > > modify the cost calculations and/or what optimizations of cursor
> > > > motion to avoid when these technologies for the visually impaired are
> > > > used, we could see how to fix this.
> > >
> > > That is exactly what is written above.
> >
> > Sorry, I don't understand: what is written above?
>
> ?
>
> "Emacs, instead of sending a rightward cursor movement
> (\e[C), sends \009\008 (a tabulation and a leftward cursor movement)"
>
> that is the optimization that disturbs some terminals such as rxvt or
> vte.
Yes, but what does that mean in general? Should Emacs refrain from
sending TAB in all the cases? Are there other characters that should
not be sent for similar reasons?
To modify the code, it is not enough to understand what should be done
in this specific case, we need to better understand the problem and
its various aspects, in order to be able to translate that into code
changes.
Also, I'm a bit confused: you say that sending \009\008 disturbs rxvt
or vte, but the original report seemed to be not about what the
terminals do, but about what that causes to the various software
solutions for the visually impaired. Can you please tell more about
this to resolve the confusion?
Thanks.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#78474; Package
emacs.
(Sun, 18 May 2025 09:27:02 GMT)
Full text and
rfc822 format available.
Message #26 received at 78474 <at> debbugs.gnu.org (full text, mbox):
Hello,
Bastien Guerry, le dim. 18 mai 2025 10:54:50 +0200, a ecrit:
> Samuel Thibault <samuel.thibault <at> gnu.org> writes:
>
> > "Emacs, instead of sending a rightward cursor movement
> > (\e[C), sends \009\008 (a tabulation and a leftward cursor movement)"
>
> I'd describe it as the result of the "optimization" rather than the
> optimization itself...
>
> Line 90 of cm.c, there is this if clause that leads to a comment:
>
> if (tty->Wcm->cm_magicwrap)
> ; /* "limbo" */
But this is only about the end of a line? We are not talking about the
end of a line here.
That said, that pointed me to the optimization code in calccost, which
looks at tty->Wcm->cm_usetabs to determine whether to use tabs or not,
which is set from tabs_safe_p and TabWidth. Apparently, using
stty -tabs
does avoid the issue, by making rxvt & vte switch to destructive tabs,
which emacs then knows to avoid just for moving the cursor.
Samuel
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#78474; Package
emacs.
(Sun, 18 May 2025 09:34:01 GMT)
Full text and
rfc822 format available.
Message #29 received at 78474 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii, le dim. 18 mai 2025 12:18:32 +0300, a ecrit:
> > Date: Sun, 18 May 2025 10:30:01 +0200
> > From: Samuel Thibault <samuel.thibault <at> gnu.org>
> > Cc: bzg <at> gnu.org, 78474 <at> debbugs.gnu.org, Sebastien.Hinderer <at> inria.fr
> >
> > Eli Zaretskii, le dim. 18 mai 2025 11:05:49 +0300, a ecrit:
> > > > Eli Zaretskii, le dim. 18 mai 2025 08:13:58 +0300, a ecrit:
> > > > > > Quoting Samuel: "Emacs, instead of sending a rightward cursor movement
> > > > > > (\e[C), sends \009\008 (a tabulation and a leftward cursor movement)"
> > > > >
> > > > > If Sébastien or Samuel (or someone else) can help us understand how to
> > > > > modify the cost calculations and/or what optimizations of cursor
> > > > > motion to avoid when these technologies for the visually impaired are
> > > > > used, we could see how to fix this.
> > > >
> > > > That is exactly what is written above.
> > >
> > > Sorry, I don't understand: what is written above?
> >
> > ?
> >
> > "Emacs, instead of sending a rightward cursor movement
> > (\e[C), sends \009\008 (a tabulation and a leftward cursor movement)"
> >
> > that is the optimization that disturbs some terminals such as rxvt or
> > vte.
>
> Yes, but what does that mean in general? Should Emacs refrain from
> sending TAB in all the cases?
At least, having an option to avoid this optimization would be useful.
> Are there other characters that should not be sent for similar
> reasons?
I'm not aware of any other character movement sequence that would be
confused with text addition.
> Also, I'm a bit confused: you say that sending \009\008 disturbs rxvt
> or vte, but the original report seemed to be not about what the
> terminals do, but about what that causes to the various software
> solutions for the visually impaired. Can you please tell more about
> this to resolve the confusion?
The eventual issue is that what when typing "coucou " in emacs, what
ends up sent by emacs to vte is "coucou\x09\x08", and what vte exposes
to accessibility technologies is "coucou\t", and it is then unable to
expose to them that the cursor position is in the middle of that "\t".
And it happens that rxvt gets a similar confusion, leading to that wide
cursor appearance
https://dept-info.labri.fr/~thibault/tmp/coucou.png
Samuel
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#78474; Package
emacs.
(Sun, 18 May 2025 09:40:02 GMT)
Full text and
rfc822 format available.
Message #32 received at 78474 <at> debbugs.gnu.org (full text, mbox):
On Mai 18 2025, Bastien Guerry wrote:
> Line 90 of cm.c, there is this if clause that leads to a comment:
That line is inside a #if 0 block.
--
Andreas Schwab, schwab <at> linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1
"And now for something completely different."
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#78474; Package
emacs.
(Fri, 11 Jul 2025 15:24:01 GMT)
Full text and
rfc822 format available.
Message #35 received at 78474 <at> debbugs.gnu.org (full text, mbox):
Is there anyone working on this?
It's beyond my skills, but I'd hate to see this bug closed due to lack
of activity/interest. Let me know if I can help somehow.
--
Bastien Guerry
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#78474; Package
emacs.
(Fri, 11 Jul 2025 17:33:01 GMT)
Full text and
rfc822 format available.
Message #38 received at 78474 <at> debbugs.gnu.org (full text, mbox):
>>>>> On Fri, 11 Jul 2025 17:20:52 +0200, Bastien Guerry <bzg <at> gnu.org> said:
Bastien> Is there anyone working on this?
Bastien> It's beyond my skills, but I'd hate to see this bug closed due to lack
Bastien> of activity/interest. Let me know if I can help somehow.
I can take a look at it. Eli, a clue as to where this optimization
happens in the redisplay code?
Robert
--
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#78474; Package
emacs.
(Fri, 11 Jul 2025 18:58:02 GMT)
Full text and
rfc822 format available.
Message #41 received at 78474 <at> debbugs.gnu.org (full text, mbox):
> From: Bastien Guerry <bzg <at> gnu.org>
> Cc: Eli Zaretskii <eliz <at> gnu.org>, 78474 <at> debbugs.gnu.org,
> Sebastien.Hinderer <at> inria.fr
> Date: Fri, 11 Jul 2025 17:20:52 +0200
>
> Is there anyone working on this?
>
> It's beyond my skills, but I'd hate to see this bug closed due to lack
> of activity/interest. Let me know if I can help somehow.
Sorry, there's not enough useful information in this discussion to
make any progress.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#78474; Package
emacs.
(Fri, 11 Jul 2025 19:08:02 GMT)
Full text and
rfc822 format available.
Message #44 received at 78474 <at> debbugs.gnu.org (full text, mbox):
> From: Robert Pluim <rpluim <at> gmail.com>
> Cc: Samuel Thibault <samuel.thibault <at> gnu.org>, 78474 <at> debbugs.gnu.org, Eli
> Zaretskii <eliz <at> gnu.org>, Sebastien.Hinderer <at> inria.fr
> Date: Fri, 11 Jul 2025 19:32:43 +0200
>
> >>>>> On Fri, 11 Jul 2025 17:20:52 +0200, Bastien Guerry <bzg <at> gnu.org> said:
>
> Bastien> Is there anyone working on this?
> Bastien> It's beyond my skills, but I'd hate to see this bug closed due to lack
> Bastien> of activity/interest. Let me know if I can help somehow.
>
> I can take a look at it. Eli, a clue as to where this optimization
> happens in the redisplay code?
I mentioned that up-thread: it's in cm.c.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#78474; Package
emacs.
(Wed, 16 Jul 2025 15:44:01 GMT)
Full text and
rfc822 format available.
Message #47 received at 78474 <at> debbugs.gnu.org (full text, mbox):
>>>>> On Fri, 11 Jul 2025 22:06:25 +0300, Eli Zaretskii <eliz <at> gnu.org> said:
>> From: Robert Pluim <rpluim <at> gmail.com>
>> Cc: Samuel Thibault <samuel.thibault <at> gnu.org>, 78474 <at> debbugs.gnu.org, Eli
>> Zaretskii <eliz <at> gnu.org>, Sebastien.Hinderer <at> inria.fr
>> Date: Fri, 11 Jul 2025 19:32:43 +0200
>>
>> >>>>> On Fri, 11 Jul 2025 17:20:52 +0200, Bastien Guerry <bzg <at> gnu.org> said:
>>
Bastien> Is there anyone working on this?
Bastien> It's beyond my skills, but I'd hate to see this bug closed due to lack
Bastien> of activity/interest. Let me know if I can help somehow.
>>
>> I can take a look at it. Eli, a clue as to where this optimization
>> happens in the redisplay code?
Eli> I mentioned that up-thread: it's in cm.c.
Thanks, Iʼd missed that.
cm.c works out the cost of either
- moving past the destination with tabs then moving left
- moving towards the destination with tabs then moving right
- moving right directly to the destination
According to my instrumentation, emitting the 'move right' command
costs 3 times as much as 'emit tab' or 'move left' here, so itʼs an
optimization that makes sense, especially if the destination is far
away.
So I donʼt think a generic 'make tabs expensive' is a good idea, but I
guess we could add a user option to disable the use of tabs for motion
on ttys.
Robert
--
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#78474; Package
emacs.
(Thu, 17 Jul 2025 05:32:01 GMT)
Full text and
rfc822 format available.
Message #50 received at 78474 <at> debbugs.gnu.org (full text, mbox):
> From: Robert Pluim <rpluim <at> gmail.com>
> Cc: bzg <at> gnu.org, 78474 <at> debbugs.gnu.org, samuel.thibault <at> gnu.org,
> Sebastien.Hinderer <at> inria.fr
> Date: Wed, 16 Jul 2025 17:43:49 +0200
>
> >>>>> On Fri, 11 Jul 2025 22:06:25 +0300, Eli Zaretskii <eliz <at> gnu.org> said:
>
> >> From: Robert Pluim <rpluim <at> gmail.com>
> >> Cc: Samuel Thibault <samuel.thibault <at> gnu.org>, 78474 <at> debbugs.gnu.org, Eli
> >> Zaretskii <eliz <at> gnu.org>, Sebastien.Hinderer <at> inria.fr
> >> Date: Fri, 11 Jul 2025 19:32:43 +0200
> >>
> >> >>>>> On Fri, 11 Jul 2025 17:20:52 +0200, Bastien Guerry <bzg <at> gnu.org> said:
> >>
> Bastien> Is there anyone working on this?
> Bastien> It's beyond my skills, but I'd hate to see this bug closed due to lack
> Bastien> of activity/interest. Let me know if I can help somehow.
> >>
> >> I can take a look at it. Eli, a clue as to where this optimization
> >> happens in the redisplay code?
>
> Eli> I mentioned that up-thread: it's in cm.c.
>
> Thanks, Iʼd missed that.
>
> cm.c works out the cost of either
>
> - moving past the destination with tabs then moving left
> - moving towards the destination with tabs then moving right
> - moving right directly to the destination
>
> According to my instrumentation, emitting the 'move right' command
> costs 3 times as much as 'emit tab' or 'move left' here, so itʼs an
> optimization that makes sense, especially if the destination is far
> away.
>
> So I donʼt think a generic 'make tabs expensive' is a good idea, but I
> guess we could add a user option to disable the use of tabs for motion
> on ttys.
Feel free to suggest a patch with such a variable.
We should also think how to make the accessibility-related knobs more
discoverable. Perhaps a new section in the user manual is in order.
Thanks.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#78474; Package
emacs.
(Mon, 21 Jul 2025 12:14:01 GMT)
Full text and
rfc822 format available.
Message #53 received at 78474 <at> debbugs.gnu.org (full text, mbox):
>>>>> On Thu, 17 Jul 2025 08:30:44 +0300, Eli Zaretskii <eliz <at> gnu.org> said:
Eli> Feel free to suggest a patch with such a variable.
See below. I have zero ego about the name of the option.
Perhaps the "stty -tabs" workaround should go into PROBLEMS.
Eli> We should also think how to make the accessibility-related knobs more
Eli> discoverable. Perhaps a new section in the user manual is in order.
Indeed, I didnʼt find a good place to put this. What else would go in
this new node apart from this new user option? `text-scale-increase',
I guess, and discussion of the high-contrast themes.
(did anyone ever (re-)implement sticky modifier keys for Emacs? Thatʼs
about the only thing I miss from XEmacs)
Robert
--
diff --git c/etc/NEWS i/etc/NEWS
index f7aebdf538f..637df26d246 100644
--- c/etc/NEWS
+++ i/etc/NEWS
@@ -78,6 +78,13 @@ the 'standard-display-table's extra slots with Unicode characters.
Please see the documentation of that function to see which slots of the
display table it changes.
++++
+** New user option 'tty-allow-tabs-for-motion'.
+The display optimization where TAB characters may be used to move around
+on a TTY frame can now be disabled by customizing the user option
+'tty-allow-tabs-for-motion' to nil (default t). This is to accomodate
+screen readers which may interpret those TAB characters literally.
+
+++
** Child frames are now supported on TTY frames.
This supports use-cases like Posframe, Corfu, and child frames acting
diff --git c/lisp/cus-start.el i/lisp/cus-start.el
index 09364b68e11..d74459657f3 100644
--- c/lisp/cus-start.el
+++ i/lisp/cus-start.el
@@ -602,6 +602,7 @@ minibuffer-prompt-properties--setter
"21.1")
;; term.c
(visible-cursor cursor boolean "22.1")
+ (tty-allow-tabs-for-motion cursor boolean "31.1")
;; terminal.c
(ring-bell-function display
(choice
diff --git c/src/cm.c i/src/cm.c
index 150d1c9a580..a464fd5d0d4 100644
--- c/src/cm.c
+++ i/src/cm.c
@@ -225,7 +225,8 @@ calccost (struct tty_display_info *tty,
goto dodelta; /* skip all the tab junk */
}
/* Tabs (the toughie) */
- if (tty->Wcm->cc_tab >= BIG || !tty->Wcm->cm_usetabs)
+ if (!tty_allow_tabs_for_motion /* Bug#78474. */
+ || tty->Wcm->cc_tab >= BIG || !tty->Wcm->cm_usetabs)
goto olddelta; /* forget it! */
/*
diff --git c/src/term.c i/src/term.c
index 8aa47322d19..acb21c66e05 100644
--- c/src/term.c
+++ i/src/term.c
@@ -5167,6 +5167,17 @@ syms_of_term (void)
trigger redisplay. */);
tty_menu_calls_mouse_position_function = 0;
+ DEFVAR_BOOL ("tty-allow-tabs-for-motion", tty_allow_tabs_for_motion,
+ doc: /* Whether TTY frames may use TAB characters for moving around.
+As a display optimization, Emacs may move between two positions on a TTY
+frame by emitting TAB characters, combined with TTY motion commands,
+when this is more efficient than using only motion commands. These
+characters can interfere with the functioning of some software, such as
+screen readers, which interpret the TAB characters literally. Set this
+to nil to disable this optimization, but be warned that this may affect
+redisplay performance. */);
+ tty_allow_tabs_for_motion = 1;
+
defsubr (&Stty_display_color_p);
defsubr (&Stty_display_color_cells);
defsubr (&Stty_no_underline);
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#78474; Package
emacs.
(Mon, 21 Jul 2025 12:53:01 GMT)
Full text and
rfc822 format available.
Message #56 received at 78474 <at> debbugs.gnu.org (full text, mbox):
> From: Robert Pluim <rpluim <at> gmail.com>
> Cc: bzg <at> gnu.org, 78474 <at> debbugs.gnu.org, samuel.thibault <at> gnu.org,
> Sebastien.Hinderer <at> inria.fr
> Date: Mon, 21 Jul 2025 14:12:54 +0200
>
> >>>>> On Thu, 17 Jul 2025 08:30:44 +0300, Eli Zaretskii <eliz <at> gnu.org> said:
>
> Eli> Feel free to suggest a patch with such a variable.
>
> See below. I have zero ego about the name of the option.
See below.
> Perhaps the "stty -tabs" workaround should go into PROBLEMS.
A good idea, but please add that to PROBLEMS on the release branch
(unlike the rest of the patch).
> Eli> We should also think how to make the accessibility-related knobs more
> Eli> discoverable. Perhaps a new section in the user manual is in order.
>
> Indeed, I didnʼt find a good place to put this. What else would go in
> this new node apart from this new user option? `text-scale-increase',
> I guess, and discussion of the high-contrast themes.
Also w32-use-visible-system-caret (a link to the relevant appendix
should be enough). Hopefully, the list will grow.
> (did anyone ever (re-)implement sticky modifier keys for Emacs? Thatʼs
> about the only thing I miss from XEmacs)
Are there nowadays systems which don't have this built-in?
> +** New user option 'tty-allow-tabs-for-motion'.
I suggest 'cursor-motion-use-tabs' instead.
Thanks.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#78474; Package
emacs.
(Mon, 21 Jul 2025 14:13:02 GMT)
Full text and
rfc822 format available.
Message #59 received at 78474 <at> debbugs.gnu.org (full text, mbox):
Hello,
I apologize in advance if my question is stupid, I have been able to
follow the discussion only from afar.
Is the proposed solution going to work out of the box, or is theuser who
will need it going to have to enable it and what we are discussing is
how easy it will be for that user to discover how?
Again sorry if the answer is obvious and I simply missed it.
Seb.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#78474; Package
emacs.
(Mon, 21 Jul 2025 14:13:03 GMT)
Full text and
rfc822 format available.
Message #62 received at 78474 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii (2025/07/21 15:52 +0300):
> Are there nowadays systems which don't have this built-in?
I am not sure theLinux console does.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#78474; Package
emacs.
(Mon, 21 Jul 2025 14:18:02 GMT)
Full text and
rfc822 format available.
Message #65 received at 78474 <at> debbugs.gnu.org (full text, mbox):
> Date: Mon, 21 Jul 2025 16:04:43 +0200
> From: Seb Hinderer <Sebastien.Hinderer <at> inria.fr>
> Cc: Eli Zaretskii <eliz <at> gnu.org>, bzg <at> gnu.org, 78474 <at> debbugs.gnu.org,
> samuel.thibault <at> gnu.org
>
> Hello,
>
> I apologize in advance if my question is stupid, I have been able to
> follow the discussion only from afar.
>
> Is the proposed solution going to work out of the box, or is theuser who
> will need it going to have to enable it and what we are discussing is
> how easy it will be for that user to discover how?
The user will need to customize the option to disable the use of tabs.
We plan on describing the option in the Emacs user manual, in a
special section dedicated to accessibility-related features. I hope
this will be discoverable enough.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#78474; Package
emacs.
(Mon, 21 Jul 2025 14:20:02 GMT)
Full text and
rfc822 format available.
Message #68 received at 78474 <at> debbugs.gnu.org (full text, mbox):
> Date: Mon, 21 Jul 2025 16:07:13 +0200
> From: Seb Hinderer <Sebastien.Hinderer <at> inria.fr>
> Cc: Robert Pluim <rpluim <at> gmail.com>, bzg <at> gnu.org, 78474 <at> debbugs.gnu.org,
> samuel.thibault <at> gnu.org
>
> Eli Zaretskii (2025/07/21 15:52 +0300):
> > Are there nowadays systems which don't have this built-in?
>
> I am not sure theLinux console does.
It isn't a feature of the console, I think, it's a feature of the
keyboard input subsystem.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#78474; Package
emacs.
(Mon, 21 Jul 2025 14:21:01 GMT)
Full text and
rfc822 format available.
Message #71 received at 78474 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
>>>>> On Mon, 21 Jul 2025 15:52:31 +0300, Eli Zaretskii <eliz <at> gnu.org> said:
>> From: Robert Pluim <rpluim <at> gmail.com>
>> Cc: bzg <at> gnu.org, 78474 <at> debbugs.gnu.org, samuel.thibault <at> gnu.org,
>> Sebastien.Hinderer <at> inria.fr
>> Date: Mon, 21 Jul 2025 14:12:54 +0200
>>
>> >>>>> On Thu, 17 Jul 2025 08:30:44 +0300, Eli Zaretskii <eliz <at> gnu.org> said:
>>
Eli> Feel free to suggest a patch with such a variable.
>>
>> See below. I have zero ego about the name of the option.
Eli> See below.
>> Perhaps the "stty -tabs" workaround should go into PROBLEMS.
Eli> A good idea, but please add that to PROBLEMS on the release branch
Eli> (unlike the rest of the patch).
Done
Eli> We should also think how to make the accessibility-related knobs more
Eli> discoverable. Perhaps a new section in the user manual is in order.
>>
>> Indeed, I didnʼt find a good place to put this. What else would go in
>> this new node apart from this new user option? `text-scale-increase',
>> I guess, and discussion of the high-contrast themes.
Eli> Also w32-use-visible-system-caret (a link to the relevant appendix
Eli> should be enough). Hopefully, the list will grow.
OK, Iʼve put this on my list. Could we point at EmacsSpeak as well?
>> (did anyone ever (re-)implement sticky modifier keys for Emacs? Thatʼs
>> about the only thing I miss from XEmacs)
Eli> Are there nowadays systems which don't have this built-in?
>> +** New user option 'tty-allow-tabs-for-motion'.
Eli> I suggest 'cursor-motion-use-tabs' instead.
Done. Patch attached, without any manual changes, for now.
Robert
--
[0001-Allow-disabling-use-of-TABS-for-motion-on-TTYs-Bug-7.patch (text/x-diff, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#78474; Package
emacs.
(Mon, 21 Jul 2025 14:28:02 GMT)
Full text and
rfc822 format available.
Message #74 received at 78474 <at> debbugs.gnu.org (full text, mbox):
>>>>> On Mon, 21 Jul 2025 17:18:58 +0300, Eli Zaretskii <eliz <at> gnu.org> said:
>> Date: Mon, 21 Jul 2025 16:07:13 +0200
>> From: Seb Hinderer <Sebastien.Hinderer <at> inria.fr>
>> Cc: Robert Pluim <rpluim <at> gmail.com>, bzg <at> gnu.org, 78474 <at> debbugs.gnu.org,
>> samuel.thibault <at> gnu.org
>>
>> Eli Zaretskii (2025/07/21 15:52 +0300):
>> > Are there nowadays systems which don't have this built-in?
>>
>> I am not sure theLinux console does.
Eli> It isn't a feature of the console, I think, it's a feature of the
Eli> keyboard input subsystem.
All the systems I use have a way to turn on a 'sticky keys' or similar
feature. But theyʼre all different, and I access different Emacs
running on different target systems from different source systems. So
it would be nice if there was a way to enable it in Emacs instead of
changing the configuration of the system where I happen to be typing
from. But itʼs less of problem now that my Ctrl key is next to the
space bar everywhere 😀
Robert
--
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#78474; Package
emacs.
(Mon, 21 Jul 2025 14:36:02 GMT)
Full text and
rfc822 format available.
Message #77 received at 78474 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii (2025/07/21 17:17 +0300):
> > Date: Mon, 21 Jul 2025 16:04:43 +0200
> > From: Seb Hinderer <Sebastien.Hinderer <at> inria.fr>
> > Cc: Eli Zaretskii <eliz <at> gnu.org>, bzg <at> gnu.org, 78474 <at> debbugs.gnu.org,
> > samuel.thibault <at> gnu.org
> >
> > Hello,
> >
> > I apologize in advance if my question is stupid, I have been able to
> > follow the discussion only from afar.
> >
> > Is the proposed solution going to work out of the box, or is theuser who
> > will need it going to have to enable it and what we are discussing is
> > how easy it will be for that user to discover how?
>
> The user will need to customize the option to disable the use of tabs.
>
> We plan on describing the option in the Emacs user manual, in a
> special section dedicated to accessibility-related features. I hope
> this will be discoverable enough.
Okay, thanks. Let me first say that I do appreciate the effort and
sincere will to make tools accessible. Also, I am not especially fond of
the posture of the person who is never happy withanything, even when
others do efforts. In general I try very hard not to be such a person,
but...
I would like to emphasize that, generally speaking, ifsomebody is in
need of accessibility, one can quite reasonably assume that the life of
this person is already rather hard. So I tend to be of the opinion that,
as easy as the discoverability of such options may be, it still leaves
the «configuration burden»on the shoulders of people who already have a
lot to tinker with.
This leads me to the suggestion that the configuration where tab is not
used is the one enabled by default, leaving the configuraitn burden to
those to whom performance matters enough for them to care.
Apologies if at any stage I misunderstood theproblem, I am not strongly
attached to my point of view and ready to change my mind, especially if
I am being proven wrong.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#78474; Package
emacs.
(Mon, 21 Jul 2025 14:54:01 GMT)
Full text and
rfc822 format available.
Message #80 received at 78474 <at> debbugs.gnu.org (full text, mbox):
>>>>> On Mon, 21 Jul 2025 16:35:05 +0200, Seb Hinderer <Sebastien.Hinderer <at> inria.fr> said:
Seb> Eli Zaretskii (2025/07/21 17:17 +0300):
>> > Date: Mon, 21 Jul 2025 16:04:43 +0200
>> > From: Seb Hinderer <Sebastien.Hinderer <at> inria.fr>
>> > Cc: Eli Zaretskii <eliz <at> gnu.org>, bzg <at> gnu.org, 78474 <at> debbugs.gnu.org,
>> > samuel.thibault <at> gnu.org
>> >
>> > Hello,
>> >
>> > I apologize in advance if my question is stupid, I have been able to
>> > follow the discussion only from afar.
>> >
>> > Is the proposed solution going to work out of the box, or is theuser who
>> > will need it going to have to enable it and what we are discussing is
>> > how easy it will be for that user to discover how?
>>
>> The user will need to customize the option to disable the use of tabs.
>>
>> We plan on describing the option in the Emacs user manual, in a
>> special section dedicated to accessibility-related features. I hope
>> this will be discoverable enough.
Seb> Okay, thanks. Let me first say that I do appreciate the effort and
Seb> sincere will to make tools accessible. Also, I am not especially fond of
Seb> the posture of the person who is never happy withanything, even when
Seb> others do efforts. In general I try very hard not to be such a person,
Seb> but...
Seb> I would like to emphasize that, generally speaking, ifsomebody is in
Seb> need of accessibility, one can quite reasonably assume that the life of
Seb> this person is already rather hard. So I tend to be of the opinion that,
Seb> as easy as the discoverability of such options may be, it still leaves
Seb> the «configuration burden»on the shoulders of people who already have a
Seb> lot to tinker with.
Yes. Is there any way of detecting that the screen reader software
weʼre confusing is running? If so, we could add code to disable the
use of TAB for that case.
Seb> This leads me to the suggestion that the configuration where tab is not
Seb> used is the one enabled by default, leaving the configuraitn burden to
Seb> those to whom performance matters enough for them to care.
Thatʼs a valid point of view. The Emacs maintainers need to balance
that against the principle of not breaking backwards compatibility or
introducing performance regressions unless absolutely necessary.
I honestly donʼt know if the performance optimization makes any
difference these days, Iʼll see if I can come up with some kind of
test (does `baud-rate' actually affect anything?).
Seb> Apologies if at any stage I misunderstood theproblem, I am not strongly
Seb> attached to my point of view and ready to change my mind, especially if
Seb> I am being proven wrong.
No worries. Only the Sith deal in absolutes 😉
Robert
--
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#78474; Package
emacs.
(Mon, 21 Jul 2025 15:13:01 GMT)
Full text and
rfc822 format available.
Message #83 received at 78474 <at> debbugs.gnu.org (full text, mbox):
> Date: Mon, 21 Jul 2025 16:35:05 +0200
> From: Seb Hinderer <Sebastien.Hinderer <at> inria.fr>
> Cc: rpluim <at> gmail.com, bzg <at> gnu.org, 78474 <at> debbugs.gnu.org,
> samuel.thibault <at> gnu.org
>
> This leads me to the suggestion that the configuration where tab is not
> used is the one enabled by default, leaving the configuraitn burden to
> those to whom performance matters enough for them to care.
I see where you're coming from, but IMO such a change can only fly if
we enabled this new behavior when some screen-reading software is in
use. And that requires some means for Emacs to detect this. If
someone knows how to do that on Posix systems, please speak up.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#78474; Package
emacs.
(Mon, 21 Jul 2025 15:35:01 GMT)
Full text and
rfc822 format available.
Message #86 received at 78474 <at> debbugs.gnu.org (full text, mbox):
Hello,
Eli Zaretskii, le lun. 21 juil. 2025 18:12:25 +0300, a ecrit:
> > Date: Mon, 21 Jul 2025 16:35:05 +0200
> > From: Seb Hinderer <Sebastien.Hinderer <at> inria.fr>
> > Cc: rpluim <at> gmail.com, bzg <at> gnu.org, 78474 <at> debbugs.gnu.org,
> > samuel.thibault <at> gnu.org
> >
> > This leads me to the suggestion that the configuration where tab is not
> > used is the one enabled by default, leaving the configuraitn burden to
> > those to whom performance matters enough for them to care.
>
> I see where you're coming from, but IMO such a change can only fly if
> we enabled this new behavior when some screen-reading software is in
> use. And that requires some means for Emacs to detect this. If
> someone knows how to do that on Posix systems, please speak up.
That does not exist in terminals, only in graphical sessions (and it's
not posix, it's gnomish).
Samuel
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#78474; Package
emacs.
(Mon, 21 Jul 2025 15:38:02 GMT)
Full text and
rfc822 format available.
Message #89 received at 78474 <at> debbugs.gnu.org (full text, mbox):
Hello,
Robert Pluim, le lun. 21 juil. 2025 16:53:34 +0200, a ecrit:
> I honestly donʼt know if the performance optimization makes any
> difference these days,
I don't think it will be actually measurable by any mean. The
optimization we are talking about saves transmitting one byte while
making the terminal interpret one more character sequence (tab+backspace
vs arrow-right). In the common case of running emacs in a terminal, I'd
rather guess that the overhead of the additional character sequence
interpretation is most probably way more expensive than the transmission
of an additional byte.
Samuel
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#78474; Package
emacs.
(Mon, 21 Jul 2025 15:44:02 GMT)
Full text and
rfc822 format available.
Message #92 received at 78474 <at> debbugs.gnu.org (full text, mbox):
> Date: Mon, 21 Jul 2025 17:34:22 +0200
> From: Samuel Thibault <samuel.thibault <at> gnu.org>
> Cc: Seb Hinderer <Sebastien.Hinderer <at> inria.fr>, rpluim <at> gmail.com,
> bzg <at> gnu.org, 78474 <at> debbugs.gnu.org
>
> Hello,
>
> Eli Zaretskii, le lun. 21 juil. 2025 18:12:25 +0300, a ecrit:
> > > Date: Mon, 21 Jul 2025 16:35:05 +0200
> > > From: Seb Hinderer <Sebastien.Hinderer <at> inria.fr>
> > > Cc: rpluim <at> gmail.com, bzg <at> gnu.org, 78474 <at> debbugs.gnu.org,
> > > samuel.thibault <at> gnu.org
> > >
> > > This leads me to the suggestion that the configuration where tab is not
> > > used is the one enabled by default, leaving the configuraitn burden to
> > > those to whom performance matters enough for them to care.
> >
> > I see where you're coming from, but IMO such a change can only fly if
> > we enabled this new behavior when some screen-reading software is in
> > use. And that requires some means for Emacs to detect this. If
> > someone knows how to do that on Posix systems, please speak up.
>
> That does not exist in terminals, only in graphical sessions
How come? Screen readers should announce themselves quite prominently
to any system, so I'd be very surprised to hear that they are
invisible on Linux terminals.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#78474; Package
emacs.
(Mon, 21 Jul 2025 15:46:02 GMT)
Full text and
rfc822 format available.
Message #95 received at 78474 <at> debbugs.gnu.org (full text, mbox):
Robert Pluim (2025/07/21 16:53 +0200):
> Yes. Is there any way of detecting that the screen reader software
> weʼre confusing is running? If so, we could add code to disable the
> use of TAB for that case.
As Samuel has explained, no, there is no need to.
Also, if I understand correctly, we are talking about a behaviour which
is buggy even in contexts beyond accessibility, I think it were rxvt
terminals which were mentionned at the beginning of the thread.
So to me, trying to optimize a code which actually does not quite work
everywhere feels like like taking the problem the wrong way as we should
first make the code work everywhere, and then, potentially, try to
optimize it.
> Seb> This leads me to the suggestion that the configuration where tab is not
> Seb> used is the one enabled by default, leaving the configuraitn burden to
> Seb> those to whom performance matters enough for them to care.
>
> Thatʼs a valid point of view. The Emacs maintainers need to balance
> that against the principle of not breaking backwards compatibility or
> introducing performance regressions unless absolutely necessary.
I trust them on those as I have my self no clue on what are the impacts,
neither on performance nor on backward compatibility. I'd assume that,
of the two, backward compatibility is the most critical. Regarding
performance, compared to what web browsers and graphical user interfaces
do, well, I am not sure a few characters are even worht talkinb about,
even though I do not think that the others doing it in a pour way is an
excuse for us to do likewise. ;)
Seb.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#78474; Package
emacs.
(Mon, 21 Jul 2025 15:48:02 GMT)
Full text and
rfc822 format available.
Message #98 received at 78474 <at> debbugs.gnu.org (full text, mbox):
> Date: Mon, 21 Jul 2025 17:37:02 +0200
> From: Samuel Thibault <samuel.thibault <at> gnu.org>
> Cc: Seb Hinderer <Sebastien.Hinderer <at> inria.fr>,
> Eli Zaretskii <eliz <at> gnu.org>, bzg <at> gnu.org, 78474 <at> debbugs.gnu.org
>
> Hello,
>
> Robert Pluim, le lun. 21 juil. 2025 16:53:34 +0200, a ecrit:
> > I honestly donʼt know if the performance optimization makes any
> > difference these days,
>
> I don't think it will be actually measurable by any mean. The
> optimization we are talking about saves transmitting one byte while
> making the terminal interpret one more character sequence (tab+backspace
> vs arrow-right). In the common case of running emacs in a terminal, I'd
> rather guess that the overhead of the additional character sequence
> interpretation is most probably way more expensive than the transmission
> of an additional byte.
There's no interpretation. The bytes are sent and executed by the
video driver. Using tabs can save several spaces or several bytes of
a cursor movement command, and that is not a trivial difference.
So let's please not argue about this. We can only turn this feature
on by default if Emacs can tell, with a sufficient degree of
certainty, that a screen-reading software is in use. Otherwise, users
will need to enable this manually.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#78474; Package
emacs.
(Mon, 21 Jul 2025 15:48:03 GMT)
Full text and
rfc822 format available.
Message #101 received at 78474 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii (2025/07/21 18:43 +0300):
> > Date: Mon, 21 Jul 2025 17:34:22 +0200
> > From: Samuel Thibault <samuel.thibault <at> gnu.org>
> > Cc: Seb Hinderer <Sebastien.Hinderer <at> inria.fr>, rpluim <at> gmail.com,
> > bzg <at> gnu.org, 78474 <at> debbugs.gnu.org
> >
> > Hello,
> >
> > Eli Zaretskii, le lun. 21 juil. 2025 18:12:25 +0300, a ecrit:
> > > > Date: Mon, 21 Jul 2025 16:35:05 +0200
> > > > From: Seb Hinderer <Sebastien.Hinderer <at> inria.fr>
> > > > Cc: rpluim <at> gmail.com, bzg <at> gnu.org, 78474 <at> debbugs.gnu.org,
> > > > samuel.thibault <at> gnu.org
> > > >
> > > > This leads me to the suggestion that the configuration where tab is not
> > > > used is the one enabled by default, leaving the configuraitn burden to
> > > > those to whom performance matters enough for them to care.
> > >
> > > I see where you're coming from, but IMO such a change can only fly if
> > > we enabled this new behavior when some screen-reading software is in
> > > use. And that requires some means for Emacs to detect this. If
> > > someone knows how to do that on Posix systems, please speak up.
> >
> > That does not exist in terminals, only in graphical sessions
>
> How come? Screen readers should announce themselves quite prominently
> to any system,
Can you elaborate why you are thingking so?
> so I'd be very surprised to hear that they are
> invisible on Linux terminals.
Well then, be surprised, they are. Basically the kernel provides
/dev/vcsa and then every tool that needs to monitor the screen reads it.
There is no API for a screen reader to present itself as such because
there has never really been the need for that.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#78474; Package
emacs.
(Mon, 21 Jul 2025 15:48:04 GMT)
Full text and
rfc822 format available.
Message #104 received at 78474 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii, le lun. 21 juil. 2025 18:43:19 +0300, a ecrit:
> > Eli Zaretskii, le lun. 21 juil. 2025 18:12:25 +0300, a ecrit:
> > > > Date: Mon, 21 Jul 2025 16:35:05 +0200
> > > > From: Seb Hinderer <Sebastien.Hinderer <at> inria.fr>
> > > > Cc: rpluim <at> gmail.com, bzg <at> gnu.org, 78474 <at> debbugs.gnu.org,
> > > > samuel.thibault <at> gnu.org
> > > >
> > > > This leads me to the suggestion that the configuration where tab is not
> > > > used is the one enabled by default, leaving the configuraitn burden to
> > > > those to whom performance matters enough for them to care.
> > >
> > > I see where you're coming from, but IMO such a change can only fly if
> > > we enabled this new behavior when some screen-reading software is in
> > > use. And that requires some means for Emacs to detect this. If
> > > someone knows how to do that on Posix systems, please speak up.
> >
> > That does not exist in terminals, only in graphical sessions
>
> How come? Screen readers should announce themselves quite prominently
> to any system, so I'd be very surprised to hear that they are
> invisible on Linux terminals.
They really are, since they just read the content from /dev/vcsa.
Samul
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#78474; Package
emacs.
(Mon, 21 Jul 2025 15:52:02 GMT)
Full text and
rfc822 format available.
Message #107 received at 78474 <at> debbugs.gnu.org (full text, mbox):
> Date: Mon, 21 Jul 2025 17:44:55 +0200
> From: Seb Hinderer <Sebastien.Hinderer <at> inria.fr>
> Cc: Eli Zaretskii <eliz <at> gnu.org>, bzg <at> gnu.org, 78474 <at> debbugs.gnu.org,
> samuel.thibault <at> gnu.org
>
> Robert Pluim (2025/07/21 16:53 +0200):
> > Yes. Is there any way of detecting that the screen reader software
> > weʼre confusing is running? If so, we could add code to disable the
> > use of TAB for that case.
>
> As Samuel has explained, no, there is no need to.
I understood that he said there was no means, not that there was no
need. The need clearly exists -- for Emacs.
> Also, if I understand correctly, we are talking about a behaviour which
> is buggy even in contexts beyond accessibility, I think it were rxvt
> terminals which were mentionned at the beginning of the thread.
I'm not aware of any bugs with this behavior, on any terminal we
support.
This feature is being added for the benefit of users who run
screen-reading software. I'm not aware of any other reasons to
disable the use of tabs in Emacs cursor motion.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#78474; Package
emacs.
(Mon, 21 Jul 2025 15:56:01 GMT)
Full text and
rfc822 format available.
Message #110 received at 78474 <at> debbugs.gnu.org (full text, mbox):
> Date: Mon, 21 Jul 2025 17:47:30 +0200
> From: Seb Hinderer <Sebastien.Hinderer <at> inria.fr>
> Cc: Samuel Thibault <samuel.thibault <at> gnu.org>, rpluim <at> gmail.com,
> bzg <at> gnu.org, 78474 <at> debbugs.gnu.org
>
> Eli Zaretskii (2025/07/21 18:43 +0300):
> > > Date: Mon, 21 Jul 2025 17:34:22 +0200
> > > From: Samuel Thibault <samuel.thibault <at> gnu.org>
> > > Cc: Seb Hinderer <Sebastien.Hinderer <at> inria.fr>, rpluim <at> gmail.com,
> > > bzg <at> gnu.org, 78474 <at> debbugs.gnu.org
> > >
> > > > I see where you're coming from, but IMO such a change can only fly if
> > > > we enabled this new behavior when some screen-reading software is in
> > > > use. And that requires some means for Emacs to detect this. If
> > > > someone knows how to do that on Posix systems, please speak up.
> > >
> > > That does not exist in terminals, only in graphical sessions
> >
> > How come? Screen readers should announce themselves quite prominently
> > to any system,
>
> Can you elaborate why you are thingking so?
Because catching screen output is not an easy feat on modern
platforms.
> > so I'd be very surprised to hear that they are
> > invisible on Linux terminals.
>
> Well then, be surprised, they are. Basically the kernel provides
> /dev/vcsa and then every tool that needs to monitor the screen reads it.
> There is no API for a screen reader to present itself as such because
> there has never really been the need for that.
Then maybe the /dev/vcsa driver itself could be the sign we need? Or
any of those other tools you mention? Anything that happens on those
systems and can serve as a reliable-enough indication of the use of
screen-reading software, will do.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#78474; Package
emacs.
(Mon, 21 Jul 2025 15:59:02 GMT)
Full text and
rfc822 format available.
Message #113 received at 78474 <at> debbugs.gnu.org (full text, mbox):
> Date: Mon, 21 Jul 2025 17:47:37 +0200
> From: Samuel Thibault <samuel.thibault <at> gnu.org>
> Cc: Sebastien.Hinderer <at> inria.fr, rpluim <at> gmail.com, bzg <at> gnu.org,
> 78474 <at> debbugs.gnu.org
>
> > > That does not exist in terminals, only in graphical sessions
> >
> > How come? Screen readers should announce themselves quite prominently
> > to any system, so I'd be very surprised to hear that they are
> > invisible on Linux terminals.
>
> They really are, since they just read the content from /dev/vcsa.
OK, but the reader itself is a program that is loaded into memory,
right? Can those programs be detected somehow? Do they leave some
traces somewhere on the system? E.g., if those programs have known
names, we could scan the processes running on the system and look for
them, if no better method exists.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#78474; Package
emacs.
(Mon, 21 Jul 2025 16:02:02 GMT)
Full text and
rfc822 format available.
Message #116 received at 78474 <at> debbugs.gnu.org (full text, mbox):
> Cc: bzg <at> gnu.org, Sebastien.Hinderer <at> inria.fr, rpluim <at> gmail.com,
> 78474 <at> debbugs.gnu.org
> Date: Mon, 21 Jul 2025 18:58:06 +0300
> From: Eli Zaretskii <eliz <at> gnu.org>
>
> > Date: Mon, 21 Jul 2025 17:47:37 +0200
> > From: Samuel Thibault <samuel.thibault <at> gnu.org>
> > Cc: Sebastien.Hinderer <at> inria.fr, rpluim <at> gmail.com, bzg <at> gnu.org,
> > 78474 <at> debbugs.gnu.org
> >
> > > > That does not exist in terminals, only in graphical sessions
> > >
> > > How come? Screen readers should announce themselves quite prominently
> > > to any system, so I'd be very surprised to hear that they are
> > > invisible on Linux terminals.
> >
> > They really are, since they just read the content from /dev/vcsa.
>
> OK, but the reader itself is a program that is loaded into memory,
> right? Can those programs be detected somehow? Do they leave some
> traces somewhere on the system? E.g., if those programs have known
> names, we could scan the processes running on the system and look for
> them, if no better method exists.
Or maybe some completely indirect indication, not directly related to
screen-readers. For example, is there an indication that the user
activated some accessibility features?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#78474; Package
emacs.
(Mon, 21 Jul 2025 16:02:02 GMT)
Full text and
rfc822 format available.
Message #119 received at 78474 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Eli Zaretskii, le lun. 21 juil. 2025 18:47:07 +0300, a ecrit:
> > Robert Pluim, le lun. 21 juil. 2025 16:53:34 +0200, a ecrit:
> > > I honestly donʼt know if the performance optimization makes any
> > > difference these days,
> >
> > I don't think it will be actually measurable by any mean. The
> > optimization we are talking about saves transmitting one byte while
> > making the terminal interpret one more character sequence (tab+backspace
> > vs arrow-right). In the common case of running emacs in a terminal, I'd
> > rather guess that the overhead of the additional character sequence
> > interpretation is most probably way more expensive than the transmission
> > of an additional byte.
>
> There's no interpretation.
Of course there is.
> The bytes are sent and executed by the video driver.
No, it's the terminal layer.
> Using tabs can save several spaces or several bytes of
> a cursor movement command, and that is not a trivial difference.
But a right-arrow interpretation is quite more trivial than a tab
interpretation plus backspace interpretation.
Really, please come up with actual figures. We can't be trading
performance for accuracy without significant figures.
I have tried the attached test which reproduces both ways and reports
the time to achieve one million iteration, on my system:
- with rxvt: non-optimized way takes ~1.9s, optimized way takes ~2.1s.
- with mate-terminal: non-optimized way takes ~1.8s, optimized way takes
~2.0s.
So on my system at least the "optimized" way is actually slower.
Samuel
[test.c (text/x-csrc, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#78474; Package
emacs.
(Mon, 21 Jul 2025 16:03:02 GMT)
Full text and
rfc822 format available.
Message #122 received at 78474 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii, le lun. 21 juil. 2025 18:51:42 +0300, a ecrit:
> > Date: Mon, 21 Jul 2025 17:44:55 +0200
> > From: Seb Hinderer <Sebastien.Hinderer <at> inria.fr>
> > Cc: Eli Zaretskii <eliz <at> gnu.org>, bzg <at> gnu.org, 78474 <at> debbugs.gnu.org,
> > samuel.thibault <at> gnu.org
> >
> > Robert Pluim (2025/07/21 16:53 +0200):
> > > Yes. Is there any way of detecting that the screen reader software
> > > weʼre confusing is running? If so, we could add code to disable the
> > > use of TAB for that case.
> >
> > As Samuel has explained, no, there is no need to.
>
> I understood that he said there was no means, not that there was no
> need. The need clearly exists -- for Emacs.
>
> > Also, if I understand correctly, we are talking about a behaviour which
> > is buggy even in contexts beyond accessibility, I think it were rxvt
> > terminals which were mentionned at the beginning of the thread.
>
> I'm not aware of any bugs with this behavior, on any terminal we
> support.
It is buggy on rxvt, as the very first mail of this whole thread talks
about:
https://dept-info.labri.fr/~thibault/tmp/coucou.png
The cursor it two times too big.
> This feature is being added for the benefit of users who run
> screen-reading software. I'm not aware of any other reasons to
> disable the use of tabs in Emacs cursor motion.
It's actually even slower on my box.
Samuel
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#78474; Package
emacs.
(Mon, 21 Jul 2025 16:04:02 GMT)
Full text and
rfc822 format available.
Message #125 received at 78474 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii, le lun. 21 juil. 2025 18:54:45 +0300, a ecrit:
> > Eli Zaretskii (2025/07/21 18:43 +0300):
> > > > Date: Mon, 21 Jul 2025 17:34:22 +0200
> > > > From: Samuel Thibault <samuel.thibault <at> gnu.org>
> > > > Cc: Seb Hinderer <Sebastien.Hinderer <at> inria.fr>, rpluim <at> gmail.com,
> > > > bzg <at> gnu.org, 78474 <at> debbugs.gnu.org
> > > >
> > > > > I see where you're coming from, but IMO such a change can only fly if
> > > > > we enabled this new behavior when some screen-reading software is in
> > > > > use. And that requires some means for Emacs to detect this. If
> > > > > someone knows how to do that on Posix systems, please speak up.
> > > >
> > > > That does not exist in terminals, only in graphical sessions
> > >
> > > How come? Screen readers should announce themselves quite prominently
> > > to any system,
> >
> > Can you elaborate why you are thingking so?
>
> Because catching screen output is not an easy feat on modern
> platforms.
It is. Cat /dev/vcs, and you have it.
> > > so I'd be very surprised to hear that they are
> > > invisible on Linux terminals.
> >
> > Well then, be surprised, they are. Basically the kernel provides
> > /dev/vcsa and then every tool that needs to monitor the screen reads it.
> > There is no API for a screen reader to present itself as such because
> > there has never really been the need for that.
>
> Then maybe the /dev/vcsa driver itself could be the sign we need?
It is also used by other tools.
Samuel
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#78474; Package
emacs.
(Mon, 21 Jul 2025 16:04:03 GMT)
Full text and
rfc822 format available.
Message #128 received at 78474 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii, le lun. 21 juil. 2025 18:58:06 +0300, a ecrit:
> > > > That does not exist in terminals, only in graphical sessions
> > >
> > > How come? Screen readers should announce themselves quite prominently
> > > to any system, so I'd be very surprised to hear that they are
> > > invisible on Linux terminals.
> >
> > They really are, since they just read the content from /dev/vcsa.
>
> OK, but the reader itself is a program that is loaded into memory,
> right? Can those programs be detected somehow? Do they leave some
> traces somewhere on the system? E.g., if those programs have known
> names, we could scan the processes running on the system and look for
> them, if no better method exists.
Do you allow me to puke?
Samuel
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#78474; Package
emacs.
(Mon, 21 Jul 2025 16:09:02 GMT)
Full text and
rfc822 format available.
Message #131 received at 78474 <at> debbugs.gnu.org (full text, mbox):
Samuel Thibault, le lun. 21 juil. 2025 18:00:47 +0200, a ecrit:
> I have tried the attached test which reproduces both ways and reports
> the time to achieve one million iteration, on my system:
>
> - with rxvt: non-optimized way takes ~1.9s, optimized way takes ~2.1s.
> - with mate-terminal: non-optimized way takes ~1.8s, optimized way takes
> ~2.0s.
On the Linux console (fbcon)
- non-optimized way takes ~7.2s
- optimized way takes ~10.0s
Samuel
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#78474; Package
emacs.
(Mon, 21 Jul 2025 16:13:02 GMT)
Full text and
rfc822 format available.
Message #134 received at 78474 <at> debbugs.gnu.org (full text, mbox):
Samuel Thibault, le lun. 21 juil. 2025 18:08:28 +0200, a ecrit:
> Samuel Thibault, le lun. 21 juil. 2025 18:00:47 +0200, a ecrit:
> > I have tried the attached test which reproduces both ways and reports
> > the time to achieve one million iteration, on my system:
> >
> > - with rxvt: non-optimized way takes ~1.9s, optimized way takes ~2.1s.
> > - with mate-terminal: non-optimized way takes ~1.8s, optimized way takes
> > ~2.0s.
>
> On the Linux console (fbcon)
> - non-optimized way takes ~7.2s
> - optimized way takes ~10.0s
I also tried through ssh in rxvt, which is a case where the additional
byte is supposed to matter. non-optimized way takes ~5.4s, optimized way
takes ~7.0s...
Samuel
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#78474; Package
emacs.
(Mon, 21 Jul 2025 16:16:02 GMT)
Full text and
rfc822 format available.
Message #137 received at 78474 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii (2025/07/21 18:47 +0300):
> > Date: Mon, 21 Jul 2025 17:37:02 +0200
> > From: Samuel Thibault <samuel.thibault <at> gnu.org>
> > Cc: Seb Hinderer <Sebastien.Hinderer <at> inria.fr>,
> > Eli Zaretskii <eliz <at> gnu.org>, bzg <at> gnu.org, 78474 <at> debbugs.gnu.org
> >
> > Hello,
> >
> > Robert Pluim, le lun. 21 juil. 2025 16:53:34 +0200, a ecrit:
> > > I honestly donʼt know if the performance optimization makes any
> > > difference these days,
> >
> > I don't think it will be actually measurable by any mean. The
> > optimization we are talking about saves transmitting one byte while
> > making the terminal interpret one more character sequence (tab+backspace
> > vs arrow-right). In the common case of running emacs in a terminal, I'd
> > rather guess that the overhead of the additional character sequence
> > interpretation is most probably way more expensive than the transmission
> > of an additional byte.
>
> There's no interpretation. The bytes are sent and executed by the
> video driver. Using tabs can save several spaces or several bytes of
> a cursor movement command, and that is not a trivial difference.
>
> So let's please not argue about this.
Well I must say I remain unconvinced (1) about how trivial or not the
difference is and (2) about, even non-trivial, whether it outweights the
burden for users of accessibility technologies.
> We can only turn this feature
> on by default if Emacs can tell, with a sufficient degree of
> certainty, that a screen-reading software is in use. Otherwise, users
> will need to enable this manually.
One possibility might be if distirbutions have a way to configure once
and for all whether accessibility isneeded and then Emacs' configuration
could select its default based on that.
For the sake of completeness of this discussion, Samuel may want to
share a link on a discussion that happened in the context of the Debian
installer. The topic being discussed there was that visually impaired
people need n audible Beep to know whenthe boot process is done andthey
can tyep an 's' to maketheinstallerspeak. Understandably, havingthe beep
turned on by default was deemed annoying by those testingthe installer
whichwas beepingallthe time. In the end, it was accepted to let the beep
on by default because it was considered that its inconveninece for the
testers was less problematic than the burden it represented to turn it
on for those in need for it, thetrick being to plug a headset to the
computer while testing the installer. Samuel will hopefully correct me
if anything I write is wrong or inaccurate.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#78474; Package
emacs.
(Mon, 21 Jul 2025 16:20:02 GMT)
Full text and
rfc822 format available.
Message #140 received at 78474 <at> debbugs.gnu.org (full text, mbox):
>>>>> On Mon, 21 Jul 2025 18:02:00 +0200, Samuel Thibault <samuel.thibault <at> gnu.org> said:
Samuel> It is buggy on rxvt, as the very first mail of this whole thread talks
Samuel> about:
Samuel> https://dept-info.labri.fr/~thibault/tmp/coucou.png
Samuel> The cursor it two times too big.
Yet another reason to avoid rxvt *ducks*
>> This feature is being added for the benefit of users who run
>> screen-reading software. I'm not aware of any other reasons to
>> disable the use of tabs in Emacs cursor motion.
Samuel> It's actually even slower on my box.
You benchmarked moving by one character. Moving by tabs can move in
multiples of 8 characters, so I doubt itʼs that cut and dried.
My testing shows that itʼs slower to have tabs disabled, in that visiting
src/xdisp.c and pressing C-v repeatedly makes redisplay freeze earlier
than when theyʼre enabled (Emacs eventually catches up).
Robert
--
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#78474; Package
emacs.
(Mon, 21 Jul 2025 16:26:02 GMT)
Full text and
rfc822 format available.
Message #143 received at 78474 <at> debbugs.gnu.org (full text, mbox):
Robert Pluim, le lun. 21 juil. 2025 18:19:24 +0200, a ecrit:
> > >> This feature is being added for the benefit of users who run
> > >> screen-reading software. I'm not aware of any other reasons to
> > >> disable the use of tabs in Emacs cursor motion.
> >
> > Samuel> It's actually even slower on my box.
>
> You benchmarked moving by one character. Moving by tabs can move in
> multiples of 8 characters, so I doubt itʼs that cut and dried.
The case which actually poses problem is only that \t\b vs \e[C. Using
tab without moving back with \b does not pose problem.
Samuel
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#78474; Package
emacs.
(Mon, 21 Jul 2025 16:37:02 GMT)
Full text and
rfc822 format available.
Message #146 received at 78474 <at> debbugs.gnu.org (full text, mbox):
Robert Pluim, le lun. 21 juil. 2025 18:19:24 +0200, a ecrit:
> >>>>> On Mon, 21 Jul 2025 18:02:00 +0200, Samuel Thibault <samuel.thibault <at> gnu.org> said:
>
> Samuel> It is buggy on rxvt, as the very first mail of this whole thread talks
> Samuel> about:
>
> Samuel> https://dept-info.labri.fr/~thibault/tmp/coucou.png
>
> Samuel> The cursor it two times too big.
>
> Yet another reason to avoid rxvt *ducks*
Well, one thing is: I was unabled to find an actual reference on what
*exactly* \t is supposed to be doing for the terminal content. Notably,
run:
echo -e 'a\ta'
and copy/paste that text: do you expect the paste to be 'a\ta' or
'a a' ? I have seen people request for the former.
Also, if you run:
echo -e 'a\t'
is there actually supposed to be some content to copy/paste on the right
of a?
Samuel
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#78474; Package
emacs.
(Mon, 21 Jul 2025 17:03:03 GMT)
Full text and
rfc822 format available.
Message #149 received at 78474 <at> debbugs.gnu.org (full text, mbox):
Samuel Thibault, le lun. 21 juil. 2025 18:35:53 +0200, a ecrit:
> Robert Pluim, le lun. 21 juil. 2025 18:19:24 +0200, a ecrit:
> > >>>>> On Mon, 21 Jul 2025 18:02:00 +0200, Samuel Thibault <samuel.thibault <at> gnu.org> said:
> >
> > Samuel> It is buggy on rxvt, as the very first mail of this whole thread talks
> > Samuel> about:
> >
> > Samuel> https://dept-info.labri.fr/~thibault/tmp/coucou.png
> >
> > Samuel> The cursor it two times too big.
> >
> > Yet another reason to avoid rxvt *ducks*
>
> Well, one thing is: I was unabled to find an actual reference on what
> *exactly* \t is supposed to be doing for the terminal content.
And don't get me wrong, I tried hard, because that's precisely what I'm
missing for getting fixed the behavior of libvte, the only accessible
graphical terminal. They too are waving hands at optimizations which
are making the content wrong. Both emacs and vte are getting borderline
on the precise semantics of \t, and the problem is that they are on
*different* sides.
Samuel
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#78474; Package
emacs.
(Tue, 22 Jul 2025 08:18:02 GMT)
Full text and
rfc822 format available.
Message #152 received at 78474 <at> debbugs.gnu.org (full text, mbox):
>>>>> On Mon, 21 Jul 2025 18:25:05 +0200, Samuel Thibault <samuel.thibault <at> gnu.org> said:
Samuel> Robert Pluim, le lun. 21 juil. 2025 18:19:24 +0200, a ecrit:
>> > >> This feature is being added for the benefit of users who run
>> > >> screen-reading software. I'm not aware of any other reasons to
>> > >> disable the use of tabs in Emacs cursor motion.
>> >
>> > Samuel> It's actually even slower on my box.
>>
>> You benchmarked moving by one character. Moving by tabs can move in
>> multiples of 8 characters, so I doubt itʼs that cut and dried.
Samuel> The case which actually poses problem is only that \t\b vs \e[C. Using
Samuel> tab without moving back with \b does not pose problem.
But Emacs uses \t for motion for more than that one case. Are you
saying that if we change Emacs to avoid only \t\b then vte and rxvt
will be happy? Thatʼs a much less impactful change.
Robert
--
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#78474; Package
emacs.
(Tue, 22 Jul 2025 08:55:02 GMT)
Full text and
rfc822 format available.
Message #155 received at 78474 <at> debbugs.gnu.org (full text, mbox):
Robert Pluim, le mar. 22 juil. 2025 10:17:37 +0200, a ecrit:
> >>>>> On Mon, 21 Jul 2025 18:25:05 +0200, Samuel Thibault <samuel.thibault <at> gnu.org> said:
>
> Samuel> Robert Pluim, le lun. 21 juil. 2025 18:19:24 +0200, a ecrit:
> >> > >> This feature is being added for the benefit of users who run
> >> > >> screen-reading software. I'm not aware of any other reasons to
> >> > >> disable the use of tabs in Emacs cursor motion.
> >> >
> >> > Samuel> It's actually even slower on my box.
> >>
> >> You benchmarked moving by one character. Moving by tabs can move in
> >> multiples of 8 characters, so I doubt itʼs that cut and dried.
>
> Samuel> The case which actually poses problem is only that \t\b vs \e[C. Using
> Samuel> tab without moving back with \b does not pose problem.
>
> But Emacs uses \t for motion for more than that one case. Are you
> saying that if we change Emacs to avoid only \t\b then vte and rxvt
> will be happy?
Yes. That's the only case that we have reported from the beginning.
Samuel
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#78474; Package
emacs.
(Tue, 22 Jul 2025 11:28:02 GMT)
Full text and
rfc822 format available.
Message #158 received at 78474 <at> debbugs.gnu.org (full text, mbox):
> From: Robert Pluim <rpluim <at> gmail.com>
> Cc: Seb Hinderer <Sebastien.Hinderer <at> inria.fr>, bzg <at> gnu.org,
> 78474 <at> debbugs.gnu.org, samuel.thibault <at> gnu.org
> Date: Mon, 21 Jul 2025 16:27:16 +0200
>
> Eli> It isn't a feature of the console, I think, it's a feature of the
> Eli> keyboard input subsystem.
>
> All the systems I use have a way to turn on a 'sticky keys' or similar
> feature. But theyʼre all different, and I access different Emacs
> running on different target systems from different source systems. So
> it would be nice if there was a way to enable it in Emacs instead of
> changing the configuration of the system where I happen to be typing
> from.
I think we will only be able to implement this when the raw-key events
feature is installed? because otherwise, how can we detect the Shift
or Ctrl or Alt keypress, to change state? Or what am I missing?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#78474; Package
emacs.
(Tue, 22 Jul 2025 11:29:01 GMT)
Full text and
rfc822 format available.
Message #161 received at 78474 <at> debbugs.gnu.org (full text, mbox):
> Date: Mon, 21 Jul 2025 18:00:47 +0200
> From: Samuel Thibault <samuel.thibault <at> gnu.org>
> Cc: rpluim <at> gmail.com, Sebastien.Hinderer <at> inria.fr, bzg <at> gnu.org,
> 78474 <at> debbugs.gnu.org
>
> I have tried the attached test which reproduces both ways and reports
> the time to achieve one million iteration, on my system:
>
> - with rxvt: non-optimized way takes ~1.9s, optimized way takes ~2.1s.
> - with mate-terminal: non-optimized way takes ~1.8s, optimized way takes
> ~2.0s.
>
> So on my system at least the "optimized" way is actually slower.
For that particular single case. Not in general.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#78474; Package
emacs.
(Tue, 22 Jul 2025 11:31:01 GMT)
Full text and
rfc822 format available.
Message #164 received at 78474 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii, le mar. 22 juil. 2025 14:28:19 +0300, a ecrit:
> > Date: Mon, 21 Jul 2025 18:00:47 +0200
> > From: Samuel Thibault <samuel.thibault <at> gnu.org>
> > Cc: rpluim <at> gmail.com, Sebastien.Hinderer <at> inria.fr, bzg <at> gnu.org,
> > 78474 <at> debbugs.gnu.org
> >
> > I have tried the attached test which reproduces both ways and reports
> > the time to achieve one million iteration, on my system:
> >
> > - with rxvt: non-optimized way takes ~1.9s, optimized way takes ~2.1s.
> > - with mate-terminal: non-optimized way takes ~1.8s, optimized way takes
> > ~2.0s.
> >
> > So on my system at least the "optimized" way is actually slower.
>
> For that particular single case.
Which is exactly the case that we are reporting about.
Samuel
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#78474; Package
emacs.
(Tue, 22 Jul 2025 11:46:02 GMT)
Full text and
rfc822 format available.
Message #167 received at 78474 <at> debbugs.gnu.org (full text, mbox):
> Date: Mon, 21 Jul 2025 18:02:00 +0200
> From: Samuel Thibault <samuel.thibault <at> gnu.org>
> Cc: Seb Hinderer <Sebastien.Hinderer <at> inria.fr>, rpluim <at> gmail.com,
> bzg <at> gnu.org, 78474 <at> debbugs.gnu.org
>
> Eli Zaretskii, le lun. 21 juil. 2025 18:51:42 +0300, a ecrit:
> > I'm not aware of any bugs with this behavior, on any terminal we
> > support.
>
> It is buggy on rxvt, as the very first mail of this whole thread talks
> about:
>
> https://dept-info.labri.fr/~thibault/tmp/coucou.png
>
> The cursor it two times too big.
Ah, okay. Apologies for forgetting that.
However, that seems a rxvt-specific bug, which should be solved there.
It is only tangentially relevant here. I don't see this on other
terminals; do you?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#78474; Package
emacs.
(Tue, 22 Jul 2025 11:55:01 GMT)
Full text and
rfc822 format available.
Message #170 received at 78474 <at> debbugs.gnu.org (full text, mbox):
> Date: Mon, 21 Jul 2025 18:03:47 +0200
> From: Samuel Thibault <samuel.thibault <at> gnu.org>
> Cc: Sebastien.Hinderer <at> inria.fr, rpluim <at> gmail.com, bzg <at> gnu.org,
> 78474 <at> debbugs.gnu.org
>
> Eli Zaretskii, le lun. 21 juil. 2025 18:58:06 +0300, a ecrit:
> > > > > That does not exist in terminals, only in graphical sessions
> > > >
> > > > How come? Screen readers should announce themselves quite prominently
> > > > to any system, so I'd be very surprised to hear that they are
> > > > invisible on Linux terminals.
> > >
> > > They really are, since they just read the content from /dev/vcsa.
> >
> > OK, but the reader itself is a program that is loaded into memory,
> > right? Can those programs be detected somehow? Do they leave some
> > traces somewhere on the system? E.g., if those programs have known
> > names, we could scan the processes running on the system and look for
> > them, if no better method exists.
>
> Do you allow me to puke?
You can, but it will hardly be useful.
And frankly, I don't understand the attitude. The original request
was to have an option to disable use of TABs for moving the cursor,
see
https://debbugs.gnu.org/cgi/bugreport.cgi?bug=78474#29
Adding such an option is a relatively easy decision, and a preliminary
patch was already posted here to that effect.
But now you have changed the request, and are asking to disable the
TABs by default. That is a much harder decision to make, since the
relevant code is working for us for decades, and disabling TABs will
definitely slow down display on text-mode terminals, especially those
connected via slow-speed connections. So I'm trying hard to find some
way of determining that the user could be using screen reading
software, or some other accessibility features of the OS, to
automatically disable TABs only in those cases. (We do something
similar with system caret on MS-Windows, another accessibility feature
related to screen readers.) IOW, I'm trying to find a way to allow us
to disable TABs in those cases where that matters, instead of asking
the affected users to do that manually. Why this should cause the
above reaction is beyond me.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#78474; Package
emacs.
(Tue, 22 Jul 2025 12:05:02 GMT)
Full text and
rfc822 format available.
Message #173 received at 78474 <at> debbugs.gnu.org (full text, mbox):
> From: Robert Pluim <rpluim <at> gmail.com>
> Cc: Eli Zaretskii <eliz <at> gnu.org>, Seb Hinderer
> <Sebastien.Hinderer <at> inria.fr>, bzg <at> gnu.org, 78474 <at> debbugs.gnu.org
> Date: Mon, 21 Jul 2025 18:19:24 +0200
>
> Samuel> It's actually even slower on my box.
>
> You benchmarked moving by one character. Moving by tabs can move in
> multiples of 8 characters, so I doubt itʼs that cut and dried.
>
> My testing shows that itʼs slower to have tabs disabled, in that visiting
> src/xdisp.c and pressing C-v repeatedly makes redisplay freeze earlier
> than when theyʼre enabled (Emacs eventually catches up).
I have no doubt that the use of TABs speeds up display on average,
because its "cost" notion is based on counting bytes written to the
screen. It chooses the method that writes the smallest number of
bytes, and that must be faster in general.
Of course, specially-tailored cases could be concocted which show the
contrary, but that's not what this code is about. The request in this
bug report, AFAIU, was to disable the use of TABs _in_all_cases_, not
just in the particular case shown by the recipe at the beginning of
the discussion.
For users who use screen-reading software the speed gains are
outweighed by the correctness of the spoken text, so disabling TABs in
those cases makes sense. But if we want to do that automatically, we
should find some reasonably-accurate indication of such uses, like we
do with w32-use-visible-system-caret on MS-Windows. If the number of
false positives is low, we could risk disabling TABs for a small
fraction of users who don't actually use screen readers.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#78474; Package
emacs.
(Tue, 22 Jul 2025 12:06:02 GMT)
Full text and
rfc822 format available.
Message #176 received at 78474 <at> debbugs.gnu.org (full text, mbox):
> Date: Mon, 21 Jul 2025 18:03:19 +0200
> From: Samuel Thibault <samuel.thibault <at> gnu.org>
> Cc: Seb Hinderer <Sebastien.Hinderer <at> inria.fr>, rpluim <at> gmail.com,
> bzg <at> gnu.org, 78474 <at> debbugs.gnu.org
>
> Eli Zaretskii, le lun. 21 juil. 2025 18:54:45 +0300, a ecrit:
> > > > How come? Screen readers should announce themselves quite prominently
> > > > to any system,
> > >
> > > Can you elaborate why you are thingking so?
> >
> > Because catching screen output is not an easy feat on modern
> > platforms.
>
> It is. Cat /dev/vcs, and you have it.
When I do that on a GNU/Linux system to which I have access, I get:
$ cat /dev/vcs
cat: /dev/vcs: Permission denied
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#78474; Package
emacs.
(Tue, 22 Jul 2025 12:07:02 GMT)
Full text and
rfc822 format available.
Message #179 received at 78474 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii, le mar. 22 juil. 2025 14:45:15 +0300, a ecrit:
> > Date: Mon, 21 Jul 2025 18:02:00 +0200
> > From: Samuel Thibault <samuel.thibault <at> gnu.org>
> > Cc: Seb Hinderer <Sebastien.Hinderer <at> inria.fr>, rpluim <at> gmail.com,
> > bzg <at> gnu.org, 78474 <at> debbugs.gnu.org
> >
> > Eli Zaretskii, le lun. 21 juil. 2025 18:51:42 +0300, a ecrit:
> > > I'm not aware of any bugs with this behavior, on any terminal we
> > > support.
> >
> > It is buggy on rxvt, as the very first mail of this whole thread talks
> > about:
> >
> > https://dept-info.labri.fr/~thibault/tmp/coucou.png
> >
> > The cursor it two times too big.
>
> Ah, okay. Apologies for forgetting that.
>
> However, that seems a rxvt-specific bug, which should be solved there.
It's also in vte, where it matters for accessibility. And we have a
*hard* time getting it fixed (the upstream bug has been lying there for
a decade already).
We mentioned rxvt because it is easy to see it there.
And again, I have not yet found a document that explicitly says what
terminals are supposed to do for the content.
Samuel
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#78474; Package
emacs.
(Tue, 22 Jul 2025 12:09:02 GMT)
Full text and
rfc822 format available.
Message #182 received at 78474 <at> debbugs.gnu.org (full text, mbox):
> Date: Mon, 21 Jul 2025 18:25:05 +0200
> From: Samuel Thibault <samuel.thibault <at> gnu.org>
> Cc: Eli Zaretskii <eliz <at> gnu.org>,
> Seb Hinderer <Sebastien.Hinderer <at> inria.fr>, bzg <at> gnu.org,
> 78474 <at> debbugs.gnu.org
>
> > > Samuel> It's actually even slower on my box.
> >
> > You benchmarked moving by one character. Moving by tabs can move in
> > multiples of 8 characters, so I doubt itʼs that cut and dried.
>
> The case which actually poses problem is only that \t\b vs \e[C. Using
> tab without moving back with \b does not pose problem.
If that's the only problematic case, then disabling TABs as in the
proposed patch is not TRT.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#78474; Package
emacs.
(Tue, 22 Jul 2025 12:10:02 GMT)
Full text and
rfc822 format available.
Message #185 received at 78474 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii, le mar. 22 juil. 2025 15:03:52 +0300, a ecrit:
> Of course, specially-tailored cases could be concocted which show the
> contrary, but that's not what this code is about. The request in this
> bug report, AFAIU, was to disable the use of TABs _in_all_cases_,
No.
“
Quoting Samuel: "Emacs, instead of sending a rightward cursor movement
(\e[C), sends \009\008 (a tabulation and a leftward cursor movement)"
This char insertion problem confuses assistive technologies for the
visually impaired.
”
I don't remember really asking for more than that.
Samuel
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#78474; Package
emacs.
(Tue, 22 Jul 2025 12:11:01 GMT)
Full text and
rfc822 format available.
Message #188 received at 78474 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii, le mar. 22 juil. 2025 15:08:09 +0300, a ecrit:
> > Date: Mon, 21 Jul 2025 18:25:05 +0200
> > From: Samuel Thibault <samuel.thibault <at> gnu.org>
> > Cc: Eli Zaretskii <eliz <at> gnu.org>,
> > Seb Hinderer <Sebastien.Hinderer <at> inria.fr>, bzg <at> gnu.org,
> > 78474 <at> debbugs.gnu.org
> >
> > > > Samuel> It's actually even slower on my box.
> > >
> > > You benchmarked moving by one character. Moving by tabs can move in
> > > multiples of 8 characters, so I doubt itʼs that cut and dried.
> >
> > The case which actually poses problem is only that \t\b vs \e[C. Using
> > tab without moving back with \b does not pose problem.
>
> If that's the only problematic case, then disabling TABs as in the
> proposed patch is not TRT.
I don't think I asked for this, and only confirmed that it's one way to
do it.
Samuel
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#78474; Package
emacs.
(Tue, 22 Jul 2025 12:16:02 GMT)
Full text and
rfc822 format available.
Message #191 received at 78474 <at> debbugs.gnu.org (full text, mbox):
> Date: Mon, 21 Jul 2025 18:35:53 +0200
> From: Samuel Thibault <samuel.thibault <at> gnu.org>
> Cc: Eli Zaretskii <eliz <at> gnu.org>,
> Seb Hinderer <Sebastien.Hinderer <at> inria.fr>, bzg <at> gnu.org,
> 78474 <at> debbugs.gnu.org
>
> Robert Pluim, le lun. 21 juil. 2025 18:19:24 +0200, a ecrit:
> > >>>>> On Mon, 21 Jul 2025 18:02:00 +0200, Samuel Thibault <samuel.thibault <at> gnu.org> said:
> >
> > Samuel> It is buggy on rxvt, as the very first mail of this whole thread talks
> > Samuel> about:
> >
> > Samuel> https://dept-info.labri.fr/~thibault/tmp/coucou.png
> >
> > Samuel> The cursor it two times too big.
> >
> > Yet another reason to avoid rxvt *ducks*
>
> Well, one thing is: I was unabled to find an actual reference on what
> *exactly* \t is supposed to be doing for the terminal content. Notably,
> run:
>
> echo -e 'a\ta'
>
> and copy/paste that text: do you expect the paste to be 'a\ta' or
> 'a a' ? I have seen people request for the former.
What you copy/paste and what is written to the screen are not
necessarily the same thing. The effect of TAB on the screen is to
move the cursor (or the rest of the line's text) to the right by a
suitably-computed number of columns, which depends on the column where
you do that. What is copy/paste'd depends on the program which
serves the copy: some give you TAB, others give you spaces.
> Also, if you run:
>
> echo -e 'a\t'
>
> is there actually supposed to be some content to copy/paste on the right
> of a?
IME, also depends on the program which serves the copy/paste.
(I think these aspects are tangents, not an integral part of this
discussion.)
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#78474; Package
emacs.
(Tue, 22 Jul 2025 12:17:01 GMT)
Full text and
rfc822 format available.
Message #194 received at 78474 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii, le mar. 22 juil. 2025 14:54:27 +0300, a ecrit:
> > Date: Mon, 21 Jul 2025 18:03:47 +0200
> > From: Samuel Thibault <samuel.thibault <at> gnu.org>
> > Cc: Sebastien.Hinderer <at> inria.fr, rpluim <at> gmail.com, bzg <at> gnu.org,
> > 78474 <at> debbugs.gnu.org
> >
> > Eli Zaretskii, le lun. 21 juil. 2025 18:58:06 +0300, a ecrit:
> > > > > > That does not exist in terminals, only in graphical sessions
> > > > >
> > > > > How come? Screen readers should announce themselves quite prominently
> > > > > to any system, so I'd be very surprised to hear that they are
> > > > > invisible on Linux terminals.
> > > >
> > > > They really are, since they just read the content from /dev/vcsa.
> > >
> > > OK, but the reader itself is a program that is loaded into memory,
> > > right? Can those programs be detected somehow? Do they leave some
> > > traces somewhere on the system? E.g., if those programs have known
> > > names, we could scan the processes running on the system and look for
> > > them, if no better method exists.
> >
> > Do you allow me to puke?
>
> You can, but it will hardly be useful.
>
> And frankly, I don't understand the attitude.
I'm sorry, but I also have a hard time understanding the attitude.
This bug is making emacs user have to avoid working in the graphical
desktop environment, because they cannot reliably edit text. And thus
they miss all the graphical tools that everybody else is using. So
they'd have to switch back&forth between textmode and console to do
their work, a very painful experience.
And you are proposing to probe for the existence of a process to decide
the emacs behavior. There has been already half a dozen graphical
screen readers, some of which have even changed name. How can that be
considered a solution when we are talking about just adding one byte...
> The original request was to have an option to disable use of TABs for
> moving the cursor, see
No.
> https://debbugs.gnu.org/cgi/bugreport.cgi?bug=78474#29
*Actually* see the _*original*_ request:
“
Quoting Samuel: "Emacs, instead of sending a rightward cursor movement
(\e[C), sends \009\008 (a tabulation and a leftward cursor movement)"
This char insertion problem confuses assistive technologies for the
visually impaired.
”
Yes. I'm repeating myself. Since you don't seem to be accepting that.
> But now you have changed the request, and are asking to disable the
> TABs by default.
I'm not *asking* for something in particular. I'm asking for a solution
to the *actual* problem, which is \009\008. And not a solution that will
break as soon as somebody creates their own screen reader for their own
use.
Samuel
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#78474; Package
emacs.
(Tue, 22 Jul 2025 12:17:02 GMT)
Full text and
rfc822 format available.
Message #197 received at 78474 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii, le mar. 22 juil. 2025 15:05:27 +0300, a ecrit:
> > Date: Mon, 21 Jul 2025 18:03:19 +0200
> > From: Samuel Thibault <samuel.thibault <at> gnu.org>
> > Cc: Seb Hinderer <Sebastien.Hinderer <at> inria.fr>, rpluim <at> gmail.com,
> > bzg <at> gnu.org, 78474 <at> debbugs.gnu.org
> >
> > Eli Zaretskii, le lun. 21 juil. 2025 18:54:45 +0300, a ecrit:
> > > > > How come? Screen readers should announce themselves quite prominently
> > > > > to any system,
> > > >
> > > > Can you elaborate why you are thingking so?
> > >
> > > Because catching screen output is not an easy feat on modern
> > > platforms.
> >
> > It is. Cat /dev/vcs, and you have it.
>
> When I do that on a GNU/Linux system to which I have access, I get:
>
> $ cat /dev/vcs
> cat: /dev/vcs: Permission denied
Yes, screen readers have always had to be privileged somehow.
Samuel
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#78474; Package
emacs.
(Tue, 22 Jul 2025 12:21:02 GMT)
Full text and
rfc822 format available.
Message #200 received at 78474 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii, le mar. 22 juil. 2025 15:15:28 +0300, a ecrit:
> > Date: Mon, 21 Jul 2025 18:35:53 +0200
> > From: Samuel Thibault <samuel.thibault <at> gnu.org>
> > Cc: Eli Zaretskii <eliz <at> gnu.org>,
> > Seb Hinderer <Sebastien.Hinderer <at> inria.fr>, bzg <at> gnu.org,
> > 78474 <at> debbugs.gnu.org
> >
> > Robert Pluim, le lun. 21 juil. 2025 18:19:24 +0200, a ecrit:
> > > >>>>> On Mon, 21 Jul 2025 18:02:00 +0200, Samuel Thibault <samuel.thibault <at> gnu.org> said:
> > >
> > > Samuel> It is buggy on rxvt, as the very first mail of this whole thread talks
> > > Samuel> about:
> > >
> > > Samuel> https://dept-info.labri.fr/~thibault/tmp/coucou.png
> > >
> > > Samuel> The cursor it two times too big.
> > >
> > > Yet another reason to avoid rxvt *ducks*
> >
> > Well, one thing is: I was unabled to find an actual reference on what
> > *exactly* \t is supposed to be doing for the terminal content. Notably,
> > run:
> >
> > echo -e 'a\ta'
> >
> > and copy/paste that text: do you expect the paste to be 'a\ta' or
> > 'a a' ? I have seen people request for the former.
>
> What you copy/paste and what is written to the screen are not
> necessarily the same thing. The effect of TAB on the screen is to
> move the cursor (or the rest of the line's text) to the right by a
> suitably-computed number of columns, which depends on the column where
> you do that. What is copy/paste'd depends on the program which
> serves the copy: some give you TAB, others give you spaces.
>
> > Also, if you run:
> >
> > echo -e 'a\t'
> >
> > is there actually supposed to be some content to copy/paste on the right
> > of a?
>
> IME, also depends on the program which serves the copy/paste.
>
> (I think these aspects are tangents, not an integral part of this
> discussion.)
They are fully part of the discussion, because that changes what is
actually supposed to be stored in the terminal, and thus what the
accessibility feature is supposed to expose to the user: should it
expose a tab, or spaces. But if a tab, then how can the cursor be inside
the tab when emitting \t\b. That's the *whole* problem at stake.
And thus why I mentioned looking for an actual document that explictly
says that \t is supposed to produce spaces, because for now the vte
maintainer is saying that there is no text there and thus it should not
be exposed to the accessibility layer, but then the cursor is getting
wrong, making emacs essentially unusable as it is now. If I had a text
that explicitly says that \t produces content, it would be way easier
to fix this on the vte side. For now, we have been stuck for a *decade*
there.
Samuel
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#78474; Package
emacs.
(Tue, 22 Jul 2025 12:28:01 GMT)
Full text and
rfc822 format available.
Message #203 received at 78474 <at> debbugs.gnu.org (full text, mbox):
Samuel Thibault, le mar. 22 juil. 2025 14:16:02 +0200, a ecrit:
> And not a solution that will break as soon as somebody creates their
> own screen reader for their own use.
To put some context here: one of the latest screen readers out there,
odilia, is already concerned by the amount of existing workarounds
for accessibility in general. If they bang their head against walls
concerning \t\b, wondering why that works with the well-known orca
screen reader, and not with their own, and end up seeing a hardcoded
list of the screen readers that are fortunate enough to be known enough
to get the proper behavior of emacs in vte, as opposed to the screen
reader that they are trying to write, then yes, I believe they could
almost litteraly throw up.
Samuel
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#78474; Package
emacs.
(Tue, 22 Jul 2025 12:32:01 GMT)
Full text and
rfc822 format available.
Message #206 received at 78474 <at> debbugs.gnu.org (full text, mbox):
>>>>> On Tue, 22 Jul 2025 14:10:11 +0200, Samuel Thibault <samuel.thibault <at> gnu.org> said:
Samuel> Eli Zaretskii, le mar. 22 juil. 2025 15:08:09 +0300, a ecrit:
>> > Date: Mon, 21 Jul 2025 18:25:05 +0200
>> > From: Samuel Thibault <samuel.thibault <at> gnu.org>
>> > Cc: Eli Zaretskii <eliz <at> gnu.org>,
>> > Seb Hinderer <Sebastien.Hinderer <at> inria.fr>, bzg <at> gnu.org,
>> > 78474 <at> debbugs.gnu.org
>> >
>> > > > Samuel> It's actually even slower on my box.
>> > >
>> > > You benchmarked moving by one character. Moving by tabs can move in
>> > > multiples of 8 characters, so I doubt itʼs that cut and dried.
>> >
>> > The case which actually poses problem is only that \t\b vs \e[C. Using
>> > tab without moving back with \b does not pose problem.
>>
>> If that's the only problematic case, then disabling TABs as in the
>> proposed patch is not TRT.
Samuel> I don't think I asked for this, and only confirmed that it's one way to
Samuel> do it.
That was my misinterpretation of the request. Itʼs easy enough to
restrict the change to only affect the '\t\b' case, but weʼll have to
come up with a new name for the user option :-)
Robert
--
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#78474; Package
emacs.
(Tue, 22 Jul 2025 12:34:02 GMT)
Full text and
rfc822 format available.
Message #209 received at 78474 <at> debbugs.gnu.org (full text, mbox):
Robert Pluim, le mar. 22 juil. 2025 14:30:52 +0200, a ecrit:
> >>>>> On Tue, 22 Jul 2025 14:10:11 +0200, Samuel Thibault <samuel.thibault <at> gnu.org> said:
>
> Samuel> Eli Zaretskii, le mar. 22 juil. 2025 15:08:09 +0300, a ecrit:
> >> > Date: Mon, 21 Jul 2025 18:25:05 +0200
> >> > From: Samuel Thibault <samuel.thibault <at> gnu.org>
> >> > Cc: Eli Zaretskii <eliz <at> gnu.org>,
> >> > Seb Hinderer <Sebastien.Hinderer <at> inria.fr>, bzg <at> gnu.org,
> >> > 78474 <at> debbugs.gnu.org
> >> >
> >> > > > Samuel> It's actually even slower on my box.
> >> > >
> >> > > You benchmarked moving by one character. Moving by tabs can move in
> >> > > multiples of 8 characters, so I doubt itʼs that cut and dried.
> >> >
> >> > The case which actually poses problem is only that \t\b vs \e[C. Using
> >> > tab without moving back with \b does not pose problem.
> >>
> >> If that's the only problematic case, then disabling TABs as in the
> >> proposed patch is not TRT.
>
> Samuel> I don't think I asked for this, and only confirmed that it's one way to
> Samuel> do it.
>
> That was my misinterpretation of the request. Itʼs easy enough to
> restrict the change to only affect the '\t\b' case, but weʼll have to
> come up with a new name for the user option :-)
Since \t\b is actually slower than \e[C, I don't see why it should be an
option.
Samuel
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#78474; Package
emacs.
(Tue, 22 Jul 2025 12:46:01 GMT)
Full text and
rfc822 format available.
Message #212 received at 78474 <at> debbugs.gnu.org (full text, mbox):
>>>>> On Tue, 22 Jul 2025 14:33:38 +0200, Samuel Thibault <samuel.thibault <at> gnu.org> said:
>> That was my misinterpretation of the request. Itʼs easy enough to
>> restrict the change to only affect the '\t\b' case, but weʼll have to
>> come up with a new name for the user option :-)
Samuel> Since \t\b is actually slower than \e[C, I don't see why it should be an
Samuel> option.
Youʼre a braver man than I to make such a statement, and I for one
will not propose a change like this that cannot be controlled with a
variable of some sort.
Robert
--
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#78474; Package
emacs.
(Tue, 22 Jul 2025 13:20:02 GMT)
Full text and
rfc822 format available.
Message #215 received at 78474 <at> debbugs.gnu.org (full text, mbox):
> Date: Tue, 22 Jul 2025 13:30:41 +0200
> From: Samuel Thibault <samuel.thibault <at> gnu.org>
> Cc: rpluim <at> gmail.com, Sebastien.Hinderer <at> inria.fr, bzg <at> gnu.org,
> 78474 <at> debbugs.gnu.org
>
> Eli Zaretskii, le mar. 22 juil. 2025 14:28:19 +0300, a ecrit:
> > > Date: Mon, 21 Jul 2025 18:00:47 +0200
> > > From: Samuel Thibault <samuel.thibault <at> gnu.org>
> > > Cc: rpluim <at> gmail.com, Sebastien.Hinderer <at> inria.fr, bzg <at> gnu.org,
> > > 78474 <at> debbugs.gnu.org
> > >
> > > I have tried the attached test which reproduces both ways and reports
> > > the time to achieve one million iteration, on my system:
> > >
> > > - with rxvt: non-optimized way takes ~1.9s, optimized way takes ~2.1s.
> > > - with mate-terminal: non-optimized way takes ~1.8s, optimized way takes
> > > ~2.0s.
> > >
> > > So on my system at least the "optimized" way is actually slower.
> >
> > For that particular single case.
>
> Which is exactly the case that we are reporting about.
No, it isn't. Not even if only \t\b should be disabled.
What we need is to implement a prototype of the change to disable the
above, and then time it on a large enough buffer.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#78474; Package
emacs.
(Tue, 22 Jul 2025 13:25:02 GMT)
Full text and
rfc822 format available.
Message #218 received at 78474 <at> debbugs.gnu.org (full text, mbox):
> Date: Tue, 22 Jul 2025 14:09:40 +0200
> From: Samuel Thibault <samuel.thibault <at> gnu.org>
> Cc: Robert Pluim <rpluim <at> gmail.com>, Sebastien.Hinderer <at> inria.fr,
> bzg <at> gnu.org, 78474 <at> debbugs.gnu.org
>
> Eli Zaretskii, le mar. 22 juil. 2025 15:03:52 +0300, a ecrit:
> > Of course, specially-tailored cases could be concocted which show the
> > contrary, but that's not what this code is about. The request in this
> > bug report, AFAIU, was to disable the use of TABs _in_all_cases_,
>
> No.
>
> “
> Quoting Samuel: "Emacs, instead of sending a rightward cursor movement
> (\e[C), sends \009\008 (a tabulation and a leftward cursor movement)"
>
> This char insertion problem confuses assistive technologies for the
> visually impaired.
> ”
We are mis-communicating. When I said "in all cases", I meant even
when TABs do not cause any problems and/or when screen-reading
software is not used at all.
> I don't remember really asking for more than that.
A reminder from https://debbugs.gnu.org/cgi/bugreport.cgi?bug=78474#77
> This leads me to the suggestion that the configuration where tab is not
> used is the one enabled by default, leaving the configuraitn burden to
> those to whom performance matters enough for them to care.
And no, it wasn't you who asked for that; but then I didn't say it was
you.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#78474; Package
emacs.
(Tue, 22 Jul 2025 13:27:02 GMT)
Full text and
rfc822 format available.
Message #221 received at 78474 <at> debbugs.gnu.org (full text, mbox):
> Date: Tue, 22 Jul 2025 14:16:02 +0200
> From: Samuel Thibault <samuel.thibault <at> gnu.org>
> Cc: Sebastien.Hinderer <at> inria.fr, rpluim <at> gmail.com, bzg <at> gnu.org,
> 78474 <at> debbugs.gnu.org
>
> > But now you have changed the request, and are asking to disable the
> > TABs by default.
>
> I'm not *asking* for something in particular. I'm asking for a solution
> to the *actual* problem, which is \009\008.
Yes, by default (as opposed to an opt-in solution). That's what I
meant. Apologies if that wasn't clear.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#78474; Package
emacs.
(Tue, 22 Jul 2025 13:28:02 GMT)
Full text and
rfc822 format available.
Message #224 received at 78474 <at> debbugs.gnu.org (full text, mbox):
> Date: Tue, 22 Jul 2025 14:16:25 +0200
> From: Samuel Thibault <samuel.thibault <at> gnu.org>
> Cc: Sebastien.Hinderer <at> inria.fr, rpluim <at> gmail.com, bzg <at> gnu.org,
> 78474 <at> debbugs.gnu.org
>
> Eli Zaretskii, le mar. 22 juil. 2025 15:05:27 +0300, a ecrit:
> > > It is. Cat /dev/vcs, and you have it.
> >
> > When I do that on a GNU/Linux system to which I have access, I get:
> >
> > $ cat /dev/vcs
> > cat: /dev/vcs: Permission denied
>
> Yes, screen readers have always had to be privileged somehow.
Which maybe gives us a way to detect them?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#78474; Package
emacs.
(Tue, 22 Jul 2025 13:33:01 GMT)
Full text and
rfc822 format available.
Message #227 received at 78474 <at> debbugs.gnu.org (full text, mbox):
> Date: Tue, 22 Jul 2025 14:20:24 +0200
> From: Samuel Thibault <samuel.thibault <at> gnu.org>
> Cc: rpluim <at> gmail.com, Sebastien.Hinderer <at> inria.fr, bzg <at> gnu.org,
> 78474 <at> debbugs.gnu.org
>
> Eli Zaretskii, le mar. 22 juil. 2025 15:15:28 +0300, a ecrit:
> > What you copy/paste and what is written to the screen are not
> > necessarily the same thing. The effect of TAB on the screen is to
> > move the cursor (or the rest of the line's text) to the right by a
> > suitably-computed number of columns, which depends on the column where
> > you do that. What is copy/paste'd depends on the program which
> > serves the copy: some give you TAB, others give you spaces.
> >
> > > Also, if you run:
> > >
> > > echo -e 'a\t'
> > >
> > > is there actually supposed to be some content to copy/paste on the right
> > > of a?
> >
> > IME, also depends on the program which serves the copy/paste.
> >
> > (I think these aspects are tangents, not an integral part of this
> > discussion.)
>
> They are fully part of the discussion, because that changes what is
> actually supposed to be stored in the terminal, and thus what the
> accessibility feature is supposed to expose to the user: should it
> expose a tab, or spaces. But if a tab, then how can the cursor be inside
> the tab when emitting \t\b. That's the *whole* problem at stake.
So you are saying that even using cursor movement commands could cause
problems, because it is not known what the terminal will store? And
that Emacs should only use SPCes for that reason? Or what am I
missing?
> And thus why I mentioned looking for an actual document that explictly
> says that \t is supposed to produce spaces, because for now the vte
> maintainer is saying that there is no text there and thus it should not
> be exposed to the accessibility layer, but then the cursor is getting
> wrong, making emacs essentially unusable as it is now. If I had a text
> that explicitly says that \t produces content, it would be way easier
> to fix this on the vte side. For now, we have been stuck for a *decade*
> there.
I think I understand, but the refusal of the vte developers to provide
some solution doesn't mean it becomes the responsibility of Emacs to
solve that, does it?
Also, what about the "stty -tabs" workaround -- does it work with vte
and rxvt?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#78474; Package
emacs.
(Tue, 22 Jul 2025 13:40:02 GMT)
Full text and
rfc822 format available.
Message #230 received at 78474 <at> debbugs.gnu.org (full text, mbox):
> Date: Tue, 22 Jul 2025 14:16:02 +0200
> From: Samuel Thibault <samuel.thibault <at> gnu.org>
> Cc: Sebastien.Hinderer <at> inria.fr, rpluim <at> gmail.com, bzg <at> gnu.org,
> 78474 <at> debbugs.gnu.org
>
> And you are proposing to probe for the existence of a process to decide
> the emacs behavior. There has been already half a dozen graphical
> screen readers, some of which have even changed name. How can that be
> considered a solution when we are talking about just adding one byte...
I suggested that as an idea. I don't know if it is practical or not,
but I wanted to leave no rock unturned. (Recognizing half a dozen
names of programs doesn't sound terrible to me, if it will give us
what we want: the ability to disable \t\b when it could matter, and
not in other cases.)
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#78474; Package
emacs.
(Tue, 22 Jul 2025 13:43:02 GMT)
Full text and
rfc822 format available.
Message #233 received at 78474 <at> debbugs.gnu.org (full text, mbox):
> Date: Tue, 22 Jul 2025 14:27:30 +0200
> From: Samuel Thibault <samuel.thibault <at> gnu.org>
> Cc: Sebastien.Hinderer <at> inria.fr, rpluim <at> gmail.com, bzg <at> gnu.org,
> 78474 <at> debbugs.gnu.org
>
> Samuel Thibault, le mar. 22 juil. 2025 14:16:02 +0200, a ecrit:
> > And not a solution that will break as soon as somebody creates their
> > own screen reader for their own use.
>
> To put some context here: one of the latest screen readers out there,
> odilia, is already concerned by the amount of existing workarounds
> for accessibility in general. If they bang their head against walls
> concerning \t\b, wondering why that works with the well-known orca
> screen reader, and not with their own, and end up seeing a hardcoded
> list of the screen readers that are fortunate enough to be known enough
> to get the proper behavior of emacs in vte, as opposed to the screen
> reader that they are trying to write, then yes, I believe they could
> almost litteraly throw up.
Emacs makes it very easy to modify such databases. Saying the names
of such programs are "hardcoded" is not really accurate for Emacs,
because we can expose the list as a user option, so users could easily
add/remove programs as needed.
Again, I'm not saying this must be the solution, but it could be, from
where I stand.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#78474; Package
emacs.
(Tue, 22 Jul 2025 13:49:01 GMT)
Full text and
rfc822 format available.
Message #236 received at 78474 <at> debbugs.gnu.org (full text, mbox):
> From: Robert Pluim <rpluim <at> gmail.com>
> Cc: Eli Zaretskii <eliz <at> gnu.org>, Sebastien.Hinderer <at> inria.fr,
> bzg <at> gnu.org, 78474 <at> debbugs.gnu.org
> Date: Tue, 22 Jul 2025 14:45:12 +0200
>
> >>>>> On Tue, 22 Jul 2025 14:33:38 +0200, Samuel Thibault <samuel.thibault <at> gnu.org> said:
>
> >> That was my misinterpretation of the request. Itʼs easy enough to
> >> restrict the change to only affect the '\t\b' case, but weʼll have to
> >> come up with a new name for the user option :-)
>
> Samuel> Since \t\b is actually slower than \e[C, I don't see why it should be an
> Samuel> option.
>
> Youʼre a braver man than I to make such a statement, and I for one
> will not propose a change like this that cannot be controlled with a
> variable of some sort.
Yes, I agree. If only to have a "fire escape" if we ever bump into
some use case where this change might be a culprit, and will want an
easy way of testing that.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#78474; Package
emacs.
(Tue, 22 Jul 2025 13:55:01 GMT)
Full text and
rfc822 format available.
Message #239 received at 78474 <at> debbugs.gnu.org (full text, mbox):
And of course, this discussion about which screen reader is running does
not even take into account the ssh case where a blind user is using one
computer with a screen reader to ssh into another where emacs is run.
How then is the emacs run on the server supposed to guess that a screen
reader is being used?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#78474; Package
emacs.
(Tue, 22 Jul 2025 14:00:02 GMT)
Full text and
rfc822 format available.
Message #242 received at 78474 <at> debbugs.gnu.org (full text, mbox):
Robert Pluim (2025/07/22 14:45 +0200):
> >>>>> On Tue, 22 Jul 2025 14:33:38 +0200, Samuel Thibault <samuel.thibault <at> gnu.org> said:
>
> >> That was my misinterpretation of the request. Itʼs easy enough to
> >> restrict the change to only affect the '\t\b' case, but weʼll have to
> >> come up with a new name for the user option :-)
>
> Samuel> Since \t\b is actually slower than \e[C, I don't see why it should be an
> Samuel> option.
>
> Youʼre a braver man than I to make such a statement, and I for one
> will not propose a change like this that cannot be controlled with a
> variable of some sort.
I am not sure it's a matter of bravety. Do we know one context in
whichthe new way would not be desirable and where one may want to not
have that change?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#78474; Package
emacs.
(Tue, 22 Jul 2025 14:07:02 GMT)
Full text and
rfc822 format available.
Message #245 received at 78474 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii (2025/07/22 16:27 +0300):
> > Yes, screen readers have always had to be privileged somehow.
>
> Which maybe gives us a way to detect them?
Frankly Eli, I cannot urge you enough to just forget about this idea, as
swiftly as possible, for your own good (and ours).
There is the ssh case I mentionned and also, if you go through the WCAG
and all the principles of the Internet, sane communication is based on
agreements on what is exchanged which do not try to depend on which
software is on the other side.
Did you once see one RFC specifying what theprotocol should be depending
on which client or server one is talking to?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#78474; Package
emacs.
(Tue, 22 Jul 2025 14:08:02 GMT)
Full text and
rfc822 format available.
Message #248 received at 78474 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii (2025/07/22 16:18 +0300):
> What we need is to implement a prototype of the change to disable the
> above, and then time it on a large enough buffer.
Assuming the time actually does depend on the buffer's size, whihc I am
very not convinced about.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#78474; Package
emacs.
(Tue, 22 Jul 2025 14:10:02 GMT)
Full text and
rfc822 format available.
Message #251 received at 78474 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Robert Pluim <rpluim <at> gmail.com> writes:
>>>>>> On Tue, 22 Jul 2025 14:10:11 +0200, Samuel Thibault <samuel.thibault <at> gnu.org> said:
>
> Samuel> Eli Zaretskii, le mar. 22 juil. 2025 15:08:09 +0300, a ecrit:
> >> > Date: Mon, 21 Jul 2025 18:25:05 +0200
> >> > From: Samuel Thibault <samuel.thibault <at> gnu.org>
> >> > Cc: Eli Zaretskii <eliz <at> gnu.org>,
> >> > Seb Hinderer <Sebastien.Hinderer <at> inria.fr>, bzg <at> gnu.org,
> >> > 78474 <at> debbugs.gnu.org
> >> >
> >> > > > Samuel> It's actually even slower on my box.
> >> > >
> >> > > You benchmarked moving by one character. Moving by tabs can move in
> >> > > multiples of 8 characters, so I doubt itʼs that cut and dried.
> >> >
> >> > The case which actually poses problem is only that \t\b vs \e[C. Using
> >> > tab without moving back with \b does not pose problem.
> >>
> >> If that's the only problematic case, then disabling TABs as in the
> >> proposed patch is not TRT.
>
> Samuel> I don't think I asked for this, and only confirmed that it's one way to
> Samuel> do it.
>
> That was my misinterpretation of the request. Itʼs easy enough to
> restrict the change to only affect the '\t\b' case, but weʼll have to
> come up with a new name for the user option :-)
What about this?
[0001-Do-not-overshoot-and-backup-for-tty-motions.patch (text/x-patch, inline)]
From 002efa4bd1db6efd9f65dc43364b084680906753 Mon Sep 17 00:00:00 2001
From: Manuel Giraud <manuel <at> ledu-giraud.fr>
Date: Tue, 22 Jul 2025 15:15:39 +0200
Subject: [PATCH] Do not overshoot and backup for tty motions
---
src/cm.c | 24 +++---------------------
1 file changed, 3 insertions(+), 21 deletions(-)
diff --git a/src/cm.c b/src/cm.c
index 150d1c9a580..fb18ef26251 100644
--- a/src/cm.c
+++ b/src/cm.c
@@ -187,9 +187,7 @@ calccost (struct tty_display_info *tty,
c,
totalcost;
int ntabs,
- n2tabs,
tabx,
- tab2x,
tabcost;
register const char *p;
@@ -229,37 +227,21 @@ calccost (struct tty_display_info *tty,
goto olddelta; /* forget it! */
/*
- * ntabs is # tabs towards but not past dstx; n2tabs is one more
- * (ie past dstx), but this is only valid if that is not past the
- * right edge of the screen. We can check that at the same time
- * as we figure out where we would be if we use the tabs (which
- * we will put into tabx (for ntabs) and tab2x (for n2tabs)).
+ * ntabs is # tabs towards but not past dstx. tabx is where we
+ * would be if we put those ntabs tabulations.
*/
ntabs = (deltax + srcx % tty->Wcm->cm_tabwidth) / tty->Wcm->cm_tabwidth;
- n2tabs = ntabs + 1;
tabx = (srcx / tty->Wcm->cm_tabwidth + ntabs) * tty->Wcm->cm_tabwidth;
- tab2x = tabx + tty->Wcm->cm_tabwidth;
-
- if (tab2x >= tty->Wcm->cm_cols) /* too far (past edge) */
- n2tabs = 0;
/*
- * Now set tabcost to the cost for using ntabs, and c to the cost
- * for using n2tabs, then pick the minimum.
+ * Now set tabcost to the cost for using ntabs.
*/
/* cost for ntabs + cost for right motion */
tabcost = ntabs ? ntabs * tty->Wcm->cc_tab + (dstx - tabx) * tty->Wcm->cc_right
: BIG;
- /* cost for n2tabs + cost for left motion */
- c = n2tabs ? n2tabs * tty->Wcm->cc_tab + (tab2x - dstx) * tty->Wcm->cc_left
- : BIG;
-
- if (c < tabcost) /* then cheaper to overshoot & back up */
- ntabs = n2tabs, tabcost = c, tabx = tab2x;
-
if (tabcost >= BIG) /* caint use tabs */
goto newdelta;
--
2.50.1
[Message part 3 (text/plain, inline)]
Words of warning: I'm not a heavy user of tty emacs and don't really
have an idea of what would be the implications of such change (don't
shoot me). But maybe, Samuel and Sebastien could try this and see if it
solves their issue. Then, we could decide to guard behind a user option
and what would be the default.
--
Manuel Giraud
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#78474; Package
emacs.
(Tue, 22 Jul 2025 14:19:03 GMT)
Full text and
rfc822 format available.
Message #254 received at 78474 <at> debbugs.gnu.org (full text, mbox):
> Date: Tue, 22 Jul 2025 15:54:33 +0200
> From: Seb Hinderer <Sebastien.Hinderer <at> inria.fr>
> Cc: Eli Zaretskii <eliz <at> gnu.org>, rpluim <at> gmail.com, bzg <at> gnu.org,
> 78474 <at> debbugs.gnu.org
>
> And of course, this discussion about which screen reader is running does
> not even take into account the ssh case where a blind user is using one
> computer with a screen reader to ssh into another where emacs is run.
> How then is the emacs run on the server supposed to guess that a screen
> reader is being used?
If there's no way of knowing that, the option we are talking about
will still be available to disable the problematic sequences manually.
(And of course, if the remote login uses a terminal emulator that is
not affected by these issues, the problem will not exist in the first
place.)
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#78474; Package
emacs.
(Tue, 22 Jul 2025 14:21:03 GMT)
Full text and
rfc822 format available.
Message #257 received at 78474 <at> debbugs.gnu.org (full text, mbox):
> Date: Tue, 22 Jul 2025 15:59:24 +0200
> From: Seb Hinderer <Sebastien.Hinderer <at> inria.fr>
> Cc: Samuel Thibault <samuel.thibault <at> gnu.org>, Eli Zaretskii <eliz <at> gnu.org>,
> bzg <at> gnu.org, 78474 <at> debbugs.gnu.org
>
> Robert Pluim (2025/07/22 14:45 +0200):
> > >>>>> On Tue, 22 Jul 2025 14:33:38 +0200, Samuel Thibault <samuel.thibault <at> gnu.org> said:
> >
> > >> That was my misinterpretation of the request. Itʼs easy enough to
> > >> restrict the change to only affect the '\t\b' case, but weʼll have to
> > >> come up with a new name for the user option :-)
> >
> > Samuel> Since \t\b is actually slower than \e[C, I don't see why it should be an
> > Samuel> option.
> >
> > Youʼre a braver man than I to make such a statement, and I for one
> > will not propose a change like this that cannot be controlled with a
> > variable of some sort.
>
> I am not sure it's a matter of bravety. Do we know one context in
> whichthe new way would not be desirable and where one may want to not
> have that change?
We have enough gray hair to know that such contexts will almost
certainly reveal themselves at some point. And if they don't, then
the option which is never used will; not do any harm, will it?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#78474; Package
emacs.
(Tue, 22 Jul 2025 14:25:02 GMT)
Full text and
rfc822 format available.
Message #260 received at 78474 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii (2025/07/22 17:18 +0300):
> If there's no way of knowing that, the option we are talking about
> will still be available to disable the problematic sequences manually.
The second part of the discussion: what should be the default.
Backward-compatibility matters suggest to continue to emit exactly the
same thing and the possibility to disable the problematic sequence but,
as I explained earlier in this thread, I really findthis painful and
unfair to people who already have to tinker with everything.
Can we please consider makingthe new style the default and provide the
option to re-enable the sequence if there are people forwhom it
actuallymakes a difference?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#78474; Package
emacs.
(Tue, 22 Jul 2025 14:26:02 GMT)
Full text and
rfc822 format available.
Message #263 received at 78474 <at> debbugs.gnu.org (full text, mbox):
> Date: Tue, 22 Jul 2025 16:06:15 +0200
> From: Seb Hinderer <Sebastien.Hinderer <at> inria.fr>
> Cc: Samuel Thibault <samuel.thibault <at> gnu.org>, rpluim <at> gmail.com,
> bzg <at> gnu.org, 78474 <at> debbugs.gnu.org
>
> Eli Zaretskii (2025/07/22 16:27 +0300):
> > > Yes, screen readers have always had to be privileged somehow.
> >
> > Which maybe gives us a way to detect them?
>
> Frankly Eli, I cannot urge you enough to just forget about this idea, as
> swiftly as possible, for your own good (and ours).
>
> There is the ssh case I mentionned and also, if you go through the WCAG
> and all the principles of the Internet, sane communication is based on
> agreements on what is exchanged which do not try to depend on which
> software is on the other side.
If better methods are possible, they are of course preferred. But if
they are impossible, I don't want to reject other methods, even if
they are less elegant.
> Did you once see one RFC specifying what theprotocol should be depending
> on which client or server one is talking to?
Yes, of course. Emacs has several features where we change behavior
depending on which external program we are communicating with or using
as a sub-process.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#78474; Package
emacs.
(Tue, 22 Jul 2025 14:27:03 GMT)
Full text and
rfc822 format available.
Message #266 received at 78474 <at> debbugs.gnu.org (full text, mbox):
> Date: Tue, 22 Jul 2025 16:07:14 +0200
> From: Seb Hinderer <Sebastien.Hinderer <at> inria.fr>
> Cc: Samuel Thibault <samuel.thibault <at> gnu.org>, rpluim <at> gmail.com,
> bzg <at> gnu.org, 78474 <at> debbugs.gnu.org
>
> Eli Zaretskii (2025/07/22 16:18 +0300):
> > What we need is to implement a prototype of the change to disable the
> > above, and then time it on a large enough buffer.
>
> Assuming the time actually does depend on the buffer's size, whihc I am
> very not convinced about.
The buffer size is a means to get a good average measure of the speed.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#78474; Package
emacs.
(Tue, 22 Jul 2025 14:29:02 GMT)
Full text and
rfc822 format available.
Message #269 received at 78474 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii (2025/07/22 17:25 +0300):
> > Did you once see one RFC specifying what theprotocol should be depending
> > on which client or server one is talking to?
>
> Yes, of course. Emacs has several features where we change behavior
> depending on which external program we are communicating with or using
> as a sub-process.
I was asking about RFCs and you respond Emacs...
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#78474; Package
emacs.
(Tue, 22 Jul 2025 14:47:02 GMT)
Full text and
rfc822 format available.
Message #272 received at 78474 <at> debbugs.gnu.org (full text, mbox):
> Date: Tue, 22 Jul 2025 16:24:28 +0200
> From: Seb Hinderer <Sebastien.Hinderer <at> inria.fr>
> Cc: samuel.thibault <at> gnu.org, rpluim <at> gmail.com, bzg <at> gnu.org,
> 78474 <at> debbugs.gnu.org
>
> Eli Zaretskii (2025/07/22 17:18 +0300):
> > If there's no way of knowing that, the option we are talking about
> > will still be available to disable the problematic sequences manually.
>
> The second part of the discussion: what should be the default.
If the default is not right for everyone, setting the option manually
is still a viable alternative -- provided that we succeed to handle
the majority of the cases correctly.
> Backward-compatibility matters suggest to continue to emit exactly the
> same thing and the possibility to disable the problematic sequence but,
> as I explained earlier in this thread, I really findthis painful and
> unfair to people who already have to tinker with everything.
>
> Can we please consider makingthe new style the default and provide the
> option to re-enable the sequence if there are people forwhom it
> actuallymakes a difference?
That's what we are discussing. We are not done yet. In fact, we
don't even have a working agreed-upon patch which implements the
request when \t\b sequences are disabled. The question of the default
behavior will become relevant once we are past that.
So please be a bit more patient while we discuss this.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#78474; Package
emacs.
(Tue, 22 Jul 2025 14:51:02 GMT)
Full text and
rfc822 format available.
Message #275 received at 78474 <at> debbugs.gnu.org (full text, mbox):
> Date: Tue, 22 Jul 2025 16:28:30 +0200
> From: Seb Hinderer <Sebastien.Hinderer <at> inria.fr>
> Cc: samuel.thibault <at> gnu.org, rpluim <at> gmail.com, bzg <at> gnu.org,
> 78474 <at> debbugs.gnu.org
>
> Eli Zaretskii (2025/07/22 17:25 +0300):
> > > Did you once see one RFC specifying what theprotocol should be depending
> > > on which client or server one is talking to?
> >
> > Yes, of course. Emacs has several features where we change behavior
> > depending on which external program we are communicating with or using
> > as a sub-process.
>
> I was asking about RFCs and you respond Emacs...
But we _are_ talking about Emacs. Emacs is not driven by RFCs, and
doesn't blindly follow RFCs unless we consider that useful.
I think the fact that Emacs already takes specific programs into
consideration means that such solutions _are_ possible. If we
conclude that doing so would be a reasonably good solution for this
problem, I don't see why we should not use that. If such a solution
will make our users happy, why should anyone care whether it follows
some RFC or is pretty?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#78474; Package
emacs.
(Tue, 22 Jul 2025 15:48:01 GMT)
Full text and
rfc822 format available.
Message #278 received at 78474 <at> debbugs.gnu.org (full text, mbox):
> Cc: bzg <at> gnu.org, 78474 <at> debbugs.gnu.org, rpluim <at> gmail.com,
> samuel.thibault <at> gnu.org
> Date: Tue, 22 Jul 2025 17:46:35 +0300
> From: Eli Zaretskii <eliz <at> gnu.org>
>
> > Backward-compatibility matters suggest to continue to emit exactly the
> > same thing and the possibility to disable the problematic sequence but,
> > as I explained earlier in this thread, I really findthis painful and
> > unfair to people who already have to tinker with everything.
> >
> > Can we please consider makingthe new style the default and provide the
> > option to re-enable the sequence if there are people forwhom it
> > actuallymakes a difference?
>
> That's what we are discussing. We are not done yet. In fact, we
> don't even have a working agreed-upon patch which implements the
> request when \t\b sequences are disabled. The question of the default
> behavior will become relevant once we are past that.
>
> So please be a bit more patient while we discuss this.
Btw, let me make sure I understand correctly: is screen-reading
software affected by this only on those two kinds of terminals (rxvt
and vte), where \t\b produces wrong output? Or do other terminals,
where the above sequence is processed correctly, also dupe screen
readers into reading incorrect content?
If only those two terminals are affected, both in the effect of the
cursor motion and what that does to screen readers, then we could
disable the \t\b sequence only for those two terminals. Emacs can
look at the name of the terminal to decide what to do.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#78474; Package
emacs.
(Tue, 22 Jul 2025 16:06:01 GMT)
Full text and
rfc822 format available.
Message #281 received at 78474 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii (2025/07/22 18:47 +0300):
> Btw, let me make sure I understand correctly: is screen-reading
> software affected by this only on those two kinds of terminals (rxvt
> and vte), where \t\b produces wrong output?
I am not completely sure and would rather let Samuel complete here. What
I know isthat libvte is used for several terminals so I expect all of
them to be affected.
> If only those two terminals are affected, both in the effect of the
> cursor motion and what that does to screen readers, then we could
> disable the \t\b sequence only for those two terminals. Emacs can
> look at the name of the terminal to decide what to do.
Would that be ssh-proof? Andwhat about running screen or tmux in such a
terminal?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#78474; Package
emacs.
(Tue, 22 Jul 2025 17:01:02 GMT)
Full text and
rfc822 format available.
Message #284 received at 78474 <at> debbugs.gnu.org (full text, mbox):
> Date: Tue, 22 Jul 2025 18:05:14 +0200
> From: Seb Hinderer <Sebastien.Hinderer <at> inria.fr>
> Cc: samuel.thibault <at> gnu.org, bzg <at> gnu.org, 78474 <at> debbugs.gnu.org,
> rpluim <at> gmail.com
>
> Eli Zaretskii (2025/07/22 18:47 +0300):
> > Btw, let me make sure I understand correctly: is screen-reading
> > software affected by this only on those two kinds of terminals (rxvt
> > and vte), where \t\b produces wrong output?
>
> I am not completely sure and would rather let Samuel complete here. What
> I know isthat libvte is used for several terminals so I expect all of
> them to be affected.
We can still know the names of those terminals, even if they are more
than 2.
> > If only those two terminals are affected, both in the effect of the
> > cursor motion and what that does to screen readers, then we could
> > disable the \t\b sequence only for those two terminals. Emacs can
> > look at the name of the terminal to decide what to do.
>
> Would that be ssh-proof?
You need to set TERM in the ssh session.
> And what about running screen or tmux in such a terminal?
Again, TERM should be set.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#78474; Package
emacs.
(Tue, 22 Jul 2025 17:50:02 GMT)
Full text and
rfc822 format available.
Message #287 received at 78474 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii, le mar. 22 juil. 2025 18:47:18 +0300, a ecrit:
> Btw, let me make sure I understand correctly: is screen-reading
> software affected by this only on those two kinds of terminals (rxvt
> and vte), where \t\b produces wrong output?
Yes. But vte happens to be the only terminal layer that implements
accessibility. Screen readers cannot be used with all the others.
Seb Hinderer, le mar. 22 juil. 2025 18:05:14 +0200, a ecrit:
> I am not completely sure and would rather let Samuel complete here. What
> I know isthat libvte is used for several terminals so I expect all of
> them to be affected.
Yes, there is a dozen of those in Debian, at least.
> If only those two terminals are affected, both in the effect of the
> cursor motion and what that does to screen readers, then we could
> disable the \t\b sequence only for those two terminals. Emacs can
> look at the name of the terminal to decide what to do.
No, it cannot.
Eli Zaretskii, le mar. 22 juil. 2025 19:59:50 +0300, a ecrit:
> > > Emacs can look at the name of the terminal to decide what to do.
> >
> > Would that be ssh-proof?
>
> You need to set TERM in the ssh session.
Yes, although libvte announces itself as xterm-256color.
> > And what about running screen or tmux in such a terminal?
>
> Again, TERM should be set.
In that case it's actually screen and tmux that interpret sequences, and
TERM is then screen and tmux. And those happen not to be using the \t\b
trick when re-displaying their output, so they "fix" the issue.
Samuel
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#78474; Package
emacs.
(Tue, 22 Jul 2025 17:57:01 GMT)
Full text and
rfc822 format available.
Message #290 received at 78474 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii, le mar. 22 juil. 2025 16:24:47 +0300, a ecrit:
> > From: Samuel Thibault <samuel.thibault <at> gnu.org>
> > Eli Zaretskii, le mar. 22 juil. 2025 15:03:52 +0300, a ecrit:
> > > Of course, specially-tailored cases could be concocted which show the
> > > contrary, but that's not what this code is about. The request in this
> > > bug report, AFAIU, was to disable the use of TABs _in_all_cases_,
> >
> > No.
> >
> > “
> > Quoting Samuel: "Emacs, instead of sending a rightward cursor movement
> > (\e[C), sends \009\008 (a tabulation and a leftward cursor movement)"
> >
> > This char insertion problem confuses assistive technologies for the
> > visually impaired.
> > ”
>
> We are mis-communicating. When I said "in all cases", I meant even
> when TABs do not cause any problems and/or when screen-reading
> software is not used at all.
But we were talking about my benchmark moving only by one character
(where the optimization loses) vs moving by 8 characters (where it
most probably wins since that's 8 interpretations and 8 bytes vs 1
interpretation and 1 byte).
The discussion was not about it being a default for everybody or not.
> > I don't remember really asking for more than that.
>
> A reminder from https://debbugs.gnu.org/cgi/bugreport.cgi?bug=78474#77
Yes, and I do agree with really asking for that one: we don't want to
put the burden of configuration on people who already have a hard time
using computers.
Samuel
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#78474; Package
emacs.
(Tue, 22 Jul 2025 17:59:01 GMT)
Full text and
rfc822 format available.
Message #293 received at 78474 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii, le mar. 22 juil. 2025 16:31:54 +0300, a ecrit:
> Also, what about the "stty -tabs" workaround -- does it work with vte
> and rxvt?
Of course, since emacs then duly respects not using tabs at all.
But again, that's to be configured (and even more arcane than modifying
.emacs)
Samuel
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#78474; Package
emacs.
(Tue, 22 Jul 2025 18:05:02 GMT)
Full text and
rfc822 format available.
Message #296 received at 78474 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii, le mar. 22 juil. 2025 16:18:48 +0300, a ecrit:
> > Eli Zaretskii, le mar. 22 juil. 2025 14:28:19 +0300, a ecrit:
> > > > I have tried the attached test which reproduces both ways and reports
> > > > the time to achieve one million iteration, on my system:
> > > >
> > > > - with rxvt: non-optimized way takes ~1.9s, optimized way takes ~2.1s.
> > > > - with mate-terminal: non-optimized way takes ~1.8s, optimized way takes
> > > > ~2.0s.
> > > >
> > > > So on my system at least the "optimized" way is actually slower.
> > >
> > > For that particular single case.
> >
> > Which is exactly the case that we are reporting about.
>
> No, it isn't. Not even if only \t\b should be disabled.
? I don't understand.
\t\b really is the only issue that we are having.
And the benchmark above, which you can try on various terminals, does
show that \t\b happens to be less efficient than \e[C. So it would
actually benefit everybody to just use \e[C by default instead of \t\b.
Samuel
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#78474; Package
emacs.
(Tue, 22 Jul 2025 18:06:01 GMT)
Full text and
rfc822 format available.
Message #299 received at 78474 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii, le mar. 22 juil. 2025 16:26:38 +0300, a ecrit:
> > > But now you have changed the request, and are asking to disable the
> > > TABs by default.
> >
> > I'm not *asking* for something in particular. I'm asking for a solution
> > to the *actual* problem, which is \009\008.
>
> Yes, by default (as opposed to an opt-in solution). That's what I
> meant. Apologies if that wasn't clear.
Thanks for making it clear. It's indeed important that we get our exact
respective positions.
Samuel
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#78474; Package
emacs.
(Tue, 22 Jul 2025 18:09:02 GMT)
Full text and
rfc822 format available.
Message #302 received at 78474 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii, le mar. 22 juil. 2025 16:42:29 +0300, a ecrit:
> > Samuel Thibault, le mar. 22 juil. 2025 14:16:02 +0200, a ecrit:
> > and end up seeing a hardcoded
> > list of the screen readers that are fortunate enough to be known enough
> > to get the proper behavior of emacs in vte,
>
> Emacs makes it very easy to modify such databases. Saying the names
> of such programs are "hardcoded" is not really accurate for Emacs,
> because we can expose the list as a user option, so users could easily
> add/remove programs as needed.
But it's *really* hard for users to walk the way from "the cursor does
not move when I press space!" down to "maybe I should try disabling the
use of tab for optimization". I don't think Sebastien would have found
such an option or even thought it could have existed.
Samuel
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#78474; Package
emacs.
(Tue, 22 Jul 2025 18:11:02 GMT)
Full text and
rfc822 format available.
Message #305 received at 78474 <at> debbugs.gnu.org (full text, mbox):
Andreas Schwab, le mar. 22 juil. 2025 15:48:20 +0200, a ecrit:
> On Jul 21 2025, Samuel Thibault wrote:
>
> > It is. Cat /dev/vcs, and you have it.
>
> /dev/vcs contains the rendered contents, so how they were drawn should
> not make any difference.
The question of this thread piece was not about that, but about screen
readers being able to read the screen without getting announced to
applications in any way.
Samuel
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#78474; Package
emacs.
(Tue, 22 Jul 2025 18:17:02 GMT)
Full text and
rfc822 format available.
Message #308 received at 78474 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii, le mar. 22 juil. 2025 17:26:06 +0300, a ecrit:
> > Eli Zaretskii (2025/07/22 16:18 +0300):
> > > What we need is to implement a prototype of the change to disable the
> > > above, and then time it on a large enough buffer.
> >
> > Assuming the time actually does depend on the buffer's size, whihc I am
> > very not convinced about.
>
> The buffer size is a means to get a good average measure of the speed.
But it also makes saving one byte even less a bonus... I tried to write
100 right-left movements (\t\b\b vs \e[C\b) at a time, the \t\b trick
takes ~30s while the standard \e[C takes ~5s.
Samuel
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#78474; Package
emacs.
(Tue, 22 Jul 2025 18:21:01 GMT)
Full text and
rfc822 format available.
Message #311 received at 78474 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii, le mar. 22 juil. 2025 16:31:54 +0300, a ecrit:
> > If I had a text that explicitly says that \t produces content, it
> > would be way easier to fix this on the vte side. For now, we have
> > been stuck for a *decade* there.
>
> I think I understand, but the refusal of the vte developers to provide
> some solution doesn't mean it becomes the responsibility of Emacs to
> solve that, does it?
emacs is the only program we know that uses such \t\b trick and thus
poses cursor position problem.
Samuel
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#78474; Package
emacs.
(Tue, 22 Jul 2025 18:26:02 GMT)
Full text and
rfc822 format available.
Message #314 received at 78474 <at> debbugs.gnu.org (full text, mbox):
Manuel Giraud, le mar. 22 juil. 2025 16:09:33 +0200, a ecrit:
> Robert Pluim <rpluim <at> gmail.com> writes:
>
> >>>>>> On Tue, 22 Jul 2025 14:10:11 +0200, Samuel Thibault <samuel.thibault <at> gnu.org> said:
> >
> > Samuel> Eli Zaretskii, le mar. 22 juil. 2025 15:08:09 +0300, a ecrit:
> > >> > Date: Mon, 21 Jul 2025 18:25:05 +0200
> > >> > From: Samuel Thibault <samuel.thibault <at> gnu.org>
> > >> > Cc: Eli Zaretskii <eliz <at> gnu.org>,
> > >> > Seb Hinderer <Sebastien.Hinderer <at> inria.fr>, bzg <at> gnu.org,
> > >> > 78474 <at> debbugs.gnu.org
> > >> >
> > >> > > > Samuel> It's actually even slower on my box.
> > >> > >
> > >> > > You benchmarked moving by one character. Moving by tabs can move in
> > >> > > multiples of 8 characters, so I doubt itʼs that cut and dried.
> > >> >
> > >> > The case which actually poses problem is only that \t\b vs \e[C. Using
> > >> > tab without moving back with \b does not pose problem.
> > >>
> > >> If that's the only problematic case, then disabling TABs as in the
> > >> proposed patch is not TRT.
> >
> > Samuel> I don't think I asked for this, and only confirmed that it's one way to
> > Samuel> do it.
> >
> > That was my misinterpretation of the request. Itʼs easy enough to
> > restrict the change to only affect the '\t\b' case, but weʼll have to
> > come up with a new name for the user option :-)
>
> What about this?
It looks like a very good candidate, thanks! I'm trying it.
Samuel
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#78474; Package
emacs.
(Tue, 22 Jul 2025 18:28:02 GMT)
Full text and
rfc822 format available.
Message #317 received at 78474 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii, le mar. 22 juil. 2025 16:31:54 +0300, a ecrit:
> > Eli Zaretskii, le mar. 22 juil. 2025 15:15:28 +0300, a ecrit:
> > > What you copy/paste and what is written to the screen are not
> > > necessarily the same thing. The effect of TAB on the screen is to
> > > move the cursor (or the rest of the line's text) to the right by a
> > > suitably-computed number of columns, which depends on the column where
> > > you do that. What is copy/paste'd depends on the program which
> > > serves the copy: some give you TAB, others give you spaces.
> > >
> > > > Also, if you run:
> > > >
> > > > echo -e 'a\t'
> > > >
> > > > is there actually supposed to be some content to copy/paste on the right
> > > > of a?
> > >
> > > IME, also depends on the program which serves the copy/paste.
> > >
> > > (I think these aspects are tangents, not an integral part of this
> > > discussion.)
> >
> > They are fully part of the discussion, because that changes what is
> > actually supposed to be stored in the terminal, and thus what the
> > accessibility feature is supposed to expose to the user: should it
> > expose a tab, or spaces. But if a tab, then how can the cursor be inside
> > the tab when emitting \t\b. That's the *whole* problem at stake.
>
> So you are saying that even using cursor movement commands could cause
> problems,
The problem is that some people consider \t as not being only a cursor
movement. That's the whole point of the question raised above.
> because it is not known what the terminal will store? And
> that Emacs should only use SPCes for that reason?
\t alone seems to be not posing problems, and is fine to keep to
optimize some cursor movements. It's \t\b which gets wrong.
Samuel
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#78474; Package
emacs.
(Tue, 22 Jul 2025 19:55:01 GMT)
Full text and
rfc822 format available.
Message #320 received at 78474 <at> debbugs.gnu.org (full text, mbox):
Re,
Manuel Giraud, le mar. 22 juil. 2025 16:09:33 +0200, a ecrit:
> >>>>>> On Tue, 22 Jul 2025 14:10:11 +0200, Samuel Thibault <samuel.thibault <at> gnu.org> said:
> > That was my misinterpretation of the request. Itʼs easy enough to
> > restrict the change to only affect the '\t\b' case, but weʼll have to
> > come up with a new name for the user option :-)
>
> What about this?
Yes, that works!
> From 002efa4bd1db6efd9f65dc43364b084680906753 Mon Sep 17 00:00:00 2001
> From: Manuel Giraud <manuel <at> ledu-giraud.fr>
> Date: Tue, 22 Jul 2025 15:15:39 +0200
> Subject: [PATCH] Do not overshoot and backup for tty motions
>
> ---
> src/cm.c | 24 +++---------------------
> 1 file changed, 3 insertions(+), 21 deletions(-)
>
> diff --git a/src/cm.c b/src/cm.c
> index 150d1c9a580..fb18ef26251 100644
> --- a/src/cm.c
> +++ b/src/cm.c
> - if (c < tabcost) /* then cheaper to overshoot & back up */
> - ntabs = n2tabs, tabcost = c, tabx = tab2x;
> -
> if (tabcost >= BIG) /* caint use tabs */
> goto newdelta;
Samuel
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#78474; Package
emacs.
(Wed, 23 Jul 2025 07:42:01 GMT)
Full text and
rfc822 format available.
Message #323 received at 78474 <at> debbugs.gnu.org (full text, mbox):
Samuel Thibault (2025/07/22 20:08 +0200):
> Eli Zaretskii, le mar. 22 juil. 2025 16:42:29 +0300, a ecrit:
> > > Samuel Thibault, le mar. 22 juil. 2025 14:16:02 +0200, a ecrit:
> > > and end up seeing a hardcoded
> > > list of the screen readers that are fortunate enough to be known enough
> > > to get the proper behavior of emacs in vte,
> >
> > Emacs makes it very easy to modify such databases. Saying the names
> > of such programs are "hardcoded" is not really accurate for Emacs,
> > because we can expose the list as a user option, so users could easily
> > add/remove programs as needed.
>
> But it's *really* hard for users to walk the way from "the cursor does
> not move when I press space!" down to "maybe I should try disabling the
> use of tab for optimization". I don't think Sebastien would have found
> such an option or even thought it could have existed.
I confirm. And it's not that I am a noob. Well I am, but at the same
time I am also an engineer, so likely what is going to be hard
andpainful for me will be way more so for people who are less into
computers.
And realise that this would be multiplied by the number of software to
use. Just not viable.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#78474; Package
emacs.
(Wed, 23 Jul 2025 07:53:02 GMT)
Full text and
rfc822 format available.
Message #326 received at 78474 <at> debbugs.gnu.org (full text, mbox):
Samuel Thibault (2025/07/22 20:20 +0200):
> Eli Zaretskii, le mar. 22 juil. 2025 16:31:54 +0300, a ecrit:
> > > If I had a text that explicitly says that \t produces content, it
> > > would be way easier to fix this on the vte side. For now, we have
> > > been stuck for a *decade* there.
> >
> > I think I understand, but the refusal of the vte developers to provide
> > some solution doesn't mean it becomes the responsibility of Emacs to
> > solve that, does it?
>
> emacs is the only program we know that uses such \t\b trick and thus
> poses cursor position problem.
And the road down to this findking has been quite longbecause we first
had to fix all the problems in vte, which took the decade Samuel
mentionned and is still not integrated, before then realising that
although we get a nice behaviour with editors suchas vimor joe, that
didn't hold for Emacs. And it took another bunch of time and brain
resources to figure out what was going on there. Credit again goes to
Samuel for that.
A very friendly note to the Emacs maintainers whoare reading this
thread: my intention is *not* tomake you feel bad. I appreciate that you
are here, discuss, genuinely try tounderstand. Precisely, to broaden
your understanding, I would like to explain one point you may be missing
and it's certainly not your faul if you are missing it, but please read
me and think over it.
The discussion we are currently having with you, wehave to haveon
dozens and dozens of projects. So yes, having to have such discussions
again and again is super tiring and it's kind of a miracle that people
like Samuel are still there, although not directly concerned.
We try to suggest solutions that are viable, as "main stream" as
possible because we believe that the best thing that can happen to
accessibility is that it gets integrated to programs as readily as
possible.
As much as possible, we would like to avoid that accessibility has to go
to dedicated code paths because we know from experience tat, in the long
run, such code paths will receive less testing and maintenance
attenition.
And I think this becomes even more true if, as it seems to be the case
here, the proposed code is actually cleaner, more efficient and more
standard than what was done before. Tome, the fact that the former code
has not had to change for decades does not mean it shouldn't be changed
now.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#78474; Package
emacs.
(Wed, 23 Jul 2025 08:02:02 GMT)
Full text and
rfc822 format available.
Message #329 received at 78474 <at> debbugs.gnu.org (full text, mbox):
Samuel Thibault <samuel.thibault <at> gnu.org> writes:
> Re,
>
> Manuel Giraud, le mar. 22 juil. 2025 16:09:33 +0200, a ecrit:
>> >>>>>> On Tue, 22 Jul 2025 14:10:11 +0200, Samuel Thibault
>> > <samuel.thibault <at> gnu.org> said:
>> > That was my misinterpretation of the request. Itʼs easy enough to
>> > restrict the change to only affect the '\t\b' case, but weʼll have to
>> > come up with a new name for the user option :-)
>>
>> What about this?
>
> Yes, that works!
Thanks. So maybe next step is to decide if we keep this overshoot
behaviour guarded behind a user option (I propose
`inhibit-overshoot-in-tty-motions') and, the hard question, what should
be its default?
--
Manuel Giraud
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#78474; Package
emacs.
(Wed, 23 Jul 2025 08:07:02 GMT)
Full text and
rfc822 format available.
Message #332 received at 78474 <at> debbugs.gnu.org (full text, mbox):
On Jul 22 2025, Samuel Thibault wrote:
> Andreas Schwab, le mar. 22 juil. 2025 15:48:20 +0200, a ecrit:
>> On Jul 21 2025, Samuel Thibault wrote:
>>
>> > It is. Cat /dev/vcs, and you have it.
>>
>> /dev/vcs contains the rendered contents, so how they were drawn should
>> not make any difference.
>
> The question of this thread piece was not about that, but about screen
> readers being able to read the screen without getting announced to
> applications in any way.
Since screen readers using /dev/vcs are not affected by this issue they
are irrelevant here.
--
Andreas Schwab, SUSE Labs, schwab <at> suse.de
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE 1748 E4D4 88E3 0EEA B9D7
"And now for something completely different."
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#78474; Package
emacs.
(Wed, 23 Jul 2025 08:16:02 GMT)
Full text and
rfc822 format available.
Message #335 received at 78474 <at> debbugs.gnu.org (full text, mbox):
Andreas Schwab, le mer. 23 juil. 2025 10:06:19 +0200, a ecrit:
> On Jul 22 2025, Samuel Thibault wrote:
> > Andreas Schwab, le mar. 22 juil. 2025 15:48:20 +0200, a ecrit:
> >> On Jul 21 2025, Samuel Thibault wrote:
> >>
> >> > It is. Cat /dev/vcs, and you have it.
> >>
> >> /dev/vcs contains the rendered contents, so how they were drawn should
> >> not make any difference.
> >
> > The question of this thread piece was not about that, but about screen
> > readers being able to read the screen without getting announced to
> > applications in any way.
>
> Since screen readers using /dev/vcs are not affected by this issue they
> are irrelevant here.
It was just an example that was easier to grasp than the graphical case.
Samuel
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#78474; Package
emacs.
(Wed, 23 Jul 2025 10:51:02 GMT)
Full text and
rfc822 format available.
Message #338 received at 78474 <at> debbugs.gnu.org (full text, mbox):
> Date: Tue, 22 Jul 2025 19:49:31 +0200
> From: Samuel Thibault <samuel.thibault <at> gnu.org>
> Cc: bzg <at> gnu.org, 78474 <at> debbugs.gnu.org, rpluim <at> gmail.com
>
> Eli Zaretskii, le mar. 22 juil. 2025 18:47:18 +0300, a ecrit:
> > Btw, let me make sure I understand correctly: is screen-reading
> > software affected by this only on those two kinds of terminals (rxvt
> > and vte), where \t\b produces wrong output?
>
> Yes. But vte happens to be the only terminal layer that implements
> accessibility. Screen readers cannot be used with all the others.
>
> Seb Hinderer, le mar. 22 juil. 2025 18:05:14 +0200, a ecrit:
> > I am not completely sure and would rather let Samuel complete here. What
> > I know isthat libvte is used for several terminals so I expect all of
> > them to be affected.
>
> Yes, there is a dozen of those in Debian, at least.
Can you name them, please?
> > If only those two terminals are affected, both in the effect of the
> > cursor motion and what that does to screen readers, then we could
> > disable the \t\b sequence only for those two terminals. Emacs can
> > look at the name of the terminal to decide what to do.
>
> No, it cannot.
Why not? Looking at the value of TERM is something Emacs already
does, because it needs to load a corresponding library from
lisp/term/. So such a library would be a natural place to set this
variable if we decide to disable \t\b on thos specific terminals by
default.
> Eli Zaretskii, le mar. 22 juil. 2025 19:59:50 +0300, a ecrit:
> > > > Emacs can look at the name of the terminal to decide what to do.
> > >
> > > Would that be ssh-proof?
> >
> > You need to set TERM in the ssh session.
>
> Yes, although libvte announces itself as xterm-256color.
So we could have a terminal which sets TERM=xterm-256color, but which
doesn't behave like xterm does?
> > > And what about running screen or tmux in such a terminal?
> >
> > Again, TERM should be set.
>
> In that case it's actually screen and tmux that interpret sequences, and
> TERM is then screen and tmux. And those happen not to be using the \t\b
> trick when re-displaying their output, so they "fix" the issue.
Thus no problem.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#78474; Package
emacs.
(Wed, 23 Jul 2025 10:56:01 GMT)
Full text and
rfc822 format available.
Message #341 received at 78474 <at> debbugs.gnu.org (full text, mbox):
> Date: Tue, 22 Jul 2025 19:56:05 +0200
> From: Samuel Thibault <samuel.thibault <at> gnu.org>
> Cc: rpluim <at> gmail.com, Sebastien.Hinderer <at> inria.fr, bzg <at> gnu.org,
> 78474 <at> debbugs.gnu.org
>
> Eli Zaretskii, le mar. 22 juil. 2025 16:24:47 +0300, a ecrit:
> > > From: Samuel Thibault <samuel.thibault <at> gnu.org>
> > > Eli Zaretskii, le mar. 22 juil. 2025 15:03:52 +0300, a ecrit:
> > > > Of course, specially-tailored cases could be concocted which show the
> > > > contrary, but that's not what this code is about. The request in this
> > > > bug report, AFAIU, was to disable the use of TABs _in_all_cases_,
> > >
> > > No.
> > >
> > > “
> > > Quoting Samuel: "Emacs, instead of sending a rightward cursor movement
> > > (\e[C), sends \009\008 (a tabulation and a leftward cursor movement)"
> > >
> > > This char insertion problem confuses assistive technologies for the
> > > visually impaired.
> > > ”
> >
> > We are mis-communicating. When I said "in all cases", I meant even
> > when TABs do not cause any problems and/or when screen-reading
> > software is not used at all.
>
> But we were talking about my benchmark moving only by one character
> (where the optimization loses) vs moving by 8 characters (where it
> most probably wins since that's 8 interpretations and 8 bytes vs 1
> interpretation and 1 byte).
>
> The discussion was not about it being a default for everybody or not.
Correct me if I'm wrong, but there was a request to disable sending
\t\b sequence on all the terminals, even on those which process \t\b
correctly and if the screen-reading software is not being used, right?
That is what I mean by "in all cases", and we are definitely
discussing this issue, the alternative being that either (a) users who
are affected will have to manually disable the use of \t\b, or (b) we
will find a way to disable \t\b automatically on systems and/or for
users that _are_ affected.
> > > I don't remember really asking for more than that.
> >
> > A reminder from https://debbugs.gnu.org/cgi/bugreport.cgi?bug=78474#77
>
> Yes, and I do agree with really asking for that one: we don't want to
> put the burden of configuration on people who already have a hard time
> using computers.
So we agree: disabling \t\b "in all cases" is what is being discussed.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#78474; Package
emacs.
(Wed, 23 Jul 2025 10:57:02 GMT)
Full text and
rfc822 format available.
Message #344 received at 78474 <at> debbugs.gnu.org (full text, mbox):
> Date: Tue, 22 Jul 2025 19:57:39 +0200
> From: Samuel Thibault <samuel.thibault <at> gnu.org>
> Cc: rpluim <at> gmail.com, Sebastien.Hinderer <at> inria.fr, bzg <at> gnu.org,
> 78474 <at> debbugs.gnu.org
>
> Eli Zaretskii, le mar. 22 juil. 2025 16:31:54 +0300, a ecrit:
> > Also, what about the "stty -tabs" workaround -- does it work with vte
> > and rxvt?
>
> Of course, since emacs then duly respects not using tabs at all.
>
> But again, that's to be configured (and even more arcane than modifying
> .emacs)
Yes. But it is nice to know there's a workaround (e.g., for versions
of Emacs which were already released).
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#78474; Package
emacs.
(Wed, 23 Jul 2025 11:00:02 GMT)
Full text and
rfc822 format available.
Message #347 received at 78474 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii, le mer. 23 juil. 2025 13:50:24 +0300, a ecrit:
> > Date: Tue, 22 Jul 2025 19:49:31 +0200
> > From: Samuel Thibault <samuel.thibault <at> gnu.org>
> > Cc: bzg <at> gnu.org, 78474 <at> debbugs.gnu.org, rpluim <at> gmail.com
> >
> > Eli Zaretskii, le mar. 22 juil. 2025 18:47:18 +0300, a ecrit:
> > > Btw, let me make sure I understand correctly: is screen-reading
> > > software affected by this only on those two kinds of terminals (rxvt
> > > and vte), where \t\b produces wrong output?
> >
> > Yes. But vte happens to be the only terminal layer that implements
> > accessibility. Screen readers cannot be used with all the others.
> >
> > Seb Hinderer, le mar. 22 juil. 2025 18:05:14 +0200, a ecrit:
> > > I am not completely sure and would rather let Samuel complete here. What
> > > I know isthat libvte is used for several terminals so I expect all of
> > > them to be affected.
> >
> > Yes, there is a dozen of those in Debian, at least.
>
> Can you name them, please?
The whole set of packages that depend on libvte is:
Package: aghermann
Package: astroidmail
Package: blackbox-terminal
Package: cairo-dock-plug-ins
Package: cdebconf-terminal
Package: cdebconf-terminal
Package: cherrytree
Package: easyssh
Package: emacs-libvterm
Package: geany-plugins
Package: gedit-plugins
Package: genius
Package: gnome-boxes
Package: gnome-builder
Package: gnome-console
Package: gnome-terminal
Package: gtk-d
Package: gtkterm
Package: haskell-gi-vte
Package: lxterminal
Package: mate-terminal
Package: mssh
Package: neovim
Package: pluma-plugins
Package: ptyxis
Package: qemu
Package: rasmol
Package: remmina
Package: sakura
Package: synaptic
Package: terminus
Package: termit
Package: tilda
Package: tilix
Package: timeshift
Package: virt-viewer
Package: xcfa
Package: xfce4-terminal
Among which some are indeed terminals that run a shell, others use it to
display information, etc.
My point is: there is a dozen now, and there will be more later. We
can't rely on knowling the list.
> > > If only those two terminals are affected, both in the effect of the
> > > cursor motion and what that does to screen readers, then we could
> > > disable the \t\b sequence only for those two terminals. Emacs can
> > > look at the name of the terminal to decide what to do.
> >
> > No, it cannot.
>
> Why not?
Because of the details below.
> > Eli Zaretskii, le mar. 22 juil. 2025 19:59:50 +0300, a ecrit:
> > > > > Emacs can look at the name of the terminal to decide what to do.
> > > >
> > > > Would that be ssh-proof?
> > >
> > > You need to set TERM in the ssh session.
> >
> > Yes, although libvte announces itself as xterm-256color.
>
> So we could have a terminal which sets TERM=xterm-256color, but which
> doesn't behave like xterm does?
Again, the question is: what is the expected behavior of
echo 'a\ta'
And yes, a lot of terminals just announce themselves as xterm in TERM,
that's how it is nowadays. Fighting it is a lost cause nowadays.
> > > > And what about running screen or tmux in such a terminal?
> > >
> > > Again, TERM should be set.
> >
> > In that case it's actually screen and tmux that interpret sequences, and
> > TERM is then screen and tmux. And those happen not to be using the \t\b
> > trick when re-displaying their output, so they "fix" the issue.
>
> Thus no problem.
For that case, yes.
Samuel
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#78474; Package
emacs.
(Wed, 23 Jul 2025 11:04:01 GMT)
Full text and
rfc822 format available.
Message #350 received at 78474 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii, le mer. 23 juil. 2025 13:55:06 +0300, a ecrit:
> > Eli Zaretskii, le mar. 22 juil. 2025 16:24:47 +0300, a ecrit:
> > > > From: Samuel Thibault <samuel.thibault <at> gnu.org>
> > > > Eli Zaretskii, le mar. 22 juil. 2025 15:03:52 +0300, a ecrit:
> > > > > Of course, specially-tailored cases could be concocted which show the
> > > > > contrary, but that's not what this code is about. The request in this
> > > > > bug report, AFAIU, was to disable the use of TABs _in_all_cases_,
> > > >
> > > > No.
> > > >
> > > > “
> > > > Quoting Samuel: "Emacs, instead of sending a rightward cursor movement
> > > > (\e[C), sends \009\008 (a tabulation and a leftward cursor movement)"
> > > >
> > > > This char insertion problem confuses assistive technologies for the
> > > > visually impaired.
> > > > ”
> > >
> > > We are mis-communicating. When I said "in all cases", I meant even
> > > when TABs do not cause any problems and/or when screen-reading
> > > software is not used at all.
> >
> > But we were talking about my benchmark moving only by one character
> > (where the optimization loses) vs moving by 8 characters (where it
> > most probably wins since that's 8 interpretations and 8 bytes vs 1
> > interpretation and 1 byte).
> >
> > The discussion was not about it being a default for everybody or not.
>
> Correct me if I'm wrong, but there was a request to disable sending
> \t\b sequence on all the terminals,
There was, but not in that part of the conversation: "specially-tailored
cases could be concocted" was about the performance question. The "in
all cases" could refer to "by default" or to "for all tabs or just for
\t\b". I really only talk about the latter, and the performance figures
I showed was about that. Which then argues for making it a default,
since it'll benefit everybody! Instead of trying to find a way to change
the default depending a screen reader is there or not, which, really, is
not going to happen in a robust way.
> > > > I don't remember really asking for more than that.
> > >
> > > A reminder from https://debbugs.gnu.org/cgi/bugreport.cgi?bug=78474#77
> >
> > Yes, and I do agree with really asking for that one: we don't want to
> > put the burden of configuration on people who already have a hard time
> > using computers.
>
> So we agree: disabling \t\b "in all cases" is what is being discussed.
Yes.
Samuel
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#78474; Package
emacs.
(Wed, 23 Jul 2025 11:17:02 GMT)
Full text and
rfc822 format available.
Message #353 received at 78474 <at> debbugs.gnu.org (full text, mbox):
> Date: Tue, 22 Jul 2025 20:04:06 +0200
> From: Samuel Thibault <samuel.thibault <at> gnu.org>
> Cc: rpluim <at> gmail.com, Sebastien.Hinderer <at> inria.fr, bzg <at> gnu.org,
> 78474 <at> debbugs.gnu.org
>
> Eli Zaretskii, le mar. 22 juil. 2025 16:18:48 +0300, a ecrit:
> > > Eli Zaretskii, le mar. 22 juil. 2025 14:28:19 +0300, a ecrit:
> > > > > I have tried the attached test which reproduces both ways and reports
> > > > > the time to achieve one million iteration, on my system:
> > > > >
> > > > > - with rxvt: non-optimized way takes ~1.9s, optimized way takes ~2.1s.
> > > > > - with mate-terminal: non-optimized way takes ~1.8s, optimized way takes
> > > > > ~2.0s.
> > > > >
> > > > > So on my system at least the "optimized" way is actually slower.
> > > >
> > > > For that particular single case.
> > >
> > > Which is exactly the case that we are reporting about.
> >
> > No, it isn't. Not even if only \t\b should be disabled.
>
> ? I don't understand.
>
> \t\b really is the only issue that we are having.
The actual use of this affects much more. It affects any \t\t\t...\b
sequences (with multiple TABs), and it affects them in various places
in the line (thus different values of start and destination columns).
Perhaps also other cases (the code is quite convoluted, so I'm not
sure we understand all the implications of the proposed change). A
benchmark should use some approximately-representative sample of these
situations. A large C source file is a good test case.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#78474; Package
emacs.
(Wed, 23 Jul 2025 11:22:01 GMT)
Full text and
rfc822 format available.
Message #356 received at 78474 <at> debbugs.gnu.org (full text, mbox):
> Date: Tue, 22 Jul 2025 20:08:43 +0200
> From: Samuel Thibault <samuel.thibault <at> gnu.org>
> Cc: Sebastien.Hinderer <at> inria.fr, rpluim <at> gmail.com, bzg <at> gnu.org,
> 78474 <at> debbugs.gnu.org
>
> Eli Zaretskii, le mar. 22 juil. 2025 16:42:29 +0300, a ecrit:
> > > Samuel Thibault, le mar. 22 juil. 2025 14:16:02 +0200, a ecrit:
> > > and end up seeing a hardcoded
> > > list of the screen readers that are fortunate enough to be known enough
> > > to get the proper behavior of emacs in vte,
> >
> > Emacs makes it very easy to modify such databases. Saying the names
> > of such programs are "hardcoded" is not really accurate for Emacs,
> > because we can expose the list as a user option, so users could easily
> > add/remove programs as needed.
>
> But it's *really* hard for users to walk the way from "the cursor does
> not move when I press space!" down to "maybe I should try disabling the
> use of tab for optimization". I don't think Sebastien would have found
> such an option or even thought it could have existed.
I disagree that it's so impossibly hard. We have gobs of similar
knobs in Emacs, and Internet search is a handy tool to make these
discoverable. We also plan adding a special "Accessibility" section
to the user manual, which will make this even easier.
But anyway, let's postpone this discussion to when (and if) we decide
that the default will be to leave \t\b enabled. It is not useful to
argue about decisions that are not yet imminent. We are still
discussing possible ways of disabling \t\b where that matters, which
from my POV is a better alternative.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#78474; Package
emacs.
(Wed, 23 Jul 2025 11:23:02 GMT)
Full text and
rfc822 format available.
Message #359 received at 78474 <at> debbugs.gnu.org (full text, mbox):
> Date: Tue, 22 Jul 2025 20:15:51 +0200
> From: Samuel Thibault <samuel.thibault <at> gnu.org>
> Cc: Seb Hinderer <Sebastien.Hinderer <at> inria.fr>, rpluim <at> gmail.com,
> bzg <at> gnu.org, 78474 <at> debbugs.gnu.org
>
> Eli Zaretskii, le mar. 22 juil. 2025 17:26:06 +0300, a ecrit:
> > > Eli Zaretskii (2025/07/22 16:18 +0300):
> > > > What we need is to implement a prototype of the change to disable the
> > > > above, and then time it on a large enough buffer.
> > >
> > > Assuming the time actually does depend on the buffer's size, whihc I am
> > > very not convinced about.
> >
> > The buffer size is a means to get a good average measure of the speed.
>
> But it also makes saving one byte even less a bonus... I tried to write
> 100 right-left movements (\t\b\b vs \e[C\b) at a time, the \t\b trick
> takes ~30s while the standard \e[C takes ~5s.
As I wrote elsewhere, I'm interested in a real-life test case, such as
paging through xdisp.c or some other large C source file. Synthetic
test cases are less useful in this case.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#78474; Package
emacs.
(Wed, 23 Jul 2025 11:24:02 GMT)
Full text and
rfc822 format available.
Message #362 received at 78474 <at> debbugs.gnu.org (full text, mbox):
On Jul 21 2025, Samuel Thibault wrote:
> Also, if you run:
>
> echo -e 'a\t'
>
> is there actually supposed to be some content to copy/paste on the right
> of a?
The answer is the same as to this:
printf 'a \n'
--
Andreas Schwab, SUSE Labs, schwab <at> suse.de
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE 1748 E4D4 88E3 0EEA B9D7
"And now for something completely different."
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#78474; Package
emacs.
(Wed, 23 Jul 2025 11:25:02 GMT)
Full text and
rfc822 format available.
Message #365 received at 78474 <at> debbugs.gnu.org (full text, mbox):
> Date: Tue, 22 Jul 2025 20:20:39 +0200
> From: Samuel Thibault <samuel.thibault <at> gnu.org>
> Cc: rpluim <at> gmail.com, Sebastien.Hinderer <at> inria.fr, bzg <at> gnu.org,
> 78474 <at> debbugs.gnu.org
>
> Eli Zaretskii, le mar. 22 juil. 2025 16:31:54 +0300, a ecrit:
> > > If I had a text that explicitly says that \t produces content, it
> > > would be way easier to fix this on the vte side. For now, we have
> > > been stuck for a *decade* there.
> >
> > I think I understand, but the refusal of the vte developers to provide
> > some solution doesn't mean it becomes the responsibility of Emacs to
> > solve that, does it?
>
> emacs is the only program we know that uses such \t\b trick and thus
> poses cursor position problem.
Emacs is not just any program. There's nothing wrong in changing the
behavior of vte to cater to Emacs, at least as an option. You expect
us to do the same.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#78474; Package
emacs.
(Wed, 23 Jul 2025 11:27:03 GMT)
Full text and
rfc822 format available.
Message #368 received at 78474 <at> debbugs.gnu.org (full text, mbox):
> Date: Tue, 22 Jul 2025 20:27:17 +0200
> From: Samuel Thibault <samuel.thibault <at> gnu.org>
> Cc: rpluim <at> gmail.com, Sebastien.Hinderer <at> inria.fr, bzg <at> gnu.org,
> 78474 <at> debbugs.gnu.org
>
> > > They are fully part of the discussion, because that changes what is
> > > actually supposed to be stored in the terminal, and thus what the
> > > accessibility feature is supposed to expose to the user: should it
> > > expose a tab, or spaces. But if a tab, then how can the cursor be inside
> > > the tab when emitting \t\b. That's the *whole* problem at stake.
> >
> > So you are saying that even using cursor movement commands could cause
> > problems,
>
> The problem is that some people consider \t as not being only a cursor
> movement. That's the whole point of the question raised above.
I'm talking about cursor movement using "left" and "right" escape
sequences. If they also store something other than SPCes, they will
cause similar problems to screen readers, no?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#78474; Package
emacs.
(Wed, 23 Jul 2025 11:32:02 GMT)
Full text and
rfc822 format available.
Message #371 received at 78474 <at> debbugs.gnu.org (full text, mbox):
Andreas Schwab, le mer. 23 juil. 2025 13:23:21 +0200, a ecrit:
> On Jul 21 2025, Samuel Thibault wrote:
>
> > Also, if you run:
> >
> > echo -e 'a\t'
> >
> > is there actually supposed to be some content to copy/paste on the right
> > of a?
>
> The answer is the same as to this:
>
> printf 'a \n'
No...
And that's the whole problem.
space characters are destructive, while tab characters are not, try
echo -e 'a\r\tb'
vs
echo -e 'a\r b'
So it'd mean that tab characters don't produce content? Some people
argue that they should. I haven't found a document that explicitly says
what the *exact* expected result is.
Samuel
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#78474; Package
emacs.
(Wed, 23 Jul 2025 11:32:03 GMT)
Full text and
rfc822 format available.
Message #374 received at 78474 <at> debbugs.gnu.org (full text, mbox):
> Date: Tue, 22 Jul 2025 21:54:05 +0200
> From: Samuel Thibault <samuel.thibault <at> gnu.org>
> Cc: Robert Pluim <rpluim <at> gmail.com>, bzg <at> gnu.org,
> Sebastien.Hinderer <at> inria.fr, Eli Zaretskii <eliz <at> gnu.org>,
> 78474 <at> debbugs.gnu.org
>
> Re,
>
> Manuel Giraud, le mar. 22 juil. 2025 16:09:33 +0200, a ecrit:
> > >>>>>> On Tue, 22 Jul 2025 14:10:11 +0200, Samuel Thibault <samuel.thibault <at> gnu.org> said:
> > > That was my misinterpretation of the request. Itʼs easy enough to
> > > restrict the change to only affect the '\t\b' case, but weʼll have to
> > > come up with a new name for the user option :-)
> >
> > What about this?
>
> Yes, that works!
Thanks for testing.
What we need to make further progress is:
. make this change conditional on a variable that's exposed to Lisp
. benchmark the result by comparing the performance of text-mode
display while scrolling through a large C source file
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#78474; Package
emacs.
(Wed, 23 Jul 2025 11:33:01 GMT)
Full text and
rfc822 format available.
Message #377 received at 78474 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii, le mer. 23 juil. 2025 14:26:13 +0300, a ecrit:
> > Date: Tue, 22 Jul 2025 20:27:17 +0200
> > From: Samuel Thibault <samuel.thibault <at> gnu.org>
> > Cc: rpluim <at> gmail.com, Sebastien.Hinderer <at> inria.fr, bzg <at> gnu.org,
> > 78474 <at> debbugs.gnu.org
> >
> > > > They are fully part of the discussion, because that changes what is
> > > > actually supposed to be stored in the terminal, and thus what the
> > > > accessibility feature is supposed to expose to the user: should it
> > > > expose a tab, or spaces. But if a tab, then how can the cursor be inside
> > > > the tab when emitting \t\b. That's the *whole* problem at stake.
> > >
> > > So you are saying that even using cursor movement commands could cause
> > > problems,
> >
> > The problem is that some people consider \t as not being only a cursor
> > movement. That's the whole point of the question raised above.
>
> I'm talking about cursor movement using "left" and "right" escape
> sequences. If they also store something other than SPCes, they will
> cause similar problems to screen readers, no?
No, because for them there is no confusion between producing content or
not.
Samuel
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#78474; Package
emacs.
(Wed, 23 Jul 2025 11:35:01 GMT)
Full text and
rfc822 format available.
Message #380 received at 78474 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii, le mer. 23 juil. 2025 14:24:09 +0300, a ecrit:
> > Date: Tue, 22 Jul 2025 20:20:39 +0200
> > From: Samuel Thibault <samuel.thibault <at> gnu.org>
> > Cc: rpluim <at> gmail.com, Sebastien.Hinderer <at> inria.fr, bzg <at> gnu.org,
> > 78474 <at> debbugs.gnu.org
> >
> > Eli Zaretskii, le mar. 22 juil. 2025 16:31:54 +0300, a ecrit:
> > > > If I had a text that explicitly says that \t produces content, it
> > > > would be way easier to fix this on the vte side. For now, we have
> > > > been stuck for a *decade* there.
> > >
> > > I think I understand, but the refusal of the vte developers to provide
> > > some solution doesn't mean it becomes the responsibility of Emacs to
> > > solve that, does it?
> >
> > emacs is the only program we know that uses such \t\b trick and thus
> > poses cursor position problem.
>
> Emacs is not just any program. There's nothing wrong in changing the
> behavior of vte to cater to Emacs, at least as an option. You expect
> us to do the same.
And that's why Sébastien was previously talking about RFCs, because
they are the typical documents that people follow to make programs
behave correctly altogether.
Samuel
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#78474; Package
emacs.
(Wed, 23 Jul 2025 11:48:01 GMT)
Full text and
rfc822 format available.
Message #383 received at 78474 <at> debbugs.gnu.org (full text, mbox):
> From: Manuel Giraud <manuel <at> ledu-giraud.fr>
> Cc: Robert Pluim <rpluim <at> gmail.com>, bzg <at> gnu.org,
> Sebastien.Hinderer <at> inria.fr, Eli Zaretskii <eliz <at> gnu.org>,
> 78474 <at> debbugs.gnu.org
> Date: Wed, 23 Jul 2025 10:01:34 +0200
>
> Samuel Thibault <samuel.thibault <at> gnu.org> writes:
>
> > Re,
> >
> > Manuel Giraud, le mar. 22 juil. 2025 16:09:33 +0200, a ecrit:
> >> >>>>>> On Tue, 22 Jul 2025 14:10:11 +0200, Samuel Thibault
> >> > <samuel.thibault <at> gnu.org> said:
> >> > That was my misinterpretation of the request. Itʼs easy enough to
> >> > restrict the change to only affect the '\t\b' case, but weʼll have to
> >> > come up with a new name for the user option :-)
> >>
> >> What about this?
> >
> > Yes, that works!
>
> Thanks. So maybe next step is to decide if we keep this overshoot
> behaviour guarded behind a user option (I propose
> `inhibit-overshoot-in-tty-motions') and, the hard question, what should
> be its default?
I outlined the next step, let's please use them.
Thanks.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#78474; Package
emacs.
(Wed, 23 Jul 2025 11:49:02 GMT)
Full text and
rfc822 format available.
Message #386 received at 78474 <at> debbugs.gnu.org (full text, mbox):
> From: Andreas Schwab <schwab <at> suse.de>
> Cc: Eli Zaretskii <eliz <at> gnu.org>, bzg <at> gnu.org, Seb Hinderer
> <Sebastien.Hinderer <at> inria.fr>, rpluim <at> gmail.com, 78474 <at> debbugs.gnu.org
> Date: Wed, 23 Jul 2025 10:06:19 +0200
>
> On Jul 22 2025, Samuel Thibault wrote:
>
> > Andreas Schwab, le mar. 22 juil. 2025 15:48:20 +0200, a ecrit:
> >> On Jul 21 2025, Samuel Thibault wrote:
> >>
> >> > It is. Cat /dev/vcs, and you have it.
> >>
> >> /dev/vcs contains the rendered contents, so how they were drawn should
> >> not make any difference.
> >
> > The question of this thread piece was not about that, but about screen
> > readers being able to read the screen without getting announced to
> > applications in any way.
>
> Since screen readers using /dev/vcs are not affected by this issue they
> are irrelevant here.
So what do screen readers which _are_ affected by this issue use?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#78474; Package
emacs.
(Wed, 23 Jul 2025 11:56:02 GMT)
Full text and
rfc822 format available.
Message #389 received at 78474 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii, le mer. 23 juil. 2025 14:48:32 +0300, a ecrit:
> > From: Andreas Schwab <schwab <at> suse.de>
> > Cc: Eli Zaretskii <eliz <at> gnu.org>, bzg <at> gnu.org, Seb Hinderer
> > <Sebastien.Hinderer <at> inria.fr>, rpluim <at> gmail.com, 78474 <at> debbugs.gnu.org
> > Date: Wed, 23 Jul 2025 10:06:19 +0200
> >
> > On Jul 22 2025, Samuel Thibault wrote:
> >
> > > Andreas Schwab, le mar. 22 juil. 2025 15:48:20 +0200, a ecrit:
> > >> On Jul 21 2025, Samuel Thibault wrote:
> > >>
> > >> > It is. Cat /dev/vcs, and you have it.
> > >>
> > >> /dev/vcs contains the rendered contents, so how they were drawn should
> > >> not make any difference.
> > >
> > > The question of this thread piece was not about that, but about screen
> > > readers being able to read the screen without getting announced to
> > > applications in any way.
> >
> > Since screen readers using /dev/vcs are not affected by this issue they
> > are irrelevant here.
>
> So what do screen readers which _are_ affected by this issue use?
At-spi, which exposes the graphical interfaces to the screen readers.
Just like the cat /dev/vcs case, applications inside the terminal are
not notified whether a screen reader is reading them or not.
Samuel
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#78474; Package
emacs.
(Wed, 23 Jul 2025 12:03:02 GMT)
Full text and
rfc822 format available.
Message #392 received at 78474 <at> debbugs.gnu.org (full text, mbox):
> Date: Wed, 23 Jul 2025 12:59:08 +0200
> From: Samuel Thibault <samuel.thibault <at> gnu.org>
> Cc: Sebastien.Hinderer <at> inria.fr, bzg <at> gnu.org, 78474 <at> debbugs.gnu.org,
> rpluim <at> gmail.com
>
> Eli Zaretskii, le mer. 23 juil. 2025 13:50:24 +0300, a ecrit:
> > > Seb Hinderer, le mar. 22 juil. 2025 18:05:14 +0200, a ecrit:
> > > > I am not completely sure and would rather let Samuel complete here. What
> > > > I know isthat libvte is used for several terminals so I expect all of
> > > > them to be affected.
> > >
> > > Yes, there is a dozen of those in Debian, at least.
> >
> > Can you name them, please?
>
> The whole set of packages that depend on libvte is:
Thanks, but I asked only about terminals, because only those are
relevant to this discussion. (Actually, we are only interested in
terminals on which users could run "emacs -nw".) Can you name only
those?
> My point is: there is a dozen now, and there will be more later. We
> can't rely on knowling the list.
As mentioned earlier, Emacs already does terminal-specific stuff when
it starts, so the sheer number of affected terminals is not a problem.
> > > Yes, although libvte announces itself as xterm-256color.
> >
> > So we could have a terminal which sets TERM=xterm-256color, but which
> > doesn't behave like xterm does?
>
> Again, the question is: what is the expected behavior of
>
> echo 'a\ta'
I think I already answered that.
> And yes, a lot of terminals just announce themselves as xterm in TERM,
> that's how it is nowadays. Fighting it is a lost cause nowadays.
We have lisp/term/xterm.el where we can set the new variable to
whatever value we decide. We don't need to fight anyone.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#78474; Package
emacs.
(Wed, 23 Jul 2025 12:10:02 GMT)
Full text and
rfc822 format available.
Message #395 received at 78474 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii, le mer. 23 juil. 2025 15:01:44 +0300, a ecrit:
> > Date: Wed, 23 Jul 2025 12:59:08 +0200
> > From: Samuel Thibault <samuel.thibault <at> gnu.org>
> > Cc: Sebastien.Hinderer <at> inria.fr, bzg <at> gnu.org, 78474 <at> debbugs.gnu.org,
> > rpluim <at> gmail.com
> >
> > Eli Zaretskii, le mer. 23 juil. 2025 13:50:24 +0300, a ecrit:
> > > > Seb Hinderer, le mar. 22 juil. 2025 18:05:14 +0200, a ecrit:
> > > > > I am not completely sure and would rather let Samuel complete here. What
> > > > > I know isthat libvte is used for several terminals so I expect all of
> > > > > them to be affected.
> > > >
> > > > Yes, there is a dozen of those in Debian, at least.
> > >
> > > Can you name them, please?
> >
> > The whole set of packages that depend on libvte is:
>
> Thanks, but I asked only about terminals, because only those are
> relevant to this discussion. (Actually, we are only interested in
> terminals on which users could run "emacs -nw".) Can you name only
> those?
Determining the list is useless: there is no way for emacs to determine
what terminal it is in. Applications in the terminal cannot know where
in at-spi the terminal is, and thus the application that runs it.
> > echo 'a\ta'
>
> I think I already answered that.
No.
As I have repeated myself several times, I still haven't seen an actual
document that describes *exactly* what this is supposed to do.
> > And yes, a lot of terminals just announce themselves as xterm in TERM,
> > that's how it is nowadays. Fighting it is a lost cause nowadays.
>
> We have lisp/term/xterm.el where we can set the new variable to
> whatever value we decide.
What new variable and what value? I cannot make any sense from this
sentence.
Samuel
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#78474; Package
emacs.
(Wed, 23 Jul 2025 12:14:02 GMT)
Full text and
rfc822 format available.
Message #398 received at 78474 <at> debbugs.gnu.org (full text, mbox):
Hello,
Eli Zaretskii, le mer. 23 juil. 2025 14:31:23 +0300, a ecrit:
> . benchmark the result by comparing the performance of text-mode
> display while scrolling through a large C source file
How can we measure that?
Human-triggered timing will never be accurate enough to notice anything.
(that's why I was using synthetic measurements).
Samuel
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#78474; Package
emacs.
(Wed, 23 Jul 2025 12:23:01 GMT)
Full text and
rfc822 format available.
Message #401 received at 78474 <at> debbugs.gnu.org (full text, mbox):
> Date: Wed, 23 Jul 2025 09:52:10 +0200
> From: Sébastien Hinderer <Sebastien.Hinderer <at> inria.fr>
> Cc: Eli Zaretskii <eliz <at> gnu.org>, rpluim <at> gmail.com, bzg <at> gnu.org,
> 78474 <at> debbugs.gnu.org
>
> A very friendly note to the Emacs maintainers whoare reading this
> thread: my intention is *not* tomake you feel bad. I appreciate that you
> are here, discuss, genuinely try tounderstand. Precisely, to broaden
> your understanding, I would like to explain one point you may be missing
> and it's certainly not your faul if you are missing it, but please read
> me and think over it.
>
> The discussion we are currently having with you, wehave to haveon
> dozens and dozens of projects. So yes, having to have such discussions
> again and again is super tiring and it's kind of a miracle that people
> like Samuel are still there, although not directly concerned.
>
> We try to suggest solutions that are viable, as "main stream" as
> possible because we believe that the best thing that can happen to
> accessibility is that it gets integrated to programs as readily as
> possible.
>
> As much as possible, we would like to avoid that accessibility has to go
> to dedicated code paths because we know from experience tat, in the long
> run, such code paths will receive less testing and maintenance
> attenition.
>
> And I think this becomes even more true if, as it seems to be the case
> here, the proposed code is actually cleaner, more efficient and more
> standard than what was done before. Tome, the fact that the former code
> has not had to change for decades does not mean it shouldn't be changed
> now.
Your point is well taken!
However, please also see this and other similar issues from our POV.
Emacs users are a legion, and they use Emacs in many different usage
patterns and on many different platforms. We cannot risk making
changes that might adversely affect some group of users, because some
other group of users wants the change and considers it important, or
even if we ourselves consider the change important. The reason is
simple: the people who want the change will go away satisfied, but the
others will come to us complaining, and we will face the same problem
once again.
Emacs users trust us not to break or adversely affect functionality
that existed for decades. We try very hard not to betray that trust.
That is why we must carefully examine the effects of the proposed
changes, to make sure we understand them and to avoid causing
regressions in some cases, and we must explore all the possible
solutions that could give each one what they want without adversely
affecting the others. And that is what I'm trying to do. So please
bear with me and help me understand both the problem and its causes,
and the effect of each proposed solution, so that the decision will
not be just moving the problem from one group of users to another.
Thanks.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#78474; Package
emacs.
(Wed, 23 Jul 2025 16:14:01 GMT)
Full text and
rfc822 format available.
Message #404 received at 78474 <at> debbugs.gnu.org (full text, mbox):
> Date: Wed, 23 Jul 2025 14:09:05 +0200
> From: Samuel Thibault <samuel.thibault <at> gnu.org>
> Cc: Sebastien.Hinderer <at> inria.fr, bzg <at> gnu.org, 78474 <at> debbugs.gnu.org,
> rpluim <at> gmail.com
>
> Eli Zaretskii, le mer. 23 juil. 2025 15:01:44 +0300, a ecrit:
> > Thanks, but I asked only about terminals, because only those are
> > relevant to this discussion. (Actually, we are only interested in
> > terminals on which users could run "emacs -nw".) Can you name only
> > those?
>
> Determining the list is useless: there is no way for emacs to determine
> what terminal it is in.
Emacs looks at the value of TERM in the environment to determine that.
> > > echo 'a\ta'
> >
> > I think I already answered that.
>
> No.
>
> As I have repeated myself several times, I still haven't seen an actual
> document that describes *exactly* what this is supposed to do.
I gave you my answer. I cannot provide any documents, especially
since they don't exist.
> > > And yes, a lot of terminals just announce themselves as xterm in TERM,
> > > that's how it is nowadays. Fighting it is a lost cause nowadays.
> >
> > We have lisp/term/xterm.el where we can set the new variable to
> > whatever value we decide.
>
> What new variable and what value?
The variable that will condition the change in cm.c.
> I cannot make any sense from this sentence.
How about now?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#78474; Package
emacs.
(Wed, 23 Jul 2025 16:16:01 GMT)
Full text and
rfc822 format available.
Message #407 received at 78474 <at> debbugs.gnu.org (full text, mbox):
> Date: Wed, 23 Jul 2025 14:13:37 +0200
> From: Samuel Thibault <samuel.thibault <at> gnu.org>
> Cc: manuel <at> ledu-giraud.fr, rpluim <at> gmail.com, bzg <at> gnu.org,
> Sebastien.Hinderer <at> inria.fr, 78474 <at> debbugs.gnu.org
>
> Eli Zaretskii, le mer. 23 juil. 2025 14:31:23 +0300, a ecrit:
> > . benchmark the result by comparing the performance of text-mode
> > display while scrolling through a large C source file
>
> How can we measure that?
We have a scrolling benchmark which could be useful. I'd start with
that.
> Human-triggered timing will never be accurate enough to notice anything.
Robert described a qualitative benchmark he did, which certainly
provides a data point. Of course, quantitative measures are better.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#78474; Package
emacs.
(Wed, 23 Jul 2025 16:17:02 GMT)
Full text and
rfc822 format available.
Message #410 received at 78474 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii, le mer. 23 juil. 2025 19:13:28 +0300, a ecrit:
> > Date: Wed, 23 Jul 2025 14:09:05 +0200
> > From: Samuel Thibault <samuel.thibault <at> gnu.org>
> > Cc: Sebastien.Hinderer <at> inria.fr, bzg <at> gnu.org, 78474 <at> debbugs.gnu.org,
> > rpluim <at> gmail.com
> >
> > Eli Zaretskii, le mer. 23 juil. 2025 15:01:44 +0300, a ecrit:
> > > Thanks, but I asked only about terminals, because only those are
> > > relevant to this discussion. (Actually, we are only interested in
> > > terminals on which users could run "emacs -nw".) Can you name only
> > > those?
> >
> > Determining the list is useless: there is no way for emacs to determine
> > what terminal it is in.
>
> Emacs looks at the value of TERM in the environment to determine that.
Again, for *all* of them, TERM will be just xterm-color256
Samuel
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#78474; Package
emacs.
(Wed, 23 Jul 2025 16:19:02 GMT)
Full text and
rfc822 format available.
Message #413 received at 78474 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii, le mer. 23 juil. 2025 19:15:36 +0300, a ecrit:
> > Eli Zaretskii, le mer. 23 juil. 2025 14:31:23 +0300, a ecrit:
> > > . benchmark the result by comparing the performance of text-mode
> > > display while scrolling through a large C source file
> >
> > How can we measure that?
>
> We have a scrolling benchmark which could be useful. I'd start with
> that.
How to start it / where to find it?
(I almost never use emacs)
(yes, web-crawling for "emacs" "scrolling" "benchmark" didn't bring any
useful answer)
Samuel
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#78474; Package
emacs.
(Wed, 23 Jul 2025 16:46:01 GMT)
Full text and
rfc822 format available.
Message #416 received at 78474 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii <eliz <at> gnu.org> writes:
>> From: Manuel Giraud <manuel <at> ledu-giraud.fr>
>> Cc: Robert Pluim <rpluim <at> gmail.com>, bzg <at> gnu.org,
>> Sebastien.Hinderer <at> inria.fr, Eli Zaretskii <eliz <at> gnu.org>,
>> 78474 <at> debbugs.gnu.org
>> Date: Wed, 23 Jul 2025 10:01:34 +0200
>>
>> Samuel Thibault <samuel.thibault <at> gnu.org> writes:
>>
>> > Re,
>> >
>> > Manuel Giraud, le mar. 22 juil. 2025 16:09:33 +0200, a ecrit:
>> >> >>>>>> On Tue, 22 Jul 2025 14:10:11 +0200, Samuel Thibault
>> >> > <samuel.thibault <at> gnu.org> said:
>> >> > That was my misinterpretation of the request. Itʼs easy enough to
>> >> > restrict the change to only affect the '\t\b' case, but weʼll have to
>> >> > come up with a new name for the user option :-)
>> >>
>> >> What about this?
>> >
>> > Yes, that works!
>>
>> Thanks. So maybe next step is to decide if we keep this overshoot
>> behaviour guarded behind a user option (I propose
>> `inhibit-overshoot-in-tty-motions') and, the hard question, what should
>> be its default?
>
> I outlined the next step, let's please use them.
Of course. I didn't mean to overstep here and was just thinking out
loud what would the next step IMO.
--
Manuel Giraud
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#78474; Package
emacs.
(Wed, 23 Jul 2025 16:55:01 GMT)
Full text and
rfc822 format available.
Message #419 received at 78474 <at> debbugs.gnu.org (full text, mbox):
> Date: Wed, 23 Jul 2025 18:16:00 +0200
> From: Samuel Thibault <samuel.thibault <at> gnu.org>
> Cc: Sebastien.Hinderer <at> inria.fr, bzg <at> gnu.org, 78474 <at> debbugs.gnu.org,
> rpluim <at> gmail.com
>
> Eli Zaretskii, le mer. 23 juil. 2025 19:13:28 +0300, a ecrit:
> > > Date: Wed, 23 Jul 2025 14:09:05 +0200
> > > From: Samuel Thibault <samuel.thibault <at> gnu.org>
> > > Cc: Sebastien.Hinderer <at> inria.fr, bzg <at> gnu.org, 78474 <at> debbugs.gnu.org,
> > > rpluim <at> gmail.com
> > >
> > > Eli Zaretskii, le mer. 23 juil. 2025 15:01:44 +0300, a ecrit:
> > > > Thanks, but I asked only about terminals, because only those are
> > > > relevant to this discussion. (Actually, we are only interested in
> > > > terminals on which users could run "emacs -nw".) Can you name only
> > > > those?
> > >
> > > Determining the list is useless: there is no way for emacs to determine
> > > what terminal it is in.
> >
> > Emacs looks at the value of TERM in the environment to determine that.
>
> Again, for *all* of them, TERM will be just xterm-color256
Then we could decide to disable \t\b in lisp/term/xterm.el.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#78474; Package
emacs.
(Wed, 23 Jul 2025 17:08:02 GMT)
Full text and
rfc822 format available.
Message #422 received at 78474 <at> debbugs.gnu.org (full text, mbox):
> Date: Wed, 23 Jul 2025 18:18:14 +0200
> From: Samuel Thibault <samuel.thibault <at> gnu.org>
> Cc: manuel <at> ledu-giraud.fr, rpluim <at> gmail.com, bzg <at> gnu.org,
> Sebastien.Hinderer <at> inria.fr, 78474 <at> debbugs.gnu.org
>
> Eli Zaretskii, le mer. 23 juil. 2025 19:15:36 +0300, a ecrit:
> > > Eli Zaretskii, le mer. 23 juil. 2025 14:31:23 +0300, a ecrit:
> > > > . benchmark the result by comparing the performance of text-mode
> > > > display while scrolling through a large C source file
> > >
> > > How can we measure that?
> >
> > We have a scrolling benchmark which could be useful. I'd start with
> > that.
>
> How to start it / where to find it?
>
> (I almost never use emacs)
Sorry, I wasn't aware of that.
Here's what I usually use:
(defun scroll-up-benchmark ()
(interactive)
(let ((oldgc gcs-done)
(oldtime (float-time)))
(condition-case nil (while t (scroll-up) (redisplay))
(error (message "GCs: %d Elapsed time: %f seconds"
(- gcs-done oldgc) (- (float-time) oldtime))))))
Evaluate this in an interactive session, then visit src/xdisp.c, and
invoke the command. Wait until it finishes scrolling and record the
time it shows. Then run the same in the version with the patch, and
compare the times.
Note: you need to run this in a fresh Emacs session, i.e. never run
the benchmark twice in the same session.
Robert also mentioned that leaning on C-v and noticing when Emacs
display starts "stuttering", meaning it cannot keep up with the
auto-repeat rate of the keyboard, is also something useful -- provided
you can notice the percentage into the file that is shown in the mode
line when it starts to "stutter". If it starts stuttering earlier, it
means the display code works harder.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#78474; Package
emacs.
(Wed, 23 Jul 2025 17:17:01 GMT)
Full text and
rfc822 format available.
Message #425 received at 78474 <at> debbugs.gnu.org (full text, mbox):
> Cc: bzg <at> gnu.org, Sebastien.Hinderer <at> inria.fr, rpluim <at> gmail.com,
> manuel <at> ledu-giraud.fr, 78474 <at> debbugs.gnu.org
> Date: Wed, 23 Jul 2025 20:06:57 +0300
> From: Eli Zaretskii <eliz <at> gnu.org>
>
> (defun scroll-up-benchmark ()
> (interactive)
> (let ((oldgc gcs-done)
> (oldtime (float-time)))
> (condition-case nil (while t (scroll-up) (redisplay))
> (error (message "GCs: %d Elapsed time: %f seconds"
> (- gcs-done oldgc) (- (float-time) oldtime))))))
>
> Evaluate this in an interactive session, then visit src/xdisp.c, and
> invoke the command. Wait until it finishes scrolling and record the
> time it shows. Then run the same in the version with the patch, and
> compare the times.
Btw, please also record which terminal(s) you benchmark this. I'd
like this to be measured at least on the most popular terminals,
because there could be differences.
Thanks.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#78474; Package
emacs.
(Wed, 23 Jul 2025 20:30:02 GMT)
Full text and
rfc822 format available.
Message #428 received at 78474 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii, le mer. 23 juil. 2025 20:06:57 +0300, a ecrit:
> Evaluate this in an interactive session, then visit src/xdisp.c, and
> invoke the command. Wait until it finishes scrolling and record the
> time it shows.
Ok, thanks.
> Note: you need to run this in a fresh Emacs session, i.e. never run
> the benchmark twice in the same session.
Yes, sure.
I performed 10 measurements with the venerable xterm, and a couple
measurements with the vte-based mate-terminal, rxvt, and Eterm.
The choice of terminal hardly changes anything at all. It's emacs that
consumes one core 100%, while the terminal consumes 1-3% only.
Here are the measurements:
With \e[C:
xterm
18.515394
18.516340
18.453698
18.576480
18.454190
18.530091
18.392103
18.484421
18.422035
18.469797
mate
18.595872
18.501546
rxvt
18.500069
18.423311
Eterm
18.428876
18.460808
With \t\b:
xterm
18.310599
18.583103
18.464580
18.516165
18.424753
18.498778
18.377242
18.445612
18.407960
18.505874
mate
18.551353
18.503176
rxvt
18.396504
18.340624
Eterm
18.544554
18.423233
So the average difference on xterm (0.03s) is completely inside the standard deviation (~0.06s)...
Samuel
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#78474; Package
emacs.
(Thu, 24 Jul 2025 06:42:01 GMT)
Full text and
rfc822 format available.
Message #431 received at 78474 <at> debbugs.gnu.org (full text, mbox):
> Date: Wed, 23 Jul 2025 22:29:30 +0200
> From: Samuel Thibault <samuel.thibault <at> gnu.org>
> Cc: manuel <at> ledu-giraud.fr, rpluim <at> gmail.com, bzg <at> gnu.org,
> Sebastien.Hinderer <at> inria.fr, 78474 <at> debbugs.gnu.org
>
> Eli Zaretskii, le mer. 23 juil. 2025 20:06:57 +0300, a ecrit:
> > Evaluate this in an interactive session, then visit src/xdisp.c, and
> > invoke the command. Wait until it finishes scrolling and record the
> > time it shows.
>
> Ok, thanks.
>
> > Note: you need to run this in a fresh Emacs session, i.e. never run
> > the benchmark twice in the same session.
>
> Yes, sure.
>
> I performed 10 measurements with the venerable xterm, and a couple
> measurements with the vte-based mate-terminal, rxvt, and Eterm.
> The choice of terminal hardly changes anything at all. It's emacs that
> consumes one core 100%, while the terminal consumes 1-3% only.
>
> Here are the measurements:
>
> With \e[C:
>
> xterm
> 18.515394
> 18.516340
> 18.453698
> 18.576480
> 18.454190
> 18.530091
> 18.392103
> 18.484421
> 18.422035
> 18.469797
>
> mate
> 18.595872
> 18.501546
>
> rxvt
> 18.500069
> 18.423311
>
> Eterm
> 18.428876
> 18.460808
>
> With \t\b:
>
> xterm
> 18.310599
> 18.583103
> 18.464580
> 18.516165
> 18.424753
> 18.498778
> 18.377242
> 18.445612
> 18.407960
> 18.505874
>
> mate
> 18.551353
> 18.503176
>
> rxvt
> 18.396504
> 18.340624
>
> Eterm
> 18.544554
> 18.423233
>
> So the average difference on xterm (0.03s) is completely inside the standard deviation (~0.06s)...
Thanks.
I'd encourage others to run similar benchmarks on these and other
terminals. Gnome-terminal, alacritty, kitty, screen, tmux, and the
Linux console come to mind. Also, if someone can test this in a
remote-login session, especially over a slow connection, those numbers
would be important to have.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#78474; Package
emacs.
(Thu, 24 Jul 2025 07:16:02 GMT)
Full text and
rfc822 format available.
Message #434 received at 78474 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii, le jeu. 24 juil. 2025 09:40:43 +0300, a ecrit:
> > From: Samuel Thibault <samuel.thibault <at> gnu.org>
> > The choice of terminal hardly changes anything at all. It's emacs that
> > consumes one core 100%, while the terminal consumes 1-3% only.
>
> I'd encourage others to run similar benchmarks on these and other
> terminals. Gnome-terminal, alacritty, kitty, screen, tmux, and the
> Linux console come to mind. Also, if someone can test this in a
> remote-login session, especially over a slow connection, those numbers
> would be important to have.
Really, I strongly doubt there will be any kind of difference, since
it's emacs that goes 100% cpu and the terminal does essentially nothing.
I tried via ssh, screen and tmux to check, it's just all the
same: emacs eating 100% and ssh not even eating 1%.
(gnome-terminal is libvte-based, so it's the same as mate-terminal)
Samuel
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#78474; Package
emacs.
(Thu, 24 Jul 2025 07:39:01 GMT)
Full text and
rfc822 format available.
Message #437 received at 78474 <at> debbugs.gnu.org (full text, mbox):
> Date: Thu, 24 Jul 2025 09:14:46 +0200
> From: Samuel Thibault <samuel.thibault <at> gnu.org>
> Cc: manuel <at> ledu-giraud.fr, rpluim <at> gmail.com, bzg <at> gnu.org,
> Sebastien.Hinderer <at> inria.fr, 78474 <at> debbugs.gnu.org
>
> Eli Zaretskii, le jeu. 24 juil. 2025 09:40:43 +0300, a ecrit:
> > > From: Samuel Thibault <samuel.thibault <at> gnu.org>
> > > The choice of terminal hardly changes anything at all. It's emacs that
> > > consumes one core 100%, while the terminal consumes 1-3% only.
> >
> > I'd encourage others to run similar benchmarks on these and other
> > terminals. Gnome-terminal, alacritty, kitty, screen, tmux, and the
> > Linux console come to mind. Also, if someone can test this in a
> > remote-login session, especially over a slow connection, those numbers
> > would be important to have.
>
> Really, I strongly doubt there will be any kind of difference, since
> it's emacs that goes 100% cpu and the terminal does essentially nothing.
>
> I tried via ssh, screen and tmux to check, it's just all the
> same: emacs eating 100% and ssh not even eating 1%.
That's expected with fast connections, yes.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#78474; Package
emacs.
(Thu, 24 Jul 2025 07:45:01 GMT)
Full text and
rfc822 format available.
Message #440 received at 78474 <at> debbugs.gnu.org (full text, mbox):
> Date: Thu, 24 Jul 2025 09:14:46 +0200
> From: Samuel Thibault <samuel.thibault <at> gnu.org>
> Cc: manuel <at> ledu-giraud.fr, rpluim <at> gmail.com, bzg <at> gnu.org,
> Sebastien.Hinderer <at> inria.fr, 78474 <at> debbugs.gnu.org
>
> (gnome-terminal is libvte-based, so it's the same as mate-terminal)
Btw, any reason why libvte works as it does? The fact that there's no
document specifying what \t\b should produce is not a reason good
enough to behave in a deviant way. Are there any downsides to what
xterm does with \t\b that justify the decision of libvte to work
differently? If there are no downsides, why do they insist not to
change their implementation to match the others?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#78474; Package
emacs.
(Thu, 24 Jul 2025 07:50:02 GMT)
Full text and
rfc822 format available.
Message #443 received at 78474 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii, le jeu. 24 juil. 2025 10:38:17 +0300, a ecrit:
> > Date: Thu, 24 Jul 2025 09:14:46 +0200
> > From: Samuel Thibault <samuel.thibault <at> gnu.org>
> > Cc: manuel <at> ledu-giraud.fr, rpluim <at> gmail.com, bzg <at> gnu.org,
> > Sebastien.Hinderer <at> inria.fr, 78474 <at> debbugs.gnu.org
> >
> > Eli Zaretskii, le jeu. 24 juil. 2025 09:40:43 +0300, a ecrit:
> > > > From: Samuel Thibault <samuel.thibault <at> gnu.org>
> > > > The choice of terminal hardly changes anything at all. It's emacs that
> > > > consumes one core 100%, while the terminal consumes 1-3% only.
> > >
> > > I'd encourage others to run similar benchmarks on these and other
> > > terminals. Gnome-terminal, alacritty, kitty, screen, tmux, and the
> > > Linux console come to mind. Also, if someone can test this in a
> > > remote-login session, especially over a slow connection, those numbers
> > > would be important to have.
> >
> > Really, I strongly doubt there will be any kind of difference, since
> > it's emacs that goes 100% cpu and the terminal does essentially nothing.
> >
> > I tried via ssh, screen and tmux to check, it's just all the
> > same: emacs eating 100% and ssh not even eating 1%.
>
> That's expected with fast connections, yes.
It eats just 1Mbps.
I looked at the output, this is the amount difference:
-rw-r--r-- 1 samy samy 2154142 24 juil. 09:48 typescript-csiC
-rw-r--r-- 1 samy samy 2150934 24 juil. 09:46 typescript-tabbs
Samuel
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#78474; Package
emacs.
(Thu, 24 Jul 2025 07:56:01 GMT)
Full text and
rfc822 format available.
Message #446 received at 78474 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii, le jeu. 24 juil. 2025 10:44:21 +0300, a ecrit:
> > Date: Thu, 24 Jul 2025 09:14:46 +0200
> > From: Samuel Thibault <samuel.thibault <at> gnu.org>
> > Cc: manuel <at> ledu-giraud.fr, rpluim <at> gmail.com, bzg <at> gnu.org,
> > Sebastien.Hinderer <at> inria.fr, 78474 <at> debbugs.gnu.org
> >
> > (gnome-terminal is libvte-based, so it's the same as mate-terminal)
>
> Btw, any reason why libvte works as it does?
AIUI that's because people have requested that when printing 'a\ta' ,
copy/paste would reproduce the tab.
> Are there any downsides to what xterm does with \t\b that justify the
> decision of libvte to work differently?
Yes, cat-ing files and copy/pasting them doesn't get "the same output".
Again, the question boils down to whether \t is considered by users as
only a cursor movement thing, or content.
Samuel
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#78474; Package
emacs.
(Thu, 24 Jul 2025 07:57:02 GMT)
Full text and
rfc822 format available.
Message #449 received at 78474 <at> debbugs.gnu.org (full text, mbox):
> Date: Thu, 24 Jul 2025 09:49:27 +0200
> From: Samuel Thibault <samuel.thibault <at> gnu.org>
> Cc: manuel <at> ledu-giraud.fr, rpluim <at> gmail.com, bzg <at> gnu.org,
> Sebastien.Hinderer <at> inria.fr, 78474 <at> debbugs.gnu.org
>
> > > Really, I strongly doubt there will be any kind of difference, since
> > > it's emacs that goes 100% cpu and the terminal does essentially nothing.
> > >
> > > I tried via ssh, screen and tmux to check, it's just all the
> > > same: emacs eating 100% and ssh not even eating 1%.
> >
> > That's expected with fast connections, yes.
>
> It eats just 1Mbps.
>
> I looked at the output, this is the amount difference:
>
> -rw-r--r-- 1 samy samy 2154142 24 juil. 09:48 typescript-csiC
> -rw-r--r-- 1 samy samy 2150934 24 juil. 09:46 typescript-tabbs
Thanks. This is merely a 0.15% difference. With what terminfo entry
was this done?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#78474; Package
emacs.
(Thu, 24 Jul 2025 07:59:02 GMT)
Full text and
rfc822 format available.
Message #452 received at 78474 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii, le jeu. 24 juil. 2025 10:56:29 +0300, a ecrit:
> > Date: Thu, 24 Jul 2025 09:49:27 +0200
> > From: Samuel Thibault <samuel.thibault <at> gnu.org>
> > Cc: manuel <at> ledu-giraud.fr, rpluim <at> gmail.com, bzg <at> gnu.org,
> > Sebastien.Hinderer <at> inria.fr, 78474 <at> debbugs.gnu.org
> >
> > > > Really, I strongly doubt there will be any kind of difference, since
> > > > it's emacs that goes 100% cpu and the terminal does essentially nothing.
> > > >
> > > > I tried via ssh, screen and tmux to check, it's just all the
> > > > same: emacs eating 100% and ssh not even eating 1%.
> > >
> > > That's expected with fast connections, yes.
> >
> > It eats just 1Mbps.
> >
> > I looked at the output, this is the amount difference:
> >
> > -rw-r--r-- 1 samy samy 2154142 24 juil. 09:48 typescript-csiC
> > -rw-r--r-- 1 samy samy 2150934 24 juil. 09:46 typescript-tabbs
>
> Thanks. This is merely a 0.15% difference. With what terminfo entry
> was this done?
It was xterm.
Samuel
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#78474; Package
emacs.
(Thu, 24 Jul 2025 09:29:02 GMT)
Full text and
rfc822 format available.
Message #455 received at 78474 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii <eliz <at> gnu.org> writes:
[...]
> Thanks.
>
> I'd encourage others to run similar benchmarks on these and other
> terminals. Gnome-terminal, alacritty, kitty, screen, tmux, and the
> Linux console come to mind. Also, if someone can test this in a
> remote-login session, especially over a slow connection, those numbers
> would be important to have.
I'd like to give it a try but just to be sure: for reference, I guess we
should use the current master but what should we use as a "no \t\b"
version? My patch, Robert's one, something else?
--
Manuel Giraud
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#78474; Package
emacs.
(Thu, 24 Jul 2025 09:31:02 GMT)
Full text and
rfc822 format available.
Message #458 received at 78474 <at> debbugs.gnu.org (full text, mbox):
Hello,
Manuel Giraud, le jeu. 24 juil. 2025 11:28:04 +0200, a ecrit:
> Eli Zaretskii <eliz <at> gnu.org> writes:
> > I'd encourage others to run similar benchmarks on these and other
> > terminals. Gnome-terminal, alacritty, kitty, screen, tmux, and the
> > Linux console come to mind. Also, if someone can test this in a
> > remote-login session, especially over a slow connection, those numbers
> > would be important to have.
>
> I'd like to give it a try but just to be sure: for reference, I guess we
> should use the current master but what should we use as a "no \t\b"
> version? My patch, Robert's one, something else?
I have been using your patch, since it doesn't prevent emacs from using
tabs without \b.
Samuel
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#78474; Package
emacs.
(Thu, 24 Jul 2025 09:33:01 GMT)
Full text and
rfc822 format available.
Message #461 received at 78474 <at> debbugs.gnu.org (full text, mbox):
> From: Manuel Giraud <manuel <at> ledu-giraud.fr>
> Cc: Samuel Thibault <samuel.thibault <at> gnu.org>, rpluim <at> gmail.com,
> bzg <at> gnu.org, Sebastien.Hinderer <at> inria.fr, 78474 <at> debbugs.gnu.org
> Date: Thu, 24 Jul 2025 11:28:04 +0200
>
> Eli Zaretskii <eliz <at> gnu.org> writes:
>
> [...]
>
> > Thanks.
> >
> > I'd encourage others to run similar benchmarks on these and other
> > terminals. Gnome-terminal, alacritty, kitty, screen, tmux, and the
> > Linux console come to mind. Also, if someone can test this in a
> > remote-login session, especially over a slow connection, those numbers
> > would be important to have.
>
> I'd like to give it a try but just to be sure: for reference, I guess we
> should use the current master but what should we use as a "no \t\b"
> version? My patch, Robert's one, something else?
Please use your patch, and thanks.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#78474; Package
emacs.
(Thu, 24 Jul 2025 10:28:01 GMT)
Full text and
rfc822 format available.
Message #464 received at 78474 <at> debbugs.gnu.org (full text, mbox):
>>>>> On Thu, 24 Jul 2025 09:57:50 +0200, Samuel Thibault <samuel.thibault <at> gnu.org> said:
Samuel> It was xterm.
Eliʼs scrolling test for src/xdisp.c also doesnʼt result in the use of
many \t\b sequences in any case (121 in my testing, for a 39k line
file).
I did the following instead, with a testfile containing 40k lines of
01234567cbaaaaaa
(progn
(find-file "src/testfile")
(let ((oldgc gcs-done)
(oldtime (float-time)))
(goto-char (point-min))
(condition-case nil
(while t (right-char 5) (right-char) (redisplay))
(error (message "GCs: %d Elapsed time: %f seconds"
(- gcs-done oldgc) (- (float-time) oldtime))))))
(this is all over a fast ssh connection, with the underlying terminal
being iterm2)
With Tmux
With tabs:
GCs: 118 Elapsed time: 25.353117 seconds
Without tabs:
GCs: 118 Elapsed time: 25.073720 seconds
Without Tmux
With tabs:
GCs: 116 Elapsed time: 25.145142 seconds
Without tabs:
GCs: 116 Elapsed time: 24.360663 seconds
So it looks like avoiding \t\b is a slight win. Thatʼs surprising to
me, but that is why we measure.
Robert
--
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#78474; Package
emacs.
(Thu, 24 Jul 2025 13:24:01 GMT)
Full text and
rfc822 format available.
Message #467 received at 78474 <at> debbugs.gnu.org (full text, mbox):
> From: Robert Pluim <rpluim <at> gmail.com>
> Cc: Eli Zaretskii <eliz <at> gnu.org>, bzg <at> gnu.org,
> Sebastien.Hinderer <at> inria.fr, manuel <at> ledu-giraud.fr,
> 78474 <at> debbugs.gnu.org
> Date: Thu, 24 Jul 2025 12:27:44 +0200
>
> >>>>> On Thu, 24 Jul 2025 09:57:50 +0200, Samuel Thibault <samuel.thibault <at> gnu.org> said:
>
> Samuel> It was xterm.
>
> Eliʼs scrolling test for src/xdisp.c also doesnʼt result in the use of
> many \t\b sequences in any case (121 in my testing, for a 39k line
> file).
>
> I did the following instead, with a testfile containing 40k lines of
> 01234567cbaaaaaa
>
> (progn
> (find-file "src/testfile")
> (let ((oldgc gcs-done)
> (oldtime (float-time)))
> (goto-char (point-min))
> (condition-case nil
> (while t (right-char 5) (right-char) (redisplay))
> (error (message "GCs: %d Elapsed time: %f seconds"
> (- gcs-done oldgc) (- (float-time) oldtime))))))
>
> (this is all over a fast ssh connection, with the underlying terminal
> being iterm2)
How many times was the \t\b sequence used in this test?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#78474; Package
emacs.
(Thu, 24 Jul 2025 13:47:01 GMT)
Full text and
rfc822 format available.
Message #470 received at 78474 <at> debbugs.gnu.org (full text, mbox):
>>>>> On Thu, 24 Jul 2025 16:22:51 +0300, Eli Zaretskii <eliz <at> gnu.org> said:
>> From: Robert Pluim <rpluim <at> gmail.com>
>> Cc: Eli Zaretskii <eliz <at> gnu.org>, bzg <at> gnu.org,
>> Sebastien.Hinderer <at> inria.fr, manuel <at> ledu-giraud.fr,
>> 78474 <at> debbugs.gnu.org
>> Date: Thu, 24 Jul 2025 12:27:44 +0200
>>
>> >>>>> On Thu, 24 Jul 2025 09:57:50 +0200, Samuel Thibault <samuel.thibault <at> gnu.org> said:
>>
Samuel> It was xterm.
>>
>> Eliʼs scrolling test for src/xdisp.c also doesnʼt result in the use of
>> many \t\b sequences in any case (121 in my testing, for a 39k line
>> file).
>>
>> I did the following instead, with a testfile containing 40k lines of
>> 01234567cbaaaaaa
>>
>> (progn
>> (find-file "src/testfile")
>> (let ((oldgc gcs-done)
>> (oldtime (float-time)))
>> (goto-char (point-min))
>> (condition-case nil
>> (while t (right-char 5) (right-char) (redisplay))
>> (error (message "GCs: %d Elapsed time: %f seconds"
>> (- gcs-done oldgc) (- (float-time) oldtime))))))
>>
>> (this is all over a fast ssh connection, with the underlying terminal
>> being iterm2)
Eli> How many times was the \t\b sequence used in this test?
27151
Robert
--
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#78474; Package
emacs.
(Fri, 25 Jul 2025 07:25:01 GMT)
Full text and
rfc822 format available.
Message #473 received at 78474 <at> debbugs.gnu.org (full text, mbox):
Hi,
So test by running "emacs -Q -nw" into different terminals. Each time,
I've used the following benchmark on "src/xdisp.c":
--8<---------------cut here---------------start------------->8---
(defun scroll-up-benchmark (iteration)
(let ((oldgc gcs-done)
(oldtime (float-time)))
(condition-case nil (while t (scroll-up) (redisplay))
(error (message "%d) GCs: %d Elapsed time: %f seconds"
iteration
(- gcs-done oldgc) (- (float-time) oldtime))))))
(defun do-run-bench ()
(interactive)
(dotimes (i 10)
(goto-char (point-min))
(scroll-up-benchmark i)))
--8<---------------cut here---------------end--------------->8---
Since this benchmark is sensible to the height (and maybe also width) of
the window, I've included those sizes. Here are the results against
master and with my "no \t\b" patch:
--8<---------------cut here---------------start------------->8---
* master (e026b57f077)
** xterm -geometry 80x50
0) GCs: 567 Elapsed time: 31.086774 seconds
1) GCs: 5 Elapsed time: 4.949145 seconds
2) GCs: 4 Elapsed time: 4.838345 seconds
3) GCs: 4 Elapsed time: 4.846398 seconds
4) GCs: 4 Elapsed time: 4.863649 seconds
5) GCs: 4 Elapsed time: 4.847629 seconds
6) GCs: 4 Elapsed time: 4.870357 seconds
7) GCs: 4 Elapsed time: 4.886179 seconds
8) GCs: 4 Elapsed time: 4.845446 seconds
9) GCs: 4 Elapsed time: 4.837510 seconds
** vte --geometry=80x50
0) GCs: 564 Elapsed time: 31.275409 seconds
1) GCs: 5 Elapsed time: 4.507136 seconds
2) GCs: 4 Elapsed time: 4.391385 seconds
3) GCs: 4 Elapsed time: 4.423045 seconds
4) GCs: 4 Elapsed time: 4.414433 seconds
5) GCs: 4 Elapsed time: 4.392768 seconds
6) GCs: 4 Elapsed time: 4.426145 seconds
7) GCs: 4 Elapsed time: 4.366869 seconds
8) GCs: 4 Elapsed time: 4.383935 seconds
9) GCs: 4 Elapsed time: 4.415684 seconds
** alacritty -o "window.dimensions.columns=80" -o "window.dimensions.lines=50"
0) GCs: 564 Elapsed time: 32.297622 seconds
1) GCs: 6 Elapsed time: 4.696004 seconds
2) GCs: 3 Elapsed time: 4.545549 seconds
3) GCs: 4 Elapsed time: 4.557124 seconds
4) GCs: 4 Elapsed time: 4.552929 seconds
5) GCs: 4 Elapsed time: 4.569936 seconds
6) GCs: 4 Elapsed time: 4.569329 seconds
7) GCs: 4 Elapsed time: 4.596861 seconds
8) GCs: 4 Elapsed time: 4.579287 seconds
9) GCs: 4 Elapsed time: 4.583949 seconds
** OpenBSD console (120x33)
0) GCs: 571 Elapsed time: 40.368367 seconds
1) GCs: 7 Elapsed time: 8.152495 seconds
2) GCs: 6 Elapsed time: 7.554665 seconds
3) GCs: 6 Elapsed time: 7.984193 seconds
4) GCs: 6 Elapsed time: 10.279187 seconds
5) GCs: 6 Elapsed time: 10.023705 seconds
6) GCs: 5 Elapsed time: 9.566880 seconds
7) GCs: 6 Elapsed time: 9.344119 seconds
8) GCs: 6 Elapsed time: 7.759981 seconds
9) GCs: 6 Elapsed time: 8.756986 seconds
* no "\t\b" patch
** xterm -geometry 80x50
0) GCs: 566 Elapsed time: 28.977438 seconds
1) GCs: 5 Elapsed time: 4.128581 seconds
2) GCs: 4 Elapsed time: 4.028657 seconds
3) GCs: 4 Elapsed time: 4.034688 seconds
4) GCs: 4 Elapsed time: 4.041386 seconds
5) GCs: 4 Elapsed time: 4.023377 seconds
6) GCs: 4 Elapsed time: 4.031582 seconds
7) GCs: 4 Elapsed time: 4.048343 seconds
8) GCs: 4 Elapsed time: 4.033119 seconds
9) GCs: 4 Elapsed time: 4.035043 seconds
9) GCs: 4 Elapsed time: 4.035043 seconds
** vte --geometry=80x50
0) GCs: 564 Elapsed time: 28.069097 seconds
1) GCs: 5 Elapsed time: 3.822866 seconds
2) GCs: 4 Elapsed time: 3.711420 seconds
3) GCs: 4 Elapsed time: 3.725387 seconds
4) GCs: 4 Elapsed time: 3.750833 seconds
5) GCs: 4 Elapsed time: 3.719932 seconds
6) GCs: 4 Elapsed time: 3.718813 seconds
7) GCs: 4 Elapsed time: 3.706245 seconds
8) GCs: 4 Elapsed time: 3.722128 seconds
9) GCs: 4 Elapsed time: 3.734348 seconds
** alacritty -o "window.dimensions.columns=80" -o "window.dimensions.lines=50"
0) GCs: 564 Elapsed time: 28.864394 seconds
1) GCs: 5 Elapsed time: 3.953090 seconds
2) GCs: 4 Elapsed time: 3.857996 seconds
3) GCs: 4 Elapsed time: 3.862114 seconds
4) GCs: 4 Elapsed time: 4.039003 seconds
5) GCs: 4 Elapsed time: 3.855950 seconds
6) GCs: 4 Elapsed time: 3.849463 seconds
7) GCs: 4 Elapsed time: 3.856677 seconds
8) GCs: 4 Elapsed time: 3.871728 seconds
9) GCs: 4 Elapsed time: 3.868826 seconds
** OpenBSD console (120x34)
0) GCs: 571 Elapsed time: 32.808671 seconds
1) GCs: 7 Elapsed time: 10.445288 seconds
2) GCs: 6 Elapsed time: 9.432234 seconds
3) GCs: 6 Elapsed time: 8.429330 seconds
4) GCs: 6 Elapsed time: 8.490854 seconds
5) GCs: 5 Elapsed time: 8.528081 seconds
6) GCs: 6 Elapsed time: 9.435279 seconds
7) GCs: 6 Elapsed time: 8.696780 seconds
8) GCs: 6 Elapsed time: 8.993753 seconds
9) GCs: 5 Elapsed time: 7.756981 seconds
--8<---------------cut here---------------end--------------->8---
--
Manuel Giraud
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#78474; Package
emacs.
(Fri, 25 Jul 2025 09:03:02 GMT)
Full text and
rfc822 format available.
Message #476 received at 78474 <at> debbugs.gnu.org (full text, mbox):
Robert Pluim <rpluim <at> gmail.com> writes:
>>>>>> On Thu, 24 Jul 2025 09:57:50 +0200, Samuel Thibault <samuel.thibault <at> gnu.org> said:
>
> Samuel> It was xterm.
>
> Eliʼs scrolling test for src/xdisp.c also doesnʼt result in the use of
> many \t\b sequences in any case (121 in my testing, for a 39k line
> file).
>
> I did the following instead, with a testfile containing 40k lines of
> 01234567cbaaaaaa
>
> (progn
> (find-file "src/testfile")
> (let ((oldgc gcs-done)
> (oldtime (float-time)))
> (goto-char (point-min))
> (condition-case nil
> (while t (right-char 5) (right-char) (redisplay))
> (error (message "GCs: %d Elapsed time: %f seconds"
> (- gcs-done oldgc) (- (float-time)
> oldtime))))))
Here are my results with this new benchmark:
--8<---------------cut here---------------start------------->8---
* master (e026b57f077)
** xterm -geometry 80x50
GCs: 117 Elapsed time: 63.118144 seconds
** vte --geometry=80x50
GCs: 117 Elapsed time: 53.912884 seconds
** alacritty -o "window.dimensions.columns=80" -o "window.dimensions.lines=50"
GCs: 117 Elapsed time: 60.685075 seconds
** OpenBSD console (120x33)
GCs: 116 Elapsed time: 63.612051 seconds
* no "\t\b" patch
** xterm -geometry 80x50
GCs: 116 Elapsed time: 63.245375 seconds
** vte --geometry=80x50
GCs: 116 Elapsed time: 54.085663 seconds
** alacritty -o "window.dimensions.columns=80" -o "window.dimensions.lines=50"
GCs: 117 Elapsed time: 59.986522 seconds
** OpenBSD console (120x33)
GCs: 116 Elapsed time: 64.168769 seconds
--8<---------------cut here---------------end--------------->8---
--
Manuel Giraud
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#78474; Package
emacs.
(Fri, 25 Jul 2025 09:13:01 GMT)
Full text and
rfc822 format available.
Message #479 received at 78474 <at> debbugs.gnu.org (full text, mbox):
Manuel Giraud, le ven. 25 juil. 2025 11:02:33 +0200, a ecrit:
> Robert Pluim <rpluim <at> gmail.com> writes:
>
> >>>>>> On Thu, 24 Jul 2025 09:57:50 +0200, Samuel Thibault <samuel.thibault <at> gnu.org> said:
> >
> > Samuel> It was xterm.
> >
> > Eliʼs scrolling test for src/xdisp.c also doesnʼt result in the use of
> > many \t\b sequences in any case (121 in my testing, for a 39k line
> > file).
> >
> > I did the following instead, with a testfile containing 40k lines of
> > 01234567cbaaaaaa
> >
> > (progn
> > (find-file "src/testfile")
> > (let ((oldgc gcs-done)
> > (oldtime (float-time)))
> > (goto-char (point-min))
> > (condition-case nil
> > (while t (right-char 5) (right-char) (redisplay))
> > (error (message "GCs: %d Elapsed time: %f seconds"
> > (- gcs-done oldgc) (- (float-time)
> > oldtime))))))
>
> Here are my results with this new benchmark:
(Several measurements are really needed because of variability)
Samuel
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#78474; Package
emacs.
(Fri, 25 Jul 2025 11:09:02 GMT)
Full text and
rfc822 format available.
Message #482 received at 78474 <at> debbugs.gnu.org (full text, mbox):
Samuel Thibault <samuel.thibault <at> gnu.org> writes:
[...]
>> Here are my results with this new benchmark:
>
> (Several measurements are really needed because of variability)
Why not. So, here is the benchmark code I used:
--8<---------------cut here---------------start------------->8---
(defun move-right-in-big-file (iteration)
(let ((oldgc gcs-done)
(oldtime (float-time)))
(goto-char (point-min))
(condition-case nil
(while t (right-char 5) (right-char) (redisplay))
(error (message "%d) GCs: %d Elapsed time: %f seconds"
iteration
(- gcs-done oldgc) (- (float-time) oldtime)))))
(defun do-run-bench ()
(interactive)
(find-file "/tmp/testfile")
(with-current-buffer "testfile"
(dotimes (i 5)
(move-right-in-big-file i))))
--8<---------------cut here---------------end--------------->8---
The file "/tmp/testfile" is 40k lines of 01234567cbaaaaaa (one on each
line). Here are the new results:
--8<---------------cut here---------------start------------->8---
* master (e026b57f077)
** xterm -geometry 80x50
0) GCs: 116 Elapsed time: 63.792068 seconds
1) GCs: 116 Elapsed time: 71.622749 seconds
2) GCs: 115 Elapsed time: 71.081707 seconds
3) GCs: 115 Elapsed time: 71.586609 seconds
4) GCs: 116 Elapsed time: 71.637533 seconds
** vte --geometry=80x50
0) GCs: 116 Elapsed time: 59.622406 seconds
1) GCs: 115 Elapsed time: 64.886754 seconds
2) GCs: 116 Elapsed time: 64.992959 seconds
3) GCs: 115 Elapsed time: 68.607110 seconds
4) GCs: 115 Elapsed time: 68.618530 seconds
** alacritty -o "window.dimensions.columns=80" -o "window.dimensions.lines=50"
0) GCs: 117 Elapsed time: 62.261371 seconds
1) GCs: 115 Elapsed time: 78.729518 seconds
2) GCs: 115 Elapsed time: 71.705638 seconds
3) GCs: 115 Elapsed time: 72.297152 seconds
4) GCs: 116 Elapsed time: 70.714234 seconds
** OpenBSD console (120x33)
0) GCs: 117 Elapsed time: 52.839892 seconds
1) GCs: 115 Elapsed time: 75.330218 seconds
2) GCs: 115 Elapsed time: 70.088152 seconds
3) GCs: 116 Elapsed time: 72.875108 seconds
4) GCs: 115 Elapsed time: 77.073560 seconds
* no "\t\b" patch
** xterm -geometry 80x50
0) GCs: 117 Elapsed time: 63.044708 seconds
1) GCs: 115 Elapsed time: 71.653735 seconds
2) GCs: 115 Elapsed time: 71.419002 seconds
3) GCs: 116 Elapsed time: 71.365777 seconds
4) GCs: 115 Elapsed time: 71.368108 seconds
** vte --geometry=80x50
0) GCs: 115 Elapsed time: 54.472031 seconds
1) GCs: 116 Elapsed time: 61.845512 seconds
2) GCs: 115 Elapsed time: 61.784741 seconds
3) GCs: 115 Elapsed time: 61.765834 seconds
4) GCs: 115 Elapsed time: 61.864283 seconds
** alacritty -o "window.dimensions.columns=80" -o "window.dimensions.lines=50"
0) GCs: 116 Elapsed time: 60.468120 seconds
1) GCs: 115 Elapsed time: 68.995329 seconds
2) GCs: 115 Elapsed time: 69.065036 seconds
3) GCs: 116 Elapsed time: 69.261622 seconds
4) GCs: 115 Elapsed time: 68.021610 seconds
** OpenBSD console (120x33)
0) GCs: 117 Elapsed time: 57.670531 seconds
1) GCs: 115 Elapsed time: 58.239377 seconds
2) GCs: 116 Elapsed time: 60.935976 seconds
3) GCs: 115 Elapsed time: 67.796118 seconds
4) GCs: 115 Elapsed time: 74.120420 seconds
--8<---------------cut here---------------end--------------->8---
--
Manuel Giraud
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#78474; Package
emacs.
(Tue, 29 Jul 2025 07:52:02 GMT)
Full text and
rfc822 format available.
Message #485 received at 78474 <at> debbugs.gnu.org (full text, mbox):
>>>>> On Fri, 25 Jul 2025 13:08:07 +0200, Manuel Giraud <manuel <at> ledu-giraud.fr> said:
Manuel> Samuel Thibault <samuel.thibault <at> gnu.org> writes:
Manuel> [...]
>>> Here are my results with this new benchmark:
>>
>> (Several measurements are really needed because of variability)
Manuel> Why not. So, here is the benchmark code I used:
So it looks to me like not emitting \t\b is slightly faster. Could you
repost your patch with a user option to enable/disable it? Then we can
discuss what the default should be. Iʼm leaning towards the default
being not emitting it, since the resulting redisplay will be correct
in any case.
Robert
--
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#78474; Package
emacs.
(Sat, 02 Aug 2025 13:18:02 GMT)
Full text and
rfc822 format available.
Message #488 received at 78474 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Robert Pluim <rpluim <at> gmail.com> writes:
>>>>>> On Fri, 25 Jul 2025 13:08:07 +0200, Manuel Giraud <manuel <at> ledu-giraud.fr> said:
>
> Manuel> Samuel Thibault <samuel.thibault <at> gnu.org> writes:
> Manuel> [...]
>
> >>> Here are my results with this new benchmark:
> >>
> >> (Several measurements are really needed because of variability)
>
> Manuel> Why not. So, here is the benchmark code I used:
>
> So it looks to me like not emitting \t\b is slightly faster. Could you
> repost your patch with a user option to enable/disable it? Then we can
> discuss what the default should be. Iʼm leaning towards the default
> being not emitting it, since the resulting redisplay will be correct
> in any case.
Hi Robert and all,
Here it is. I'm not quite sure about the user option name, its
documentation and NEWS entry. Samuel could you test if this new default
works for screen readers and also if setting
`inhibit-overshoot-in-tty-motions' to nil make them unwork.
FWIW, here are the results for Robert's benchmark (xterm only) with this
patch:
* inhibit-overshoot-in-tty-motions is t (default)
** xterm -geometry 80x50
0) GCs: 116 Elapsed time: 62.708855 seconds
1) GCs: 116 Elapsed time: 70.723578 seconds
2) GCs: 115 Elapsed time: 70.099679 seconds
3) GCs: 115 Elapsed time: 70.479095 seconds
4) GCs: 115 Elapsed time: 70.143764 seconds
* (setopt inhibit-overshoot-in-tty-motions nil)
** xterm -geometry 80x50
0) GCs: 117 Elapsed time: 62.697354 seconds
1) GCs: 115 Elapsed time: 71.844141 seconds
2) GCs: 116 Elapsed time: 71.422948 seconds
3) GCs: 115 Elapsed time: 71.161357 seconds
4) GCs: 115 Elapsed time: 70.877772 seconds
[0001-User-option-to-control-overshoot-and-backup-for-tty-.patch (text/x-patch, attachment)]
[Message part 3 (text/plain, inline)]
--
Manuel Giraud
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#78474; Package
emacs.
(Sat, 02 Aug 2025 14:51:01 GMT)
Full text and
rfc822 format available.
Message #491 received at 78474 <at> debbugs.gnu.org (full text, mbox):
> From: Manuel Giraud <manuel <at> ledu-giraud.fr>
> Cc: Samuel Thibault <samuel.thibault <at> gnu.org>, Eli Zaretskii
> <eliz <at> gnu.org>, bzg <at> gnu.org, Sebastien.Hinderer <at> inria.fr,
> 78474 <at> debbugs.gnu.org
> Date: Sat, 02 Aug 2025 15:17:35 +0200
>
> Robert Pluim <rpluim <at> gmail.com> writes:
>
> >>>>>> On Fri, 25 Jul 2025 13:08:07 +0200, Manuel Giraud <manuel <at> ledu-giraud.fr> said:
> >
> > Manuel> Samuel Thibault <samuel.thibault <at> gnu.org> writes:
> > Manuel> [...]
> >
> > >>> Here are my results with this new benchmark:
> > >>
> > >> (Several measurements are really needed because of variability)
> >
> > Manuel> Why not. So, here is the benchmark code I used:
> >
> > So it looks to me like not emitting \t\b is slightly faster. Could you
> > repost your patch with a user option to enable/disable it? Then we can
> > discuss what the default should be. Iʼm leaning towards the default
> > being not emitting it, since the resulting redisplay will be correct
> > in any case.
>
> Hi Robert and all,
>
> Here it is. I'm not quite sure about the user option name, its
> documentation and NEWS entry. Samuel could you test if this new default
> works for screen readers and also if setting
> `inhibit-overshoot-in-tty-motions' to nil make them unwork.
Thanks, a few minor comments below.
> +---
> +** New user option 'inhibit-overshoot-in-tty-motions'.
I see no reason to make this a user option. It should be a simple
variable. Also, I'd call it tty-cursor-movement-use-TAB-BS and set it
to nil by default.
> +The display optimization where the combination TAB characters +
> +BACKSPACE to move to a position on a TTY frame is now disabled by
> +default and controlled by this user option. This option can be set
> +customized to nil to keep the old behavior. This is to accomodate to
> +some software such as screen readers.
This is a somewhat incompatible change. So this NEWS text should be
in the "Incompatible changes" section.
I also think lisp/term/rxvt.el should force this variable to avoid
TAB+BS, since rxvt is known to produce buggy behavior with that
combination.
Otherwise, this should be good to go.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#78474; Package
emacs.
(Sat, 02 Aug 2025 17:38:01 GMT)
Full text and
rfc822 format available.
Message #494 received at 78474 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii <eliz <at> gnu.org> writes:
[...]
> Thanks, a few minor comments below.
>
>> +---
>> +** New user option 'inhibit-overshoot-in-tty-motions'.
>
> I see no reason to make this a user option. It should be a simple
> variable. Also, I'd call it tty-cursor-movement-use-TAB-BS and set it
> to nil by default.
Ok.
>> +The display optimization where the combination TAB characters +
>> +BACKSPACE to move to a position on a TTY frame is now disabled by
>> +default and controlled by this user option. This option can be set
>> +customized to nil to keep the old behavior. This is to accomodate to
>> +some software such as screen readers.
>
> This is a somewhat incompatible change. So this NEWS text should be
> in the "Incompatible changes" section.
Ok.
> I also think lisp/term/rxvt.el should force this variable to avoid
> TAB+BS, since rxvt is known to produce buggy behavior with that
> combination.
If tty-cursor-movement-use-TAB-BS is nil by default I think we're good,
no?
> Otherwise, this should be good to go.
Thanks. I'd like to see some tests from Samuel.
--
Manuel Giraud
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#78474; Package
emacs.
(Sat, 02 Aug 2025 19:23:02 GMT)
Full text and
rfc822 format available.
Message #497 received at 78474 <at> debbugs.gnu.org (full text, mbox):
> From: Manuel Giraud <manuel <at> ledu-giraud.fr>
> Cc: rpluim <at> gmail.com, samuel.thibault <at> gnu.org, bzg <at> gnu.org,
> Sebastien.Hinderer <at> inria.fr, 78474 <at> debbugs.gnu.org
> Date: Sat, 02 Aug 2025 19:37:42 +0200
>
> Eli Zaretskii <eliz <at> gnu.org> writes:
>
> > I also think lisp/term/rxvt.el should force this variable to avoid
> > TAB+BS, since rxvt is known to produce buggy behavior with that
> > combination.
>
> If tty-cursor-movement-use-TAB-BS is nil by default I think we're good,
> no?
My point is that IMO rxvt should force it to nil even if the user
customized the value to non-nil (e.g., in their init file).
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#78474; Package
emacs.
(Sun, 03 Aug 2025 09:18:01 GMT)
Full text and
rfc822 format available.
Message #500 received at 78474 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii <eliz <at> gnu.org> writes:
>> From: Manuel Giraud <manuel <at> ledu-giraud.fr>
>> Cc: rpluim <at> gmail.com, samuel.thibault <at> gnu.org, bzg <at> gnu.org,
>> Sebastien.Hinderer <at> inria.fr, 78474 <at> debbugs.gnu.org
>> Date: Sat, 02 Aug 2025 19:37:42 +0200
>>
>> Eli Zaretskii <eliz <at> gnu.org> writes:
>>
>> > I also think lisp/term/rxvt.el should force this variable to avoid
>> > TAB+BS, since rxvt is known to produce buggy behavior with that
>> > combination.
>>
>> If tty-cursor-movement-use-TAB-BS is nil by default I think we're good,
>> no?
>
> My point is that IMO rxvt should force it to nil even if the user
> customized the value to non-nil (e.g., in their init file).
Ok. Now I see that I also did not understand this part of your previous
reply:
> I see no reason to make this a user option. It should be a simple
> variable.
I have used the DEFVAR_BOOL macro but no defcustom: does that make it a
"simple variable"? Sorry for my lack of understanding of Emacs
internals here.
--
Manuel Giraud
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#78474; Package
emacs.
(Sun, 03 Aug 2025 09:41:02 GMT)
Full text and
rfc822 format available.
Message #503 received at 78474 <at> debbugs.gnu.org (full text, mbox):
> From: Manuel Giraud <manuel <at> ledu-giraud.fr>
> Cc: rpluim <at> gmail.com, samuel.thibault <at> gnu.org, bzg <at> gnu.org,
> Sebastien.Hinderer <at> inria.fr, 78474 <at> debbugs.gnu.org
> Date: Sun, 03 Aug 2025 11:17:18 +0200
>
> > I see no reason to make this a user option. It should be a simple
> > variable.
>
> I have used the DEFVAR_BOOL macro but no defcustom: does that make it a
> "simple variable"?
Yes. To make such a variable a defcustom, you need to add it to
cus-start.el.
> Sorry for my lack of understanding of Emacs internals here.
No need to feel sorry, no one is borne with this knowledge.
Thanks.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#78474; Package
emacs.
(Sun, 03 Aug 2025 12:04:01 GMT)
Full text and
rfc822 format available.
Message #506 received at 78474 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Eli Zaretskii <eliz <at> gnu.org> writes:
>> From: Manuel Giraud <manuel <at> ledu-giraud.fr>
>> Cc: rpluim <at> gmail.com, samuel.thibault <at> gnu.org, bzg <at> gnu.org,
>> Sebastien.Hinderer <at> inria.fr, 78474 <at> debbugs.gnu.org
>> Date: Sun, 03 Aug 2025 11:17:18 +0200
>>
>> > I see no reason to make this a user option. It should be a simple
>> > variable.
>>
>> I have used the DEFVAR_BOOL macro but no defcustom: does that make it a
>> "simple variable"?
>
> Yes. To make such a variable a defcustom, you need to add it to
> cus-start.el.
>
>> Sorry for my lack of understanding of Emacs internals here.
>
> No need to feel sorry, no one is borne with this knowledge.
Thanks. Here is the new version of the patch that, I think, addresses
all the left issues.
[0001-Variable-to-control-overshoot-and-backup-for-tty-mot.patch (text/x-patch, attachment)]
[Message part 3 (text/plain, inline)]
--
Manuel Giraud
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#78474; Package
emacs.
(Sun, 03 Aug 2025 20:02:02 GMT)
Full text and
rfc822 format available.
Message #509 received at 78474 <at> debbugs.gnu.org (full text, mbox):
Hello,
Manuel Giraud, le dim. 03 août 2025 14:03:51 +0200, a ecrit:
> Eli Zaretskii <eliz <at> gnu.org> writes:
>
> >> From: Manuel Giraud <manuel <at> ledu-giraud.fr>
> >> Cc: rpluim <at> gmail.com, samuel.thibault <at> gnu.org, bzg <at> gnu.org,
> >> Sebastien.Hinderer <at> inria.fr, 78474 <at> debbugs.gnu.org
> >> Date: Sun, 03 Aug 2025 11:17:18 +0200
> >>
> >> > I see no reason to make this a user option. It should be a simple
> >> > variable.
> >>
> >> I have used the DEFVAR_BOOL macro but no defcustom: does that make it a
> >> "simple variable"?
> >
> > Yes. To make such a variable a defcustom, you need to add it to
> > cus-start.el.
> >
> >> Sorry for my lack of understanding of Emacs internals here.
> >
> > No need to feel sorry, no one is borne with this knowledge.
>
> Thanks. Here is the new version of the patch that, I think, addresses
> all the left issues.
Thanks. I confirm that the patch fixes the behavior, and that adding
(setq tty-cursor-movement-use-TAB-BS 1)
to my .emacs re-breaks the behavior.
Samuel
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#78474; Package
emacs.
(Mon, 04 Aug 2025 11:11:01 GMT)
Full text and
rfc822 format available.
Message #512 received at 78474 <at> debbugs.gnu.org (full text, mbox):
Samuel Thibault <samuel.thibault <at> gnu.org> writes:
> Hello,
>
> Manuel Giraud, le dim. 03 août 2025 14:03:51 +0200, a ecrit:
>> Eli Zaretskii <eliz <at> gnu.org> writes:
>>
>> >> From: Manuel Giraud <manuel <at> ledu-giraud.fr>
>> >> Cc: rpluim <at> gmail.com, samuel.thibault <at> gnu.org, bzg <at> gnu.org,
>> >> Sebastien.Hinderer <at> inria.fr, 78474 <at> debbugs.gnu.org
>> >> Date: Sun, 03 Aug 2025 11:17:18 +0200
>> >>
>> >> > I see no reason to make this a user option. It should be a simple
>> >> > variable.
>> >>
>> >> I have used the DEFVAR_BOOL macro but no defcustom: does that make it a
>> >> "simple variable"?
>> >
>> > Yes. To make such a variable a defcustom, you need to add it to
>> > cus-start.el.
>> >
>> >> Sorry for my lack of understanding of Emacs internals here.
>> >
>> > No need to feel sorry, no one is borne with this knowledge.
>>
>> Thanks. Here is the new version of the patch that, I think, addresses
>> all the left issues.
>
> Thanks. I confirm that the patch fixes the behavior, and that adding
>
> (setq tty-cursor-movement-use-TAB-BS 1)
>
> to my .emacs re-breaks the behavior.
Thanks for testing. Maybe if everything is ok, this could go in then.
--
Manuel Giraud
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#78474; Package
emacs.
(Mon, 04 Aug 2025 12:19:02 GMT)
Full text and
rfc822 format available.
Message #515 received at 78474 <at> debbugs.gnu.org (full text, mbox):
Thanks for the fix! And everyone's patience.
--
Bastien
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#78474; Package
emacs.
(Mon, 04 Aug 2025 13:08:01 GMT)
Full text and
rfc822 format available.
Message #518 received at 78474 <at> debbugs.gnu.org (full text, mbox):
Bastien Guerry (2025/08/04 14:18 +0200):
> Thanks for the fix! And everyone's patience.
I am grateful to everybody for all the efforts, too.
A bunch of thanks to each of you.
Reply sent
to
Eli Zaretskii <eliz <at> gnu.org>:
You have taken responsibility.
(Sat, 09 Aug 2025 12:31:01 GMT)
Full text and
rfc822 format available.
Notification sent
to
Bastien Guerry <bzg <at> gnu.org>:
bug acknowledged by developer.
(Sat, 09 Aug 2025 12:31:02 GMT)
Full text and
rfc822 format available.
Message #523 received at 78474-done <at> debbugs.gnu.org (full text, mbox):
> From: Manuel Giraud <manuel <at> ledu-giraud.fr>
> Cc: rpluim <at> gmail.com, samuel.thibault <at> gnu.org, bzg <at> gnu.org,
> Sebastien.Hinderer <at> inria.fr, 78474 <at> debbugs.gnu.org
> Date: Sun, 03 Aug 2025 14:03:51 +0200
>
> Eli Zaretskii <eliz <at> gnu.org> writes:
>
> >> From: Manuel Giraud <manuel <at> ledu-giraud.fr>
> >> Cc: rpluim <at> gmail.com, samuel.thibault <at> gnu.org, bzg <at> gnu.org,
> >> Sebastien.Hinderer <at> inria.fr, 78474 <at> debbugs.gnu.org
> >> Date: Sun, 03 Aug 2025 11:17:18 +0200
> >>
> >> > I see no reason to make this a user option. It should be a simple
> >> > variable.
> >>
> >> I have used the DEFVAR_BOOL macro but no defcustom: does that make it a
> >> "simple variable"?
> >
> > Yes. To make such a variable a defcustom, you need to add it to
> > cus-start.el.
> >
> >> Sorry for my lack of understanding of Emacs internals here.
> >
> > No need to feel sorry, no one is borne with this knowledge.
>
> Thanks. Here is the new version of the patch that, I think, addresses
> all the left issues.
Thanks, now installed on the master branch, and closing the bug.
This bug report was last modified today.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.