GNU bug report logs - #77872
[PATCH 1/2] ansi-term: ignore CSI commands with subparams

Previous Next

Full log

View this message in rfc822 format

From: Jared Finder <jared <at> finder.org>
To: Johannes Altmanninger <aclopte <at> gmail.com>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 77872 <at> debbugs.gnu.org
Subject: bug#77872: [PATCH 1/2] ansi-term: ignore CSI commands with subparams
Date: Sun, 20 Apr 2025 08:25:01 -0700

On 2025-04-20 01:03, Johannes Altmanninger wrote:
> On Fri, Apr 18, 2025 at 10:33:36PM -0700, Jared Finder wrote:
>> On 2025-04-18 02:00, Johannes Altmanninger wrote:
>> > If it's not acceptable to ignore curly underline sequences, I can
>> > probably also implement them in term.el (i.e. actually recognize
>> > \e[4:3m).
>> 
>> I think this is a much preferred option. Emacs 30 in a terminal 
>> already
>> supports displaying wavy underlines. Adding support for wavy 
>> underlines to
>> ansi-term looks like it wouldn't be harder than the proposed patch.
> 
> It would be a step in the right direction, yeah
> (though unrelated to my troubles with terminfo)
> 
> Given that we don't want to break this specific implicitly-supported 
> command,
> we should probably do the same for others, if any.
> So the question is, is there any other command of the form
> "CSI Ps : Ps X" where ansi-term's current interpretation as "CSI Ps X" 
> is
> reasonable.
> 
> We'd need to do a bit of research, based on the commands that ansi-term
> supports today.
> 
> Not sure when I can get to that (either way, I'll likely not be able
> to enable curly underlines by default; there are various issues left
> with other terminals).

Sounds appropriate to me, though I think just adding support to term.el 
for wavy underlines would be a step in the right direction and useful on 
its own. No need to wait for perfection here.

>> > In future, to get out of this mess, we should consider not asking
>> > for Smulx/Su and simply emit the styled sequences unconditionally.
>> > Unless Emacs still needs to run on hardware terminals that misinterpret
>> > those, that would be the sanest option going forward.  It will
>> > essentially force all terminal emulators to be compatible with this,
>> > which is fine I think?  From the terminals I have tested, emitting
>> > \e[4:3m would only cause regressions on these terminals: abduco, dvtm,
>> > JetBrains IDE terminals and urxvt.  It should be easy to fix them or
>> > add workarounds; in a few years it should no longer be an issue.
>> 
>> If I'm understanding this right, you're suggesting to have Emacs 
>> always emit
>> the wavy underline escape sequence for :underline (:style wave), even 
>> on
>> terminals it believes does not support wavy underlines.
>> This seems like a significant behavior change.
> 
> Yes, deferring to the underlying terminal here would be a noticeable
> change. I'd argue it would be simpler overall to have the middle-man
> be less opinionated but of course that's subjective. It's not super
> obvious how nested terminals should behave. I personally tend to
> avoid them nowadays though they are very useful sometimes.

From my perspective, it goes against the usual Emacs pattern where 
unsupported face specs are ignored.  However, I do think it makes sense 
for term.el to properly report what it does or doesn't support, hence my 
comment about checking what Emacs believes the underlying terminal 
supports with display-supports-face-attributes-p.

>> While libraries packaged within Emacs look to
>> be good about using a face supports spec when defining their faces, 
>> the same
>> can't be said for external Emacs libraries.
> 
> Right. The fallback behavior is helpful to some users/libraries and
> the opposite to others.
> 
> I realized today even if I queried those nestable terminals (like tmux 
> and ansi-term),
> and they always returned the correct answer as to whether Smulx/Su is 
> supported,
> it wouldn't really help me because they this doesn't tell me anything
> about the parent terminal.
> I guess I can work around it for tmux (which does tell me the parent
> terminal's name and pty) but it sounds pretty difficult to standardize
> an interface for this.
> 
>> I also don't understand how this makes things better. Are there 
>> terminals
>> that you encounter that Emacs does not accurately report
>> (display-supports-face-attributes-p '(:underline (:style wave))) for? 
>> Local
>> testing on a Mac with iTerm2, kitty, Alacritty, Apple Terminal.app, 
>> Rio, and
>> WezTerm correctly reported t vs nil.
> 
> Couple problems.
> 
> 1.
> 
> I took a naïve approach and installed Emacs 29.4 as well as these
> terminals via Homebrew on a (mostly vanilla) macOS. I've been running
> "emacs -nw" with no config, evaluating that expression gave nil for
> all of them.

Emacs 30 appears to have changed how styling underlines is detected. 
(https://git.savannah.gnu.org/cgit/emacs.git/tree/etc/NEWS?h=emacs-30#n244) 
 Can you run the same test on Emacs 30.1 or later?  Emacs 30.1 is 
available via Homebrew as well, https://formulae.brew.sh/cask/emacs.  I 
tested with Emacs installed via brew install --cask.

> This result is consistent with
> 
> 	{ infocmp -x $TERM; infocmp -x $TERM_PROGRAM } | grep -E 
> '\b(Su|Smulx)\b'
> 
> which gave no results on this.
> 
> I guess it's my bad to use macOS's system libraries that are probably 
> not updated often.
> 
> After `brew install ncurses` version 6.5, my $(find /opt/homebrew -name 
> infocmp) did manage
> to find a terminfo entry for say kitty, but not others like iTerm.app.
> Presumably "TERMINFO=/opt/homebrew/opt/ncurses/share/terminfo emacs 
> -nw" would work too.
> 
> On my Linux system only kitty, alacritty and rio have it.
> 
> 	$ for term in iterm2 kitty xterm-kitty alacritty Apple_Terminal rio 
> wezterm; do
> 	    echo $term
> 	    infocmp -x $term | grep -E '\b(Su|Smulx)\b'
> 	done
> 	iterm2
> 	kitty
> 		Smulx=\E[4:%p1%dm, Ss=\E[%p1%d q, TS=\E]2;,
> 	xterm-kitty
> 		am, ccc, hs, km, mc5i, mir, msgr, npc, xenl, Su, Tc, XF, fullkbd,
> 		Smulx=\E[4:%p1%dm, Ss=\E[%p1%d q, Sync=\EP=%p1%ds\E\\,
> 	alacritty
> 		PE=\E[201~, PS=\E[200~, Se=\E[0 q, Smulx=\E[4:%p1%dm,
> 	Apple_Terminal
> 	rio
> 		PE=\E[201~, PS=\E[200~, Se=\E[0 q, Smulx=\E[4:%p1%dm,
> 	wezterm
> 
> Of course we can and should add Smulx/Su to the others.
> But the bigger problems is:
> 
> 2.
> 
> Out of the ones you mention,
> alacritty, Apple Terminal.app, iTerm and wezterm
> impersonate XTerm by setting `TERM=xterm256color`
> (as do others like gnome-terminal and Konsole).
> 
> As far as I can tell this means that
> /usr/share/terminfo/x/xterm+256color should be used, which does *not*
> support curly and colored underlines.
> 
> I'd be very curious to hear what kind of magic Emacs and/or your
> system uses to somehow still get Su/Smulx support for those terminals.
> 
> Especially for Terminal.app, which does not even support XTVERSION;
> the only way to work around its quirks is by checking if $TERM_PROGRAM
> is "Apple_Terminal", which I don't see Emacs doing.

I don't think I have done anything special here.  I have a mostly stock 
MacOS, version 15.3.2 with the following leaf packages installed from 
Homebrew with no customization:

$ brew leaves
aspell
autoconf
bash
bash-completion
binutils
ghostscript
most
nano
p7zip
pkgconf
popler
python <at> 3.13
texinfo

> 3.
> 
> However way you got Emacs to think Terminal.app supports curly
> underlines, it definitely does not support the de-facto standard
> control sequence here. Even worse: it interprets that command as
> "paint the background yellow". To reproduce:
> 
> 	printf '\033[4:3mcurly\033[m'

I did not get Emacs to think Terminal.app supports wavy underlines.  
Emacs 30.1 returns nil for (display-supports-face-attributes-p 
'(:underline (:style wave))) on Terminal.app.  I think one other 
terminal didn't support wavy underlines and Emacs returned nil for as 
well, though I do not recall which one.  All the other terminals 
supported wavy underlines and Emacs returned t when checked with 
display-supports-face-attributes-p.  I see the same "paint the 
background yellow" behavior in Terminal.app when I emit escape sequences 
directly.

  -- MJF

Previous Next

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