all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Theodor Thornhill <theo@thornhill.no>
To: Perry Smith <pedz@easesoftware.com>
Cc: emacs-devel@gnu.org, bozhidar@batsov.dev
Subject: Re: ruby-ts-mode.el -- first draft
Date: Sun, 11 Dec 2022 17:26:54 +0100	[thread overview]
Message-ID: <CDD1E5C4-E9C5-46C8-B089-E1177A3BE0FC@thornhill.no> (raw)
In-Reply-To: <8340D08F-A596-4551-B7B1-B1E63E098E73@easesoftware.com>



(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



  parent reply	other threads:[~2022-12-11 16:26 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-12-11  3:51 ruby-ts-mode.el -- first draft Perry Smith
2022-12-11  4:25 ` Stefan Monnier
2022-12-11  7:55 ` Eli Zaretskii
2022-12-11 13:58   ` Perry Smith
2022-12-11 14:55     ` Eli Zaretskii
2022-12-11  8:22 ` Theodor Thornhill
     [not found]   ` <8340D08F-A596-4551-B7B1-B1E63E098E73@easesoftware.com>
2022-12-11 16:26     ` Theodor Thornhill [this message]
2022-12-11 16:42       ` Perry Smith
2022-12-11 17:26         ` Bozhidar Batsov

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CDD1E5C4-E9C5-46C8-B089-E1177A3BE0FC@thornhill.no \
    --to=theo@thornhill.no \
    --cc=bozhidar@batsov.dev \
    --cc=emacs-devel@gnu.org \
    --cc=pedz@easesoftware.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.