GNU bug report logs - #77722
[PATCH] Test and fix term-buffer-vertical-motion

Previous Next

To reply to this bug, email your comments to 77722 AT debbugs.gnu.org.

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

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

From: Stephane Zermatten <szermatt <at> gmail.com>
To: bug-gnu-emacs <at> gnu.org
Subject: [PATCH] Test and fix term-buffer-vertical-motion
Date: Thu, 10 Apr 2025 20:39:26 +0300

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

Tags: patch


In my code, I'm using hidden terminal buffers created by term.el, then
periodically copy their content to another buffer. The term-mode buffer
is not normally shown on any window. https://github.com/szermatt/mistty

This doesn't work very well with the default
term-buffer-vertical-motion implementation. I get very strange
behavior from term in such a case that disappear if the term buffer is
shown on any window.

To reproduce one issue:

 - Open term.el, go to term-emulate-terminal and replace:
             (setf term-vertical-motion
               (if (eq (window-buffer) (current-buffer))
                   'vertical-motion
                 'term-buffer-vertical-motion))
   with:
              (setf term-vertical-motion 'term-buffer-vertical-motion)

   (It is cheating a bit but much easier than trying to control a term
   buffer that's not tied to a window.)

 - Start zsh with M-x term (because it supports right prompts)

 - Type RPS1='< right'

 - Now type any command, such as "echo ok" and press enter. The
   command disappear with no output. The output never leaves the
   current line.

 - Type RPS1='' to go back to normal

That's with term-suppress-hard-newline left to nil, the default value.

The problem, I've found, is that term-buffer-vertical-motion has
issues with some corner cases, one of which is line whose width
correspond exactly to the line width.

It's especially annoying given that vertical-motion with
term-suppress-hard-newline nil could very well just be replaced by
forward-line, and I'm doing just that as a workaround:

(cl-letf (((symbol-function 'term-buffer-vertical-motion)
          (lambda (count)
            (let ((start-point (point))
                  (res (forward-line count)))
              (setq res (- count res))
              (when (and (> count 0)
                         (= (point) (point-max))
                         (> (point) start-point)
                         (not (eq ?\n (char-before (point-max)))))
                (cl-decf res))
              res))))

In this patch, however, to be nicer in the case where
term-suppress-hard-newline is non-nil, I propose to test
term-buffer-vertical-motion and fix the issues.
term-buffer-vertical-motion should always behave like
vertical-motion (assuming no display shenanigans or characters with
different width), so I used that for comparison.

In GNU Emacs 30.1 (build 2, x86_64-apple-darwin23.6.0, NS appkit-2487.70
 Version 14.7.4 (Build 23H420)) of 2025-03-24 built on boomer.zia
Windowing system distributor 'Apple', version 10.3.2487
System Description:  macOS 14.7.4

Configured using:
 'configure --disable-dependency-tracking --disable-silent-rules
 --enable-locallisppath=/usr/local/share/emacs/site-lisp
 --infodir=/usr/local/Cellar/emacs-plus <at> 30/30.1/share/info/emacs
 --prefix=/usr/local/Cellar/emacs-plus <at> 30/30.1
 --with-native-compilation=aot --with-xml2 --with-gnutls
 --without-compress-install --without-dbus --without-imagemagick
 --with-modules --with-rsvg --with-webp --with-ns
 --disable-ns-self-contained 'CFLAGS=-O2 -DFD_SETSIZE=10000
 -DDARWIN_UNLIMITED_SELECT -I/usr/local/opt/sqlite/include
 -I/usr/local/opt/gcc/include -I/usr/local/opt/libgccjit/include'
 'LDFLAGS=-L/usr/local/opt/sqlite/lib -L/usr/local/lib/gcc/14
 -I/usr/local/opt/gcc/include -I/usr/local/opt/libgccjit/include''

[0001-Test-and-fix-term-buffer-vertical-motion.patch (text/patch, attachment)]

Previous Next

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