Subject: Re: bug#77846: [PATCH ]31.0.50; C# dotnet compiler output incorrectly handled by compilation-mode

From: Mattias Engdegård <[email-masked]>
Date: Sat, 19 Apr 2025 21:28:22 +0200

18 apr. 2025 kl. 18.57 skrev Jostein Kjønigsen <[email-masked]>:

> From trying to read the MSBuild source code, my best guess so far is that the escape-code seems to be used in an elaborate output-mode detection process:
> 
> https://github.com/dotnet/msbuild/blob/a9d68ab58eab3c25b6378a90be8060dd1429a6ef/src/Framework/NativeMethods.cs#L1588-L1642

Not sure if that particular piece of code is relevant but you probably know MSBuild (and C#) better. I spent all of five minutes searching the msbuild project for insertion or detection of `<ESC> =` but nothing obvious showed up, so there is probably something we don't quite understand here.

It makes no sense to emit that sequence from a non-interactive program to a terminal because it doesn't affect the output in any way. Does it come from the C# compiler proper, from MSBuild, or some other software component (no idea how this all fits together, as you can tell).

>> Perhaps it's compilation-filter-hook that really should be used to filter it out, and other sequences like it?
> 
> That also seems like an appropriate solution.
> 
> Is there precedence for solution like in place already?

This hook would be the most obvious thing to use if the stray sequence is emitted by a different layer and risks appearing in different contexts. For example, one could write something like

> (defun stray-msbuild-seq-compilation-filter ()
>   (defvar compilation-filter-start)
>   (let ((begin compilation-filter-start)
>         (end (point))
>         (inhibit-read-only t))
>     (save-excursion
>       (goto-char begin)
>       (while (re-search-forward (rx bol "\e=") end t)
>         (delete-region (match-beginning 0) (match-end 0))))))

and then add that function to compilation-filter-hook.