GNU bug report logs - #59662
29.0.50; [PATCH] Add treesit--indent-defun

Previous Next

Full log

Message #223 received at 59662 <at> debbugs.gnu.org (full text, mbox):

From: Dmitry Gutov <dgutov <at> yandex.ru>
To: Theodor Thornhill <theo <at> thornhill.no>, Eli Zaretskii <eliz <at> gnu.org>
Cc: larsi <at> gnus.org, 59662 <at> debbugs.gnu.org, casouri <at> gmail.com,
 monnier <at> iro.umontreal.ca
Subject: Re: bug#59662: 29.0.50; [PATCH] Add treesit--indent-defun
Date: Fri, 9 Dec 2022 00:03:57 +0200

On 08/12/2022 18:33, Theodor Thornhill wrote:
> 
> 
> On 8 December 2022 17:06:26 CET, Dmitry Gutov <dgutov <at> yandex.ru> wrote:
>> On 08/12/2022 16:58, Theodor Thornhill via Bug reports for GNU Emacs, the Swiss army knife of text editors wrote:
>>> Dmitry Gutov<dgutov <at> yandex.ru>  writes:
>>>
>>>> On 08/12/2022 13:09, Theodor Thornhill wrote:
>>>>> What about this?  I changed it to make a point that we should fill if
>>>>> inside of a string or comment, and indent if inside a code block.  We
>>>>> one such variable for each type, or in both as suggested below.
>>>> Could you rephrase maybe? I'm not seeing the difference.
>>> In the first example I made the variable specific to comments.  But
>>> filling should work on everything that's considered text, IIUC.  So if
>>> the variable refers to both the regex needs to accommodate strings and
>>> comments.  That will in turn make it less useful if we want to find
>>> comments specifically, or strings specifically. so we could have both
>>> 'treesit-comment-regexp' and 'treesit-string-regexp' and match on '(or
>>> treesit-comment-regexp treesit-string-regexp)' in this particular case.
>>>
>>> Not really sure if that made more sense.
>>
>> Ah. So that was about the name of the variable. Looks good.
>>
> 
> Yeah, and thus what nodes it should capture
> 
> 
>> Note that if the improvement which I described ever comes to life (hopefully), then the variable will probably need to be renamed/moved/multiplied again.
> 
> Why is that?

Suppose we have a thingy called tree-sitter-parse-state, or tsps in short.

As a general purpose thigy, it would have the means to check whether the 
state corresponds to a string, or to a comment, at least. Maybe it would 
be able to signal different kinds of strings and comments as well, but 
let's put that aside for now.

For clients to get that info, it can have a general function that would 
return the current node (or maybe a derivative of it) -- call it 
tree-sitter-parse-state, and helpers like tsps-string-p and 
tsps-comment-p, as well as, possibly, tsps-comment-or-string-start. 
Maybe other helpers similar to the fields in the ppss defstruct.

And it seems to me that to implement tsps-string-p and tsps-comment-p 
you will need two different constants like that. Then, in turn, 
prog-fill-or-reindent-defun could be implemented in terms of 
tsps-string-p and tsps-comment-p. It could also call 
tsps-comment-or-string[-start], if such helper will be defined, which 
will internally be implemented either in terms of tsps-*-p functions, or 
use the two corresponding new constants anyway.

Previous Next

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