emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Comprehensive JSX support in Emacs


From: Stefan Monnier
Subject: Re: Comprehensive JSX support in Emacs
Date: Thu, 14 Feb 2019 09:10:48 -0500
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux)

[ 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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]