From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Daniel Colascione Newsgroups: gmane.emacs.devel Subject: Re: c-ts-mode style customization Date: Thu, 23 Mar 2023 17:06:35 -0400 Message-ID: <187104b7b78.2829.cc5b3318d7e9908e2c46732289705cb0@dancol.org> References: <87355wu4hn.fsf@dancol.org> <45CB19FB-4D80-4C71-8083-D836F51DFB49@gmail.com> <1870bc95688.2829.cc5b3318d7e9908e2c46732289705cb0@dancol.org> <1870cd213f8.2829.cc5b3318d7e9908e2c46732289705cb0@dancol.org> <79B5F13D-6718-4B47-9CDA-485A07AF36BC@gmail.com> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="187104b7d3c70502829b901d94" Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="19095"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: AquaMail/1.43.0 (build: 104300275) Cc: To: Yuan Fu Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Thu Mar 23 22:07:31 2023 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 1pfS9i-0004gl-E6 for ged-emacs-devel@m.gmane-mx.org; Thu, 23 Mar 2023 22:07:31 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1pfS94-000244-59; Thu, 23 Mar 2023 17:06:50 -0400 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 1pfS92-00020v-8N for emacs-devel@gnu.org; Thu, 23 Mar 2023 17:06:48 -0400 Original-Received: from dancol.org ([2600:3c01:e000:3d8::1]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1pfS8z-0004e4-EL for emacs-devel@gnu.org; Thu, 23 Mar 2023 17:06:48 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=dancol.org; s=x; h=Content-Type:MIME-Version:Subject:References:In-Reply-To:Message-ID: Date:CC:To:From:Sender:Reply-To:Content-Transfer-Encoding:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=GeRfCX9cOScF6gHLu3J9SiBfkG62+fJE5llzvBDMxAc=; b=G6DUOV8Eeot1RyCJTuY0jXYHGu 3KH1XHRxbw7O7yx+UoIydpHv5diXDTy6HbR8B4EzgsH8o3/GTBl5Cj2HoAqKxVwf5b9oW9tRP0hXn 92OlBV2OMOk/SSip+vTQcGR/lAnvyAN40bECP71u9uvaz23+j4z0Re7o4SHyYpLNKjozVQ98y/bvR tyKRw/6cZzX6XSpQPmvUNgrhuLm+IRGA44Jx8lEOvhowj05GS9V1CGXBCBH5DF6zwS2YkTfB1+Weh YMVJETl67UV6s29aa2DxEn9BuWsoIDtaTUNh8e6i7MSauEZw2CuyTc3qAv27+ladNbL27NNHfuxz+ I4CiKyzQ==; Original-Received: from 154.sub-174-239-64.myvzw.com ([174.239.64.154]:8720 helo=[100.126.35.25]) by dancol.org with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256 (Exim 4.94.2) (envelope-from ) id 1pfS8r-0004K1-E2; Thu, 23 Mar 2023 14:06:38 -0700 In-Reply-To: <79B5F13D-6718-4B47-9CDA-485A07AF36BC@gmail.com> Received-SPF: pass client-ip=2600:3c01:e000:3d8::1; envelope-from=dancol@dancol.org; helo=dancol.org 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, HTML_MESSAGE=0.001, SPF_HELO_PASS=-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:304740 Archived-At: This is a multi-part message in MIME format. --187104b7d3c70502829b901d94 Content-Type: text/plain; format=flowed; charset="UTF-8" Content-Transfer-Encoding: 8bit On March 23, 2023 15:20:50 Yuan Fu wrote: >> On Mar 22, 2023, at 9:55 PM, Daniel Colascione wrote: >> >> >> >> On March 22, 2023 20:21:22 Yuan Fu wrote: >> >>>> On Mar 22, 2023, at 5:05 PM, Daniel Colascione wrote: >>>> >>>> >>>> >>>> On March 22, 2023 19:58:22 Yuan Fu wrote: >>>> >>>>>> On Mar 22, 2023, at 8:53 AM, Daniel Colascione wrote: >>>>>> >>>>>> Shouldn't customization of styles in c-ts-mode look more like cc-mode's >>>>>> style machinery? Right now, the closest thing we have to defining a new >>>>>> style is add-advice on c-ts-mode--indent-styles, which isn't >>>>>> particularly convenient or future-proof. You can't drop a new style in, >>>>>> say, .dir-locals. >>>>> >>>>> Actually, you can define a custom function, say, c-ts-mode-my-style, and >>>>> set c-ts-mode-indent-style to the name of it. >>>>> >>>>> Yuan >>>> >>>> >>>> But that doesn't add the new style to the UI selection menu and doesn't let >>>> you define a style in dir-locals. IMHO, cc-mode got this right. >>> >>> You can set c-ts-mode-indent-style in dir-locals, no? >> >> >> No, because I can set that variable only to one of the predefined styles or >> to a function, and a function isn't a safe value of a directory local variable. > > I see, then an alist should solve this. > >> >>> You have a point for UI selection, we can add a >>> c-ts-mode-indent-style-alist that maps style names to rules/functions that >>> returns rules, like c-style-alist. >> >> Why this emphasis on functions? Why would we want the alist values to be >> functions instead of just lists of rules? > > Nothing except that that’s how it is right now. It certainly wouldn’t harm > to allow functions, no? > > Anyway, I agree with the general idea. I’ll add the option to set a rule alist. I gave you a concrete example of a disadvantage of using functions that return data over just using plain data. The principle of least power applies here. > > Yuan --187104b7d3c70502829b901d94 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On March 23, 2023 15:20:50 Yuan Fu <casouri@gmail.com&= gt; wrote:

On Mar 22, 2023, at 9:55 PM, Daniel Colascione <dancol= @dancol.org> wrote:



On March 22, 2023 20:21:22 Yuan Fu <casouri@gmail.com&= gt; wrote:

On Mar 22, 2023, at 5:05 PM, Daniel Colascione <dancol= @dancol.org> wrote:



On March 22, 2023 19:58:22 Yuan Fu <casouri@gmail.com&= gt; wrote:

On Mar 22, 2023, at 8:53 AM, Daniel Colascione <dancol= @dancol.org> wrote:

Shouldn't customization of styles in c-ts-mode look more = like cc-mode's
style machinery? Right now, the closest thing we have to = defining a new
style is add-advice on c-ts-mode--indent-styles, which is= n't
particularly convenient or future-proof. You can't drop a= new style in,
say, .dir-locals.


Actually, you can define a custom function, say, c-ts-mod= e-my-style, and set c-ts-mode-indent-style to the name of it.

Yuan


But that doesn't add the new style to the UI selection me= nu and doesn't let you define a style in dir-locals. IMHO, cc-mode got this= right.

You can set c-ts-mode-indent-style in dir-locals, no?


No, because I can set that variable only to one of the pr= edefined styles or to a function, and a function isn't a safe value of a di= rectory local variable.

I see, then an alist should solve this.


You have a point for UI selection, we can add a c-ts-mode= -indent-style-alist that maps style names to rules/functions that returns r= ules, like c-style-alist.

Why this emphasis on functions? Why would we want the ali= st values to be functions instead of just lists of rules?

Nothing except that that=E2=80=99s how it is right now. I= t certainly wouldn=E2=80=99t harm to allow functions, no?

Anyway, I agree with the general idea. I=E2=80=99ll add t= he option to set a rule alist.
I gave you a concrete example of a disadvantage o= f using functions that return data over just using plain data. The principl= e of least power applies here.




Yuan

--187104b7d3c70502829b901d94--