Subject: Re: bug#78263: [PATCH 1/3] Ignore OSC sequences in term instead of printing them

From: Stéphane Zermatten <[email-masked]>
Date: Mon, 5 May 2025 19:57:45 +0300

I attached a merged version of all 3 patches to this e-mail that handles OSC sequences, so they’re handled right away.  I’m happy to do it that way, if it’s more convenient. 

> On 5 May 2025, at 19:36, Per Bothner <[email-masked]> wrote:
> 
> The whole term-control-seq-regexp is fundamentally broken, and does not appear
> in any version of term.el I have worked on or blessed.  It assumes all relevant sequences
> are complete in a single call to term-emulate-terminal. That is not a safe assumption.
> 
> The correct way to parse terminal escape sequences is using a state machine, as in
> my original implementation. Alternatively, if you really want to use pattern matching,
> it is possible to recognize "incomplete escape sequence", and save that until the
> next call.  However, I don't see any code to handle that; it is possible I'm missing something.
> (That approach can in theory lead to O(n^2) behavior, which the state machine approach avoids,
> but I don't think that is a major problem.)

A state machine is indeed the right way of handling terminal escape sequences, and it would be a great idea to refactor term.el to do it that way. I don’t really want to use pattern matching. I’m using it here because it integrates with the current code. 

The current implementation does indeed recognize incomplete escape sequence, See term-control-seq-prefix-regexp and its use in term-emulate-terminal. It’s a bit, well, funny, but it seems to work. It keeps incomplete sequences in term-terminal-undecoded-bytes for the next call. 

In the patch attached to this e-mail, you’ll notice that I had to add some code that detects whether a sequence is terminated and buffers it for next time, in term-terminal-undecoded-bytes to be consistent with the current implementation. This is covered by the tests. 

If you guys think it’s time to refactor term.el to use a state machine and have time to spend on it, I’d be happy to help as much as I can. It’s a bit scary, because, unless I missed something, test coverage of the existing code isn’t very high, so adding more tests would be, I think, a good first step before engaging in larger changes. 
 
> 
> I agree with Eli that term should when possible handle OSC sequences rather than ignoring them.
> (Ones it can't handle should of course be ignored.)
> 
> On 5/5/25 7:30 AM, Stephane Zermatten wrote:
>> Tags: patch
>> This change detects OSC sequences and ignores them. This is what's
>> normally expected and avoids strange outputs.
>> Starting with version 4, the fish shell has started sending out OSC
>> sequences by default, which looks pretty bad on term. This change avoids
>> this particular problem.
>> This is PATCH 1/3, because I'd like to propose making it possible to
>> handle OSC sequences in term in follow-up changes. Emacs already has
>> handlers for OSC sequences in ansi-osc, why not make use of them?
>> In GNU Emacs 31.0.50 (build 5, x86_64-apple-darwin23.6.0, NS
>>  appkit-2487.70 Version 14.7.5 (Build 23H527)) of 2025-05-02 built on
>>  boomer.zia
>> Repository revision: 99ca41b6ef300653a0d15b73a0c0d446a9a9e059
>> Repository branch: master
>> Windowing system distributor 'Apple', version 10.3.2487
>> System Description:  macOS 14.7.5
>> Configured using:
>>  'configure --program-suffix=-head --with-tree-sitter
>>  --with-native-compilation=aot'
> 
> -- 
> 	--Per Bothner
> [email-masked]   http://per.bothner.com/
>