Subject: bug#62333: 30.0.50; Issue with tree-sitter syntax tree during certain changes

From: Dmitry Gutov <[email-masked]>
Date: Sun, 26 Mar 2023 12:25:30 +0300

On 26/03/2023 08:04, Eli Zaretskii wrote:
>> Date: Sun, 26 Mar 2023 00:57:22 +0200
>> Cc: [email-masked], [email-masked], [email-masked]
>> From: Dmitry Gutov <[email-masked]>
>>
>>> How does that work with features such as font-lock, which do widen?
>>
>> Using font-lock-dont-widen.
> 
> That's only for font-lock.  Parsing was not on the table when that was
> introduced, so it doesn't have a similar mechanism.

Parsing is on-demand, by font-lock and other features.

>> We've had this discussion several times over by now. Should it be
>> documented somewhere?
> 
> Probably, but that's a tangent.
> 
>>> Anyway, isn't this discussion a bit premature, as no TS mode has been
>>> used with the mmm framework yet?
>>
>> There is no reason to assume that: the combinations of modes are just a
>> matter of user configuration. And so far it should be working okay.
> 
> Again, I'm talking about using a parser library.  We may need to
> introduce a way of limiting the parser to a certain range of buffer
> text positions, independently of narrowing.

Except it's already limited by narrowing.

> As we all know, narrowing
> is a problematic feature to use in Lisp programs, so maybe we should
> do this better in the case of parsers.  Then problems like this one
> could be solved more cleanly and simply.

Narrowing problematic to use in Lisp?

>> And anyway, I like I mentioned, this will break this common pattern as well:
>>
>>     (save-restriction
>>       (narrow-to-region ... some-limit-position)
>>       (forward-sexp))
>>
>> I've used it in ruby-syntax-propertize-percent-literal, for example.
>> Except with 'forward-list' rather than 'forward-sexp', but others can
>> use the latter.
> 
> You want to repeat all the arguments we already brought up?

You might choose to ignore a third-party mode, but breaking a common 
pattern seems more dangerous.