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

Previous Next

Full log

Message #37 received at 61104 <at> debbugs.gnu.org (full text, mbox):

From: Mattias Engdegård <mattias.engdegard <at> gmail.com>
To: 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: Sat, 4 Feb 2023 12:59:10 +0100

Jostein, thank you for contributing a new compilation-mode pattern!

We generally want these regexps to be as tight as possible while still doing their job. This is partly because the large and ever-growing number of rules tend to interfere with one another, and over-broad patterns have shown to be a source of performance problems in the past.

I hope you don't mind helping us finishing the job:

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.

If leading whitespace indeed can occur, then when and how, exactly? Spaces or tabs, and how many? Please give us examples from actual compiler output.

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).

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.

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?).

Previous Next

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