> On 5 May 2025, at 19:36, Per Bothner 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@bothner.com http://per.bothner.com/ >