GNU bug report logs -
#78263
[PATCH 1/3] Ignore OSC sequences in term instead of printing them
Previous Next
Full log
View this message in rfc822 format
[Message part 1 (text/plain, inline)]
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.
[0001-Handle-OSC-sequences-in-term.patch (application/octet-stream, attachment)]
[Message part 3 (text/plain, inline)]
> On 5 May 2025, at 19:36, Per Bothner <per <at> bothner.com> 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
> per <at> bothner.com http://per.bothner.com/
>
This bug report was last modified 3 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.