GNU bug report logs - #61104
29.0.60; typescript-ts-mode does not provide compilation-mode support

Previous Next

Full log

View this message in rfc822 format

From: Jostein Kjønigsen <jostein <at> secure.kjonigsen.net>
To: Mattias Engdegård <mattias.engdegard <at> gmail.com>, jostein <at> kjonigsen.net
Cc: casouri <at> gmail.com, 61104 <at> debbugs.gnu.org, Theodor Thornhill <theo <at> thornhill.no>, Eli Zaretskii <eliz <at> gnu.org>
Subject: bug#61104: 29.0.60; typescript-ts-mode does not provide compilation-mode support
Date: Mon, 6 Feb 2023 18:05:52 +0100

On 2/6/23 12:19, Mattias Engdegård wrote:
> Thank you! I translated the regexps to rx (which I personally find 
> more maintainable and has plenty of precedence in this context) and 
> tightened them up further. They are now anchored at beginning-of-line 
> again, and file names cannot start with whitespace (for disambiguation 
> and speed). 
Thanks. These are all good changes.
> I also removed the part that matches the actual message text since it isn't needed, and it would highlight (with an underline in the standard theme) the whole text which is a bit ungainly to read. If the message is multi-line, which earlier examples in this discussions indicated might be the case, then only the first would be highlighted this way which wasn't ideal either.
Seconded. No issues with that either.
> Does tsc distinguish between warnings, errors, and 'informational' messages (such as locations of interest that are not errors in their own right)? The examples you supplied all had the word "error" in a prominent place.

I don't think so. There are code-analysis warnings which seems to be 
provided to your editor of choice through LSP. These can be made into a 
compilation-error with the appropriate config-flag, but I can't out of 
the blue find any "middle ground" where they are emitted compile-time as 
warnings.

Someone please correct me if I'm wrong.

> It would be possible to join the two tsc rules into a single one which would be slightly faster, but having them separate could also be an advantage since it would allow for them to be disabled individually in case of clashes.

To me that sounds like an optimization going one step too far. It will 
result in a more complex expression, which is harder to work 
with/maintain, and might also be more computationally expensive due to 
back-tracking complexity.

I personally think that having 2 self-documented expressions side by 
side works better, but I'm no authority on compilation-mode and 
performance :)

> Patch attached, please tell me what you think.
I've tested that patch myself, and from what I can tell, it still works 
just fine :)

--
Jostein

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.