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

Previous Next

Full log

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Johannes Altmanninger <aclopte <at> gmail.com>
Cc: 77872 <at> debbugs.gnu.org, jared <at> finder.org
Subject: Re: bug#77872: [PATCH 1/2] ansi-term: ignore CSI commands with
 subparams
Date: Fri, 18 Apr 2025 14:40:45 +0300

> Date: Fri, 18 Apr 2025 11:00:37 +0200
> From: Johannes Altmanninger <aclopte <at> gmail.com>
> Cc: Jared Finder <jared <at> finder.org>, 77872 <at> debbugs.gnu.org
> 
> > > I'd rather ansi-term ignore the curly underline command until it's
> > > implemented.
> >
> > We could have this behavior as an option, conditioned on some user
> > option, perhaps.
> 
> I would not be interested in an off-by-default option because if a
> user says "this doesn't work in ansi-term" then I can already tell
> them "use a different terminal, such as M-x vterm", so it wouldn't
> really reduce effort.

Your program seems to have unusual requirements, in that it doesn't
want the fallback to underline for some reason that is specific to the
program.  So I don't see any way except opt-in behavior, because
making this the default would be backward-incompatible, and in most
situations, where any kind of underline is fine, it will not make
sense.

> 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).

That might be better, but won't it slow down ansi-term?

> In future, to get out of this mess, we should consider not asking
> for Smulx/Su and simply emit the styled sequences unconditionally.

I'm not sure this is a viable alternative, but I'm not an expert on
these matters.

Previous Next

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