From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Theodor Thornhill Newsgroups: gmane.emacs.devel Subject: Re: ruby-ts-mode.el -- first draft Date: Sun, 11 Dec 2022 17:26:54 +0100 Message-ID: References: <065A1DE9-B9BA-4AA3-9D59-D0F5547B8824@easesoftware.com> <87v8mixscb.fsf@thornhill.no> <8340D08F-A596-4551-B7B1-B1E63E098E73@easesoftware.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="32696"; mail-complaints-to="usenet@ciao.gmane.io" Cc: emacs-devel@gnu.org, bozhidar@batsov.dev To: Perry Smith Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sun Dec 11 17:27:56 2022 Return-path: Envelope-to: ged-emacs-devel@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1p4PBD-0008II-Ia for ged-emacs-devel@m.gmane-mx.org; Sun, 11 Dec 2022 17:27:56 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1p4PAa-0007Kw-Jg; Sun, 11 Dec 2022 11:27:16 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1p4PAZ-0007Kl-2g for emacs-devel@gnu.org; Sun, 11 Dec 2022 11:27:15 -0500 Original-Received: from out-150.mta0.migadu.com ([91.218.175.150]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1p4PAW-0004Y0-MB for emacs-devel@gnu.org; Sun, 11 Dec 2022 11:27:14 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=thornhill.no; s=key1; t=1670776030; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=x5mpARlwqpTZH944kIgvcuZ2MfSawhjuQo8x1tW9Ovo=; b=F5eMSrUzjpqictpL29OWfwqLQsBCDawHpC2rITqnihvCAKlqY4CLOcg5t/02477vYTcl92 W/VxdWt4ylDMF277xuIjdO2rK6Is6EPWp7+tC2iMGmsUdwsl7z3T498v7cEQe/vA3uNNE7 jAnxuIP1mO4kLS5Yz7bORTfYkfH9zY2VHNoqjEJwFh9ScQQtCRBJ8BmzJRdJMk0OWdqIZd iJD+qvthvrbuz6LN0jwEQuIAMYzCmCT/YIy8qefgfmkFZO1d+qItgSBBus9kNdRymr6LE5 NM1PN24nvXzNpccmMthOqrrfITBMmZLCk7+HANj9B/Y5M/SV3SRXQO5bCLc5hg== X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. In-Reply-To: <8340D08F-A596-4551-B7B1-B1E63E098E73@easesoftware.com> X-Migadu-Flow: FLOW_OUT Received-SPF: pass client-ip=91.218.175.150; envelope-from=theo@thornhill.no; helo=out-150.mta0.migadu.com X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.devel:301154 Archived-At: (added back in emacs-devel) On 11 December 2022 16:10:54 CET, Perry Smith wr= ote: >On Dec 11, 2022, at 02:22, Theodor Thornhill wrote: >>=20 >>> (defcustom ruby-ts-mode-indent-style 'base >>> "Style used for indentation=2E >>>=20 >>=20 >> I believe we decided against using this indent style technique unless w= e >> had specific styles to show=2E A user could just: >>=20 >> (add-hook 'ruby-mode-hook >> (lambda () >> (setq treesit-simple-indent-rules >> my-personal-ruby-indent-rules))) >>=20 >> to override the current default anyway=2E > >I don=E2=80=99t disagree but here are some Ruby specific thoughts and why= I choose to have a =E2=80=9Cbase=E2=80=9D style=2E > >The =E2=80=9Clint=E2=80=9D in the Ruby community is called Rubocop and it= is rather strongly opinionated out of the box but you can adjust it to you= r liking=2E I predict someone will write a set of rules that 100% recreate= s Rubocop=E2=80=99s out of the box settings=2E I think a lot of users woul= d like to have an easy way to enable those =E2=80=9Crules=E2=80=9D which I = consider rather strict=2E And, at the same time, I think there will be a l= ot of users would like a more relax set of rules=2E So I am expecting two = sets of rules to be developed=2E > 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 vanishe= s=2E If we are not good enough people will just create the modes=2E Maybe r= ubocop could be plugged into the Emacs tree-sitter integration?Luckily rubo= cops author loves Emacs, so they might offer some useful feedback (added Bo= zhidar Batsov to cc)=2E >Of course, these rules could be off in another package that users can eas= ily load=2E =E2=80=A6 problem solved=2E > >The other thought I had while writing it is to have various switches that= could be turned off and on=2E This concept is implemented in the font loc= k side of the house but isn=E2=80=99t implemented on the indent side=2E Fo= r example, the way I format assignment of a variable to an array or hash I = could see having three different styles (I won=E2=80=99t elaborate here)=2E= So rather a choice of global styles, there could be a set of customizable= variables that cherry pick particular sets of indent rules=2E > Yes I agree, but if you have a particular design in mind I'm sure other mo= des can benefit from that as well=2E Maybe that should be an addition to tr= eesit=2Eel for all to use? >Another option would be to put the various sets of rules in separate vari= ables and then the final set the user could cherry pick the desired set of = rules=2E > >The system is incredibly beautiful and versatile and I haven=E2=80=99t se= en all the discussions on how to manage and use the versatility that Emacs = now has=2E I view myself at being rather bad when faced with these types o= f decisions and choices=2E I say bring forward something so we have something to discuss :-) > >>> "Font Lock mode face used in ruby-ts-mode to hightlight assignments= =2E" >>> :group 'font-lock-faces) >>=20 >> 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=2E I wanted the face to = be different from the other faces if the user decides to turn on the featur= e=2E > >>> (ruby-ts-mode--imenu-helper nodes))) >>>=20 >>=20 >> Are you sure we don't want more granularity than this? Why is >> everything in the same regexp? > >I didn=E2=80=99t even know imenu existed two days ago :-) The current im= plementation appears to produce the same list of items that ruby-mode does = and styles it like c-ts-mode does=2E > >Perry > Sure! I have no strong opinions, but you could look at how java-ts-mode do= es it for a slightly different approach=2E Theo