Are variations such as these desired?

Are variations such as these desired?

[Perry Smith]

[-- Attachment #1.1: Type: text/plain, Size: 2378 bytes --]

Adding on to the ruby-ts-mode I thought I would point out an example of the type of power available with tree sitter.

With a not so complex function:

(defun my-func ( node parent &rest _)
  "Proof of concept to do right justification of NODE and PARENT."
  (message "here %s" (treesit-node-text node))
  (let* ((children (treesit-node-children parent t))
         (open-bracket (nth 0 (treesit-node-children parent nil)))
         (first-child (nth 0 children))
         (same-line (equal (line-number-at-pos (treesit-node-start open-bracket))
                           (line-number-at-pos (treesit-node-start first-child))))
         (max-length (apply #'max (mapcar (lambda ( child )
                                            (- (treesit-node-end child) (treesit-node-start child)))
                                          children)))
         (node-length (- (treesit-node-end node) (treesit-node-start node)))
         (grand-parent-bol (save-excursion
                             (goto-char (treesit-node-start (treesit-node-parent parent)))
                             (back-to-indentation)
                             (point)))
         (align-column (if same-line
                           (- (+ (treesit-node-end open-bracket) max-length 1) ruby-ts-mode-indent-offset)
                         (+ grand-parent-bol max-length 1))))

    (- align-column node-length)))

And two indent rules:

           ((query "(array \"[\" ( (_) ( \",\" (_) )*) @indent \",\"? \"]\")") my-func ruby-ts-mode-indent-offset)
           ((n-p-gp "]" "array" "assignment") grand-parent ruby-ts-mode-indent-offset)

The programmer can now right justify elements of an array in two different fashions:


if dog
  array = [
       145,
     21110,
        11
    ]
end

if dog
  array = [   145,
            21110,
               11]
end

The two rules could be conditionally added to the rest of the rules via a customizable boolean variable such as ruby-ts-mode--right-justify-arrays (for example).

And this concept could be applied to hashes.  The possibilities are almost endless.

My question is, do others see adding this versatility at this point in time to the Emacs distribution as desirable?  Should we wait and see how users use the new system?  Perhaps some see both of the above formats as abominations.

Perry


[-- Attachment #1.2: Type: text/html, Size: 7164 bytes --]

[-- Attachment #2: Message signed with OpenPGP --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: Are variations such as these desired?

[Eli Zaretskii]

> From: Perry Smith <pedz@easesoftware.com>
> Date: Mon, 12 Dec 2022 18:46:29 -0600
> 
> My question is, do others see adding this versatility at this point in time to the Emacs distribution as desirable?
>  Should we wait and see how users use the new system?  Perhaps some see both of the above formats as
> abominations.

Those are questions for Ruby users here to answer, I think.  If these
feature are seen as important ones, we could add them now.

Re: Are variations such as these desired?

[Perry Smith]

[-- Attachment #1: Type: text/plain, Size: 702 bytes --]


> On Dec 13, 2022, at 06:14, Eli Zaretskii <eliz@gnu.org> wrote:
> 
>> From: Perry Smith <pedz@easesoftware.com>
>> Date: Mon, 12 Dec 2022 18:46:29 -0600
>> 
>> My question is, do others see adding this versatility at this point in time to the Emacs distribution as desirable?
>> Should we wait and see how users use the new system?  Perhaps some see both of the above formats as
>> abominations.
> 
> Those are questions for Ruby users here to answer, I think.  If these
> feature are seen as important ones, we could add them now.

Yea.  I can go poke a few Ruby forums and see what type of responses I get.  I might be able to drum up some users to test and try things out as well.


[-- Attachment #2: Message signed with OpenPGP --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: Are variations such as these desired?

[Stefan Monnier]

> The two rules could be conditionally added to the rest of the rules
> via a customizable boolean variable such as
> ruby-ts-mode--right-justify-arrays (for example).

I would welcome addition of some kind of "ts-align" functionality which
uses the tree-sitter info to align code elements.

I've had it as a todo for SMIE but never got around to it.

It should be possible to make it work well even in the absence of any
extra info provided by the major mode, AFAICT.


        Stefan

Re: Are variations such as these desired?

[Perry Smith]

[-- Attachment #1: Type: text/plain, Size: 832 bytes --]



> On Dec 13, 2022, at 08:36, Stefan Monnier <monnier@iro.umontreal.ca> wrote:
> 
>> The two rules could be conditionally added to the rest of the rules
>> via a customizable boolean variable such as
>> ruby-ts-mode--right-justify-arrays (for example).
> 
> I would welcome addition of some kind of "ts-align" functionality which
> uses the tree-sitter info to align code elements.
> 
> I've had it as a todo for SMIE but never got around to it.
> 
> It should be possible to make it work well even in the absence of any
> extra info provided by the major mode, AFAICT.

Ahh!!!  I think that might be what I’ve been mentally groping for.

So, your idea is like “align" except instead of using regular expressions, it
would use Tree Sitter queries — or similar such concepts.

Am I on the right track?


[-- Attachment #2: Message signed with OpenPGP --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: Are variations such as these desired?

[Stefan Monnier]

> So, your idea is like “align" except instead of using regular expressions, it
> would use Tree Sitter queries — or similar such concepts.

That's the idea, yes.

You could use the approach in your code: take point as a specification of
"the node to align", and then look at the children of that node and
their children's children, ...

For each level, check if all the children appear on a different line: if
they're all on the same line, we're too low in the tree and we should
stop recursing (if some are on the same line but not all, you get to
decide whether you want to try and align or not).

Otherwise, align them all together.  There might need to be some
heuristic (or major-mode-provided info) in this part so we do:

    x   = 5;
    yup = 42;

instead of

    x   = 5 ;
    yup = 42;

or

    x =   5 ;
    yup = 42;

For SMIE, we don't have "nodes", so I was thinking of having the user
specify a region of interest and look for tokens with the same
precedence placed on different lines.


        Stefan

Re: Are variations such as these desired?

[Dmitry Gutov]

On 13/12/2022 02:46, Perry Smith wrote:
> if dog
>    array = [
>         145,
>       21110,
>          11
>      ]
> end
> 
> if dog
>    array = [   145,
>              21110,
>                 11]
> end

I've never seen code like that in the wild, nor had a desire to write 
such, but like Stefan has brought up, similar logic could be used to 
line up assignments.