From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Re: Comprehensive JSX support in Emacs Date: Thu, 14 Feb 2019 09:10:48 -0500 Message-ID: References: <1423022755.65233.1550120813763@privateemail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="113949"; mail-complaints-to="usenet@blaine.gmane.org" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Feb 14 15:32:03 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 1guI3W-000TP6-1C for ged-emacs-devel@m.gmane.org; Thu, 14 Feb 2019 15:32:02 +0100 Original-Received: from localhost ([127.0.0.1]:49484 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1guI3U-0007BP-Uj for ged-emacs-devel@m.gmane.org; Thu, 14 Feb 2019 09:32:00 -0500 Original-Received: from eggs.gnu.org ([209.51.188.92]:41689) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1guHxg-0002Ru-Hr for emacs-devel@gnu.org; Thu, 14 Feb 2019 09:26:01 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1guHj9-0008Je-Sm for emacs-devel@gnu.org; Thu, 14 Feb 2019 09:11:01 -0500 Original-Received: from [195.159.176.226] (port=54994 helo=blaine.gmane.org) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1guHj9-0008CC-Jl for emacs-devel@gnu.org; Thu, 14 Feb 2019 09:10:59 -0500 Original-Received: from list by blaine.gmane.org with local (Exim 4.89) (envelope-from ) id 1guHj4-0003WJ-VZ for emacs-devel@gnu.org; Thu, 14 Feb 2019 15:10:54 +0100 X-Injected-Via-Gmane: http://gmane.org/ Cancel-Lock: sha1:1DTEX/D5jg2px64+cr41+FqrvxA= X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 195.159.176.226 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:233317 Archived-At: [ Beware: I haven't written more than 1 or 2 lines of Javascript in my life. ] > instance, Flycheck has to support all the different JavaScript modes > like this: > > :modes (js-mode js-jsx-mode js2-mode js2-jsx-mode js3-mode rjsx-mode) > > which seems messy to me. AFAIK all these should derive from js-mode (and flycheck should pay attention to parent modes), so `:modes (js-mode)` should cover them all without having to use something else than major modes. So this argument is really not convincing. > And what if we want to support more JavaScript syntax extensions, like > Facebook’s “Flow,” and support the use of multiple extensions > at once? This is a much more convincing argument. I don't know how those various extensions might interact (both in the Javascript code and in the js-mode support code), but it makes a lot of sense to try and make them modular, so you can mix&match. > Also, upon reflection, I’m becoming more certain that controlling > JavaScript indentation (even HTML-like indentation) with sgml- > variables was unintuitive and therefore also a mistake. 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. > * Deprecate js-jsx-mode (and js2-jsx-mode downstream, and have > rjsx-mode derive from js2-mode). Both modes will still exist, but > will be marked obsolete, and will simply make a file-local copy of > js-syntax-extensions (see below) with 'jsx added to the front of the > list, instead of binding indentation like they currently do. > * Deprecate js-jsx-indent-line, marking it obsolete. It will still > exist, but it will simply call through to js-indent-line, with a copy > of js-syntax-extensions let-bound, with 'jsx added to the front of > the list. Fine. > * js-mode will automatically detect whether a file uses JSX syntax > using some heuristic. Would there be any harm in activating JSX indentation&highlighting in a Javascript buffer that doesn't use JSX? In general, it sounds good. Just a nitpick about the syntax-propertize part of the patch (haven't looked at the rest, really): - You use the word "equality" in docstrings to refer to < and > chars, which to me aren't about equality. I think these are usually called "inequalities". It's obviously not too important (I figured it out in the end), but it got me confused for a little while. - Please use a "js--jsx-" or "js-jsx--" prefix for all the code that's related to JSX support (IOW all the code added for JSX support, or all the code that could be removed if JSX support were dropped). - 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? Doing it this way means that during execution of syntax-propertize-rules some of the syntax-table properties haven't been applied yet, so any call of syntax-ppss that happens during syntax-propertize-rules may get incorrect results (and more importantly will cache this incorrect result for later use). Stefan