bug#61104: 29.0.60; typescript-ts-mode does not provide compilation-mode support

[Jostein Kjønigsen]

Hey there and thanks for the valuable feedback!

I'll try to do my best to provide the info I can, so that we can create 
the tightest regexps for this, which still are functional on the level 
users would expect.

On 2/4/23 12:59, Mattias Engdegård wrote:
> First of all, both regexps match arbitrary amounts of horizontal whitespace at 
> the beginning of a line, but neither message example you supplied contains any 
> such leading whitespace. This means that either the set of test cases needs to 
> be extended, or we could safely remove this leading whitespace matcher.

I've gone looking, but I really can't find confirmation that this 
whitespace is required, at least not when building directly through the 
tsc TypeScript compiler.
I can see in the old test-suite for the MELPA package these two variants 
were the only test-cases present as well.

As such I think it's defiintely safe to remove this leading whitespace.

> Similarly the patterns match arbitrary whitespace before the word "error". This 
> seems equally questionable -- would a single space do? If not, please provide actual 
> output demonstrating it that could be added to the test suite, and tell us how it varies 
> (tabs vs spaces, amount of whitespace, etc).
I can't see any real use-case for this either. Let's snip it.
> The following is a minor point that we'll fix but I thought you may want to 
> know:
>
> The use of [[:blank:]] and [[:alnum:]] is very likely more expensive than 
> required since they accept Unicode whitespace and letters which obviously never 
> will occur where matched so if it's all the same to you we'll reduce them to 
> ASCII patterns.
I've given this a try, and it seems to work fine. I'm OK with such a change.
> Similarly, the inclusion of \r in patterns seems to be a misunderstanding: the tail part, 
> "[^\r\n]+$", does not make sense -- normally, carriage returns aren't seen in 
> buffers because line terminator translation convert everything to a single \n, and if a 
> stray CR did occur then that pattern would never match anyway (why?).

Fair enough. I've changed the code to only looks for \n instead.

Attached is a patch which codifies all these changes, and from what I 
can tell, still does the job. You make take it as is, or you may further 
work on it, if you think that is still needed.

--
Jostein

0001-Optimize-compilation-mode-expressions-for-TypeScript.patch
Description: Text Data