> On 7 Sep 2023, at 14:09, Dmitry Gutov <dmitry@gutov.dev> wrote:
> 
> On 05/09/2023 22:31, Jostein Kjønigsen wrote:
> > The patch so far is attached. It’s intentionally -not- optimized to leave room for TSX cases which may arise, so hopefully no need to nitpick this yet.
> 
> I was going to nitpick it, but then read the rest of your message ;-(
> 
>> However the patch for js-ts-mode has lots of … interesting stuff about jsx I have not included, for no other reason than not understanding what type of use-cases they are meant to support.
>> If someone can provide me some examples for the JSX use-cases, I can try to make room for TSX-variants of the same code.
> 
> The idea was to "enclose" every TSX in "generic string" syntax so that whatever unpaired characters are inside (such as (, ", ...), won't affect syntax-ppss status on the outside. I'm not sure how critical that is, but I guess some users might encounter such situations.
> 
> Examples like:
> 
>  ReactDOM.render(
>    <div className="">
>      <h1>Hello, Welcome to React and TypeScript ;-(</h1>
>    </div>,
>    // type closing paren here and see that it's matched to opener above
>    document.getElementById("root")
>  );
> 

Ok. That makes sense, and explains everything. I’ve tried implementing the same thing for tsx-ts-mode too in the attached patch. (You may start nitpicking now).

I first tried using a more naive and wide approach only trying to capture full (jsx_element) blocks without any further constraints.
What I found was that when having nested elements (which one tend to have all the time), the syntax-propertizing would cancel itself for every second nesting.

So to fix that, I’ve tried to anchor the query to top-level constructs which typically does not nest. Looking at the query for js.el, I can only assume that you were trying to too solve the same problem, Dmitry?

But without further ado… Here’s the patch. Do your worst, gentlemen :D