From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Jackson Ray Hamilton Newsgroups: gmane.emacs.devel Subject: Re: Comprehensive JSX support in Emacs Date: Fri, 15 Feb 2019 00:21:09 -0800 Message-ID: <4281f8fd-9849-07ef-30f3-8516004930c9@jacksonrayhamilton.com> References: Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="------------ECA1DE5064C8598DE613E691" Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="252234"; mail-complaints-to="usenet@blaine.gmane.org" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.4.0 Cc: emacs-devel@gnu.org To: monnier@iro.umontreal.ca Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Feb 15 09:22:08 2019 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([209.51.188.17]) by blaine.gmane.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1guYl4-0013Hx-Qe for ged-emacs-devel@m.gmane.org; Fri, 15 Feb 2019 09:22:07 +0100 Original-Received: from localhost ([127.0.0.1]:34253 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1guYky-00065c-KB for ged-emacs-devel@m.gmane.org; Fri, 15 Feb 2019 03:22:00 -0500 Original-Received: from eggs.gnu.org ([209.51.188.92]:59673) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1guYkD-0005ny-Qv for emacs-devel@gnu.org; Fri, 15 Feb 2019 03:21:15 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1guYkC-0003KK-G5 for emacs-devel@gnu.org; Fri, 15 Feb 2019 03:21:13 -0500 Original-Received: from mta-10-3.privateemail.com ([198.54.127.62]:16221) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1guYkC-0003Hp-5x for emacs-devel@gnu.org; Fri, 15 Feb 2019 03:21:12 -0500 Original-Received: from MTA-10.privateemail.com (localhost [127.0.0.1]) by MTA-10.privateemail.com (Postfix) with ESMTP id 7E2A960038; Fri, 15 Feb 2019 03:21:10 -0500 (EST) Original-Received: from [192.168.88.227] (unknown [10.20.151.224]) by MTA-10.privateemail.com (Postfix) with ESMTPA id 50B0660033; Fri, 15 Feb 2019 08:21:10 +0000 (UTC) In-Reply-To: Content-Language: en-US X-Virus-Scanned: ClamAV using ClamSMTP X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 198.54.127.62 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.21 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.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.org gmane.emacs.devel:233359 Archived-At: This is a multi-part message in MIME format. --------------ECA1DE5064C8598DE613E691 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Hi Stefan, Thanks for your reply and your code review. > I think it's a good idea to *default* to the sgml- settings if it's > common for users to want SGML-style indentation conventions for those > parts of the code, but if many users want to use different settings in > sgml-mode and jsx-mode, then it makes sense to offer > jsx-specific overrides. Right.=C2=A0 I think Emacs=E2=80=99 conventions for aligning SGML attribu= tes are=20 mostly compatible with Reacts=E2=80=99, so sticking with those, it should= n=E2=80=99t=20 feel too foreign. I think one obvious reason to have JSX-specific settings is that=20 sgml-basic-offset defaults to 2, and js-indent-level defaults to 4; so=20 no matter what, OOTB users probably think Emacs indents JSX =E2=80=9Cwron= g.=E2=80=9D=C2=A0 It=20 would surprise me if people were actually content with using 4 spaces=20 for JS and 2 spaces for JSX blocks within. A philosophical and practical reason to switch will be decoupling JSX=20 from SGML.=C2=A0 Using sgml-indent-line to indent JSX probably should hav= e=20 been kept an implementation detail, but requiring the use of sgml-=20 variables uncovered that detail.=C2=A0 If I end up changing the=20 implementation, as I=E2=80=99m considering, we could pay a price for that= .=C2=A0=20 However, I expect that most users will have already configured their JSX=20 indentation to be consistent with JS, and thus will be unaffected; else,=20 I think most will welcome a change to consistent defaults as a =E2=80=9Cf= ix.=E2=80=9D > Would there be any harm in activating JSX indentation&highlighting in > a Javascript buffer that doesn't use JSX? Indeed, that could eliminate some false negatives and simplify the code,=20 and we may be able to get away with it indefinitely. However, considering JavaScript has a well-respected specification, it=20 seems a bit risky to me to enable non-standard syntax extensions in=20 =E2=80=9C.js=E2=80=9D buffers without some precautions.=C2=A0 The standar= ds body could define=20 new syntax in the base language that invalidates userland syntax=20 extensions, or other syntax extensions with competing semantics could=20 become popular.=C2=A0 JSX itself is a successor to E4X, with which it=20 overlaps partially. I think long-term it=E2=80=99d be less disruptive to users=E2=80=99 confi= gs to define=20 parameters for enabling syntaxes that we can reasonably expect to hold=20 up in an evolving ecosystem.=C2=A0 Hence, looking for specific branding=E2= =80=94like=20 =E2=80=9C.jsx=E2=80=9D files or a =E2=80=9CReact=E2=80=9D variable=E2=80=94= could help us to eventually=20 gracefully add support for a =E2=80=9CTheoreticalAngleBracketsRedux=E2=80= =9D extension=20 also, with =E2=80=9C.jsb=E2=80=9D files / an =E2=80=9CAngleBrackets=E2=80= =9D variable / a =E2=80=9C// @Angles=E2=80=9D=20 magic comment to enable it=E2=80=A6 > - Any reason why you add a call to js--disambiguate-js-from-jsx at the > end of js-syntax-propertize instead of adding it directly within the > syntax-propertize-rules? Reason: Me not knowing what I=E2=80=99m doing. :-)=C2=A0 I figured that c= ould be=20 written better. Actually, I was hoping we=E2=80=99d be able to talk about that part.=C2=A0= I wanted=20 to know if you thought I should repeat the pattern that I see near that=20 code, where js-syntax-propertize-regexp is called in=20 syntax-propertize-function first at the beginning of the function and=20 again later in syntax-propertize-rules =E2=80=94 I haven=E2=80=99t yet fi= gured out why=20 that pattern of calling the same propertize function in multiple places=20 exists in this mode and others (like ruby-mode=E2=80=99s=20 ruby-syntax-propertize/ruby-syntax-propertize-heredoc). I=E2=80=99ve also been wondering in the back of my mind if I=E2=80=99ll n= eed to use=20 syntax-propertize-extend-region-functions in this implementation. Thanks again for talking this through (even though the language may feel=20 a bit foreign!) Jackson (BTW, I=E2=80=99m currently figuring out the process for replying to a ma= iling=20 list =E2=80=94 replying to you, CCing emacs-devel, trying to set In-Reply= -To in=20 my mail client.=C2=A0 Hopefully that works this time.) --------------ECA1DE5064C8598DE613E691 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable

Hi Stefan,

Thanks for your reply and your code review.

I think it's a good idea to *default* to the sgml- settings =
if it's
common for users to want SGML-style indentation conventions for those
parts of the code, but if many users want to use different settings in
sgml-mode and jsx-mode, then it makes sense to offer
jsx-specific overrides.
Right.=C2=A0 I think Emacs=E2=80=99 conventions for aligning SGML a= ttributes are mostly compatible with Reacts=E2=80=99, so sticking with those,= it shouldn=E2=80=99t feel too foreign.

I think one obvious reason to have JSX-specific settings is that sgml-basic-offset defaults to 2, and js-indent-level defaults to 4; so no matter what, OOTB users probably think Emacs indents JSX =E2=80=9Cwrong.=E2=80=9D=C2=A0 It would surprise me if people were = actually content with using 4 spaces for JS and 2 spaces for JSX blocks within.

A philosophical and practical reason to switch will be decoupling JSX from SGML.=C2=A0 Using sgml-indent-line to indent JSX probably should have been kept an implementation detail, but requiring the use of sgml- variables uncovered that detail.=C2=A0 If I end up changing the implementation, as I=E2=80=99m considering, we could p= ay a price for that.=C2=A0 However, I expect that most users will have already configured their JSX indentation to be consistent with JS, and thus will be unaffected; else, I think most will welcome a change to consistent defaults as a =E2=80=9Cfix.=E2=80=9D

Would there be any harm in activating JSX indentation&hi=
ghlighting in
a Javascript buffer that doesn't use JSX?
Indeed, that could eliminate some false negatives and simplify the code, and we may be able to get away with it indefinitely.

However, considering JavaScript has a well-respected specification, it seems a bit risky to me to enable non-standard syntax extensions in =E2=80=9C.js=E2=80=9D buffers without some pre= cautions.=C2=A0 The standards body could define new syntax in the base language that invalidates userland syntax extensions, or other syntax extensions with competing semantics could become popular.=C2=A0 JSX itself is = a successor to E4X, with which it overlaps partially.

I think long-term it=E2=80=99d be less disruptive to users=E2=80=99= configs to define parameters for enabling syntaxes that we can reasonably expect to hold up in an evolving ecosystem.=C2=A0 Hence, looking fo= r specific branding=E2=80=94like =E2=80=9C.jsx=E2=80=9D files or a =E2= =80=9CReact=E2=80=9D variable=E2=80=94could help us to eventually gracefully add support for a =E2=80=9CTheoreticalAngleBracketsRedux=E2=80=9D extension also, wit= h =E2=80=9C.jsb=E2=80=9D files / an =E2=80=9CAngleBrackets=E2=80=9D variable / a =E2=80=9C// @Angl= es=E2=80=9D magic comment to enable it=E2=80=A6

- Any reason why you add a call to js--disambiguate-js-from-js=
x at the
  end of js-syntax-propertize instead of adding it directly within the
  syntax-propertize-rules?

Reason: Me not knowing what I=E2=80=99m doing.=C2=A0 :-)=C2=A0 I figured t= hat could be written better.

Actually, I was hoping we=E2=80=99d be able to talk about that par= t.=C2=A0 I wanted to know if you thought I should repeat the pattern that I see near that code, where js-syntax-propertize-regexp is called in syntax-propertize-function first at the beginning of the function and again later in syntax-propertize-rules =E2=80=94 I haven=E2=80=99= t yet figured out why that pattern of calling the same propertize function in multiple places exists in this mode and others (like ruby-mode=E2=80= =99s ruby-syntax-propertize/ruby-syntax-propertize-heredoc).

I=E2=80=99ve also been wondering in the back of my mind if I=E2=80= =99ll need to use syntax-propertize-extend-region-functions in this implementation.

Thanks again for talking this through (even though the language may feel a bit foreign!)

Jackson

(BTW, I=E2=80=99m currently figuring out the process for replying = to a mailing list =E2=80=94 replying to you, CCing emacs-devel, trying t= o set In-Reply-To in my mail client.=C2=A0 Hopefully that works this time= .)

--------------ECA1DE5064C8598DE613E691--