GNU bug report logs - #62333
30.0.50; Issue with tree-sitter syntax tree during certain changes

Previous Next

Package: emacs;

Reported by: Wilhelm Kirschbaum <wkirschbaum <at> gmail.com>

Date: Tue, 21 Mar 2023 14:15:01 UTC

Severity: normal

Found in version 30.0.50

Full log


View this message in rfc822 format

From: Dmitry Gutov <dgutov <at> yandex.ru>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: wkirschbaum <at> gmail.com, casouri <at> gmail.com, 62333 <at> debbugs.gnu.org
Subject: bug#62333: 30.0.50; Issue with tree-sitter syntax tree during certain changes
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: wkirschbaum <at> gmail.com, casouri <at> gmail.com, 62333 <at> debbugs.gnu.org
>> From: Dmitry Gutov <dgutov <at> yandex.ru>
>>
>>> 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.




This bug report was last modified 2 years and 77 days ago.

Previous Next


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