GNU bug report logs - #68246
30.0.50; Add non-TS mode as extra parent of TS modes

Previous Next

Package: emacs;

Reported by: Stefan Monnier <monnier <at> iro.umontreal.ca>

Date: Thu, 4 Jan 2024 22:12:01 UTC

Severity: wishlist

Found in version 30.0.50

Done: Stefan Monnier <monnier <at> iro.umontreal.ca>

Bug is archived. No further changes may be made.

Full log


View this message in rfc822 format

From: João Távora <joaotavora <at> gmail.com>
To: Dmitry Gutov <dmitry <at> gutov.dev>
Cc: 68246 <at> debbugs.gnu.org, Eli Zaretskii <eliz <at> gnu.org>, Yuan Fu <casouri <at> gmail.com>, Stefan Monnier <monnier <at> iro.umontreal.ca>, Stefan Kangas <stefankangas <at> gmail.com>
Subject: bug#68246: 30.0.50; Add non-TS mode as extra parent of TS modes
Date: Tue, 16 Jan 2024 22:00:35 +0000
On Tue, Jan 16, 2024, 17:45 Dmitry Gutov <dmitry <at> gutov.dev> wrote:
>
> On 16/01/2024 12:34, João Távora wrote:
> > I see no real categorization or classification.  I just see
> > a many-to-one mapping of major modes to languages.
>
> It might even be many-to-many, at least in some cases.
>
> E.g. js-ts-mode being good for both :js and :jsx.

>
> Not sure how useful this -to-many relation is going to be in the above
> cases, but it's probably a good illustration of the possibility.

According to https://react.dev, jsx is a "JavaScript syntax
extension".  So it would seem JSX is a superset of JS.  If
js-ts-mode parses it perfectly, it could be called
jsx-ts-mode instead.

But does it? I see Emacs modes specific for jsx out there, I
suppose people use them for a reason.  There's also tsx-ts-mode
and typescript-ts-mode.

At the end of the day, a language is not so easy to define,
but it's not that problematic either, especially in the editor
(in the compiler, it's much more important).

The best sources are a standard, when it exists, but each iteration,
sometimes  each compiler is also its own language.  There's "GNU C",
"ANSI C", C17, C23.  All handled by the C modes we have and the best
way we have to designate this is just "C".  c++-mode also handles
this code by the way, probably flawlessly, and yet we don't say
c++-mode is for C and C++.

But if you want, I don't think there's any big problem
in making get-language-for-mode return a list, with
the most important likely language at the top.

I predict it'll be pretty rare, but I guess you could
have this (excuse the ugly CamelCase for demo purposes)

(setq auto-mode-alist '(("\\.js$" . :JavaScript)
                        ("\\.jsx$" . :JavaScriptReact)))

(setq m-m-remap-alist '((:JavaScript . js-ts-mode)
                        (:JavaScriptReact . js-ts-mode)))

And 'buffer-language' becomes more like:

(or buffer-overriding-language-keyword
    (with-current-buffer buffer (get-language-for-mode major-mode))
    (let (kw)
       (and buffer-file-name
            (keywordp
              (setq kw
                    ;; yes I know this needs regexps
                    (alist-get buffer-file-name auto-mode-alist)))
            kw))
    (consult-oracles)
    (error "Don't know what language this is, sorry"))

João




This bug report was last modified 1 year and 104 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.