|
From: | Dmitry Gutov |
Subject: | bug#59662: 29.0.50; [PATCH] Add treesit--indent-defun |
Date: | Fri, 9 Dec 2022 00:03:57 +0200 |
User-agent: | Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.4.2 |
On 08/12/2022 18:33, Theodor Thornhill wrote:
On 8 December 2022 17:06:26 CET, Dmitry Gutov <dgutov@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@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 captureNote 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.
[Prev in Thread] | Current Thread | [Next in Thread] |