unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
From: "Jostein Kjønigsen" <jostein@secure.kjonigsen.net>
To: "Mattias Engdegård" <mattias.engdegard@gmail.com>, jostein@kjonigsen.net
Cc: casouri@gmail.com, 61104@debbugs.gnu.org,
	Theodor Thornhill <theo@thornhill.no>,
	Eli Zaretskii <eliz@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	[thread overview]
Message-ID: <7802fc0d-3abc-8905-411b-4ada721e8013@secure.kjonigsen.net> (raw)
In-Reply-To: <2F86FB50-87F7-432D-B87A-1738056907AB@gmail.com>

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







  reply	other threads:[~2023-02-06 17:05 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-01-27 20:14 bug#61104: 29.0.60; typescript-ts-mode does not provide compilation-mode support Jostein Kjønigsen
2023-01-27 20:30 ` Eli Zaretskii
2023-01-27 20:52   ` Jostein Kjønigsen
2023-01-28  7:23     ` Eli Zaretskii
2023-01-28 14:28       ` Jostein Kjønigsen
2023-02-02 21:01         ` Jostein Kjønigsen
2023-02-03  5:30           ` Theodor Thornhill via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-02-03  7:06             ` Eli Zaretskii
2023-02-03  8:00               ` Theodor Thornhill via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-02-04  8:24                 ` Theodor Thornhill via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-02-04 11:59 ` Mattias Engdegård
2023-02-05 20:36   ` Jostein Kjønigsen
2023-02-06 11:19     ` Mattias Engdegård
2023-02-06 17:05       ` Jostein Kjønigsen [this message]
2023-02-06 17:34         ` Mattias Engdegård

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=7802fc0d-3abc-8905-411b-4ada721e8013@secure.kjonigsen.net \
    --to=jostein@secure.kjonigsen.net \
    --cc=61104@debbugs.gnu.org \
    --cc=casouri@gmail.com \
    --cc=eliz@gnu.org \
    --cc=jostein@kjonigsen.net \
    --cc=mattias.engdegard@gmail.com \
    --cc=theo@thornhill.no \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).