On 29 Nov 2022, at 22:48, Theodor Thornhill <theo@thornhill.no> wrote:



On 29 November 2022 22:37:25 CET, "Jostein Kjønigsen" <jostein@secure.kjonigsen.net> wrote:
Nice!

Should we until further notice assume that js-ts-mode suffers from the same issues, and that a jsx-ts-mode might be needed too? To me it at least sounds plausible. 

No, because there are no ambiguities in the grammar with types and jsx.

Note this behaviour was triggered even when a HTML-tag was contained inside a plain string. 

Even without hard typescript casts, there are places where I suspect the same issues can bleed into js-ts-mode. 

I’ll try to do more testing tomorrow. 

First of all - good news!

Contrary to my expectations, I've tested and I cannot reproduce this issue in js-ts-mode.

Even more good news:

Looking deeper into this using treesit-explorer-mode (an extremely helpful tool, Yuan!), I found I may have misinterpreted the state of the parse-tree in previous report.

Based on that, I would like to revise this bug report:

• HTML-like constructs inside strings are --not-- treated at jsx_opening_elements,
• only angle-bracket "hard" casts (which isn't present in Javascript) is causing issues for fontification.
  

Also, reading up, from what I can tell "hard casts" using angle-brackets are no longer encouraged as the default way to cast:

    const service = <IService>object;

This is because the above code will cause a compiler error if used in TSX-files (as opposed to TS-files). Instead "as" expressions are preferred, because they work equally well for both TS & TSX-files:

    const service = object as IService;

That means that writing idiomatic TypeScript with typescrip-ts-mode should produce the expected behaviour, while one may encounter issues with older code.

I'm not sure introducing a new major-mode for this 1 aspect of TypeScript development is worth it?

Does anyone else have an opinion on this?