No news from the copyright assignment front yet.
On 2 Jun 2025, at 08:21, Jared Finder <jared@finder.org> wrote:
Only minor comments, otherwise the patch generally looks good.
+(defcustom term-osc-handlers '(("0" . ansi-osc-window-title-handler)
+ ("2" . ansi-osc-window-title-handler)
+ ("7" . ansi-osc-directory-tracker)
+ ("8" . ansi-osc-hyperlink-handler))
The variable ansi-osc-handlers in ansi-osc.el doesn't handle OSC 0 (set icon and title), but here it's handled. I
OSC 0 is the code I saw most commonly used in the wild and it works well with ansi-osc-window-title-handler, so I propose, in the new version of this patch, to add it to ansi-osc-handlers (which term now calls).
Should this particular change be in another patch instead, with another set of reviewers?
would think the two should be identical. Also what's the rationale for duplicating ansi-osc-handlers instead of just adding a new custom variable that tells term to look at asci-osc-handlers?
OSC handlers run in different environments when called by term than when called by ansi-osc. ansi-osc is typically called on a compilation buffer, during or even after compilation.
That said, it’s true that, in many cases, OSC handlers, if they’re written correctly and especially if they’re just cosmetic, will work in both environments, so it might be convenient to be able to configure them once for both environments, as long as we can configure them differently if needed.
It’s not a straightforward situation. I thought that a solution with two separate configurations variable would be simpler and safer.
I updated the patch to allow delegating to ansi-osc-handlers, but still allow overriding if necessary.
I find this delegation part a bit complicated.
The root of the problem is that we can’t assume that handlers written for one environment work in the other environment, or even that they make sense.
When called by term:
- they are run at the time they appear in the stream, at the position the cursor is in (not necessarily at the end of the text)
- they have access to a process they can communicate with
When called by ansi-osc:
- they are run at the position they appear in a buffer containing a mix of text and uninterpreted terminal sequences followig it
- they cannot assume that there is a process to communicate with
The first point means that a handler written for ansi-osc might very well be confused when run in a terminal, depending on what they need to do. The current handlers happen to all work in both environment, but that’s not a given.
The second point means that a handler written for term might also be confused not having access to a real terminal and process to communicate with.
For example, a handler for OSC 4;c;spec written for the compilation buffer mightimplement "Change Color Number c to the color specified by spec” but it would not implement "If a "?" is given rather than a name or RGB specification, xterm replies with a control sequence of the same form which can be used to set the corresponding color.” while a handler for term could implement both.
(quotes from https://www.xfree86.org/current/ctlseqs.html)
+(ert-deftest term-ignore-osc()
Style nit: there should be a space between the symbol term-ignore-osc and the (). This should look like a defun of no arguments.
I fixed this.