bug#59662: 29.0.50; [PATCH] Add treesit--indent-defun

[Dmitry Gutov <dgutov@yandex.ru>]

On 08/12/2022 16:53, Eli Zaretskii wrote:
>> Date: Thu, 8 Dec 2022 16:18:17 +0200
>> Cc: monnier@iro.umontreal.ca, larsi@gnus.org, 59662@debbugs.gnu.org,
>>   casouri@gmail.org
>> From: Dmitry Gutov <dgutov@yandex.ru>
>>
>> On 08/12/2022 10:56, Theodor Thornhill wrote:
>>>       (if (or (and (treesit-available-p)
>>>                    (treesit-ready-p (treesit-language-at (point)))
>>>                    (string-match-p
>>>                     treesit-comment-type-regexp
>>>                     (treesit-node-type (treesit-node-at (point)))))
>>
>> I was kind of hoping that sometime in the near future our tree-sitter
>> code would somehow plug into syntax-ppss (maybe via advice or etc) to
>> provide the same results faster.
> 
> It is too early to consider practical code along these lines, we don't
> have enough experience with tree-sitter.  I'm not even sure it can be
> easily factored into the same categories as syntax-ppss uses.

I'm fairly certain that tree-sitter contexts could be "dumbed down" into 
syntax-ppss categories.

But that's not the only way: another is to just use tree-sitter to find 
a "safe place" to call parse-partial-sexp from. That would give us the 
speed bump together with 100% backward compatibility.

> IMO, the way to move to a unified handling is to use tree-sitter
> wherever we can, originally as special-cased code, and later refactor
> that into generalized APIs, when we know more about how to define and
> use them.

syntax-ppss is used in a lot of places. A "free" improvement like the 
above wouldn't hurt.

>> So my preference would be to check in the implementation as-is (if
>> everybody agrees with the behavior), and then migrate it to new helpers
>> (in case plugging into syntax-ppss won't be automatic).
>>
>> But I don't really mind the code you posted, if somebody (e.g. Eli) is
>> going to insist on it. It just doesn't seem critical from the
>> performance POV, and the variable treesit-comment-type-regexp seems to
>> be a little out of place. But then again, if the helpers will be put in
>> prog-mode.el, the var will be there as well.
> 
> I don't insist, but it sounds like the logical thing to do.  So unless
> you feel strongly against that, I'd say let's add that part.  This is,
> after all, an experiment, so let's experiment.

I'm not going to object.

Doubly so if somebody else wants to finish up the patch and commit it 
with NEWS and documentation updates. ;-)