emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: ruby-ts-mode.el -- first draft


From: Theodor Thornhill
Subject: Re: ruby-ts-mode.el -- first draft
Date: Sun, 11 Dec 2022 17:26:54 +0100


(added back in emacs-devel)

On 11 December 2022 16:10:54 CET, Perry Smith <pedz@easesoftware.com> wrote:
>On Dec 11, 2022, at 02:22, Theodor Thornhill <theo@thornhill.no> wrote:
>> 
>>> (defcustom ruby-ts-mode-indent-style 'base
>>>  "Style used for indentation.
>>> 
>> 
>> I believe we decided against using this indent style technique unless we
>> had specific styles to show.  A user could just:
>> 
>> (add-hook 'ruby-mode-hook
>>          (lambda ()
>>           (setq treesit-simple-indent-rules
>>                 my-personal-ruby-indent-rules)))
>> 
>> to override the current default anyway.
>
>I don’t disagree but here are some Ruby specific thoughts and why I choose to 
>have a “base” style.
>
>The “lint” in the Ruby community is called Rubocop and it is rather strongly 
>opinionated out of the box but you can adjust it to your liking.  I predict 
>someone will write a set of rules that 100% recreates Rubocop’s out of the box 
>settings.  I think a lot of users would like to have an easy way to enable 
>those “rules” which I consider rather strict.  And, at the same time, I think 
>there will be a lot of users would like a more relax set of rules.  So I am 
>expecting two sets of rules to be developed.
>

Why not create the two sets now, rather than later? I think we should try to 
make as good modes as possible so the need for external packages vanishes. If 
we are not good enough people will just create the modes. Maybe rubocop could 
be plugged into the Emacs tree-sitter integration?Luckily rubocops author loves 
Emacs, so they might offer some useful feedback (added Bozhidar Batsov to cc).

>Of course, these rules could be off in another package that users can easily 
>load. … problem solved.
>
>The other thought I had while writing it is to have various switches that 
>could be turned off and on.  This concept is implemented in the font lock side 
>of the house but isn’t implemented on the indent side.  For example, the way I 
>format assignment of a variable to an array or hash I could see having three 
>different styles (I won’t elaborate here).  So rather a choice of global 
>styles, there could be a set of customizable variables that cherry pick 
>particular sets of indent rules.
>

Yes I agree, but if you have a particular design in mind I'm sure other modes 
can benefit from that as well. Maybe that should be an addition to treesit.el 
for all to use?


>Another option would be to put the various sets of rules in separate variables 
>and then the final set the user could cherry pick the desired set of rules.
>
>The system is incredibly beautiful and versatile and I haven’t seen all the 
>discussions on how to manage and use the versatility that Emacs now has.  I 
>view myself at being rather bad when faced with these types of decisions and 
>choices.

I say bring forward something so we have something to discuss :-)

>
>>>  "Font Lock mode face used in ruby-ts-mode to hightlight assignments."
>>>  :group 'font-lock-faces)
>> 
>> Are you sure we need these very specific faces?  Can't we reuse any of
>> the provided ones?
>
>The font lock features can be turned on and off.  I wanted the face to be 
>different from the other faces if the user decides to turn on the feature.
>
>>>    (ruby-ts-mode--imenu-helper nodes)))
>>> 
>> 
>> Are you sure we don't want more granularity than this?  Why is
>> everything in the same regexp?
>
>I didn’t even know imenu existed two days ago :-)  The current implementation 
>appears to produce the same list of items that ruby-mode does and styles it 
>like c-ts-mode does.
>
>Perry
>

Sure! I have no strong opinions, but you could look at how java-ts-mode does it 
for a slightly different approach.

Theo



reply via email to

[Prev in Thread] Current Thread [Next in Thread]