From: "João Távora" <joaotavora@gmail.com>
To: Dmitry Gutov <dmitry@gutov.dev>
Cc: 68246@debbugs.gnu.org, Eli Zaretskii <eliz@gnu.org>,
Yuan Fu <casouri@gmail.com>,
Stefan Monnier <monnier@iro.umontreal.ca>,
Stefan Kangas <stefankangas@gmail.com>
Subject: bug#68246: 30.0.50; Add non-TS mode as extra parent of TS modes
Date: Wed, 17 Jan 2024 10:31:39 +0000 [thread overview]
Message-ID: <CALDnm52ESc7aANH_TTJXg1cKuV2YkY4eq0x=zDyGH1bLfPRcBA@mail.gmail.com> (raw)
In-Reply-To: <e76909d6-bc1a-4a18-9f03-1b1ca6d0a9af@gutov.dev>
On Wed, Jan 17, 2024 at 2:06 AM Dmitry Gutov <dmitry@gutov.dev> wrote:
>
> On 17/01/2024 00:00, João Távora wrote:
> > On Tue, Jan 16, 2024, 17:45 Dmitry Gutov <dmitry@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.
>
> The grammar tree-sitter-js supports JSX. So the mode is called js-ts-mode.
OK. In this case, I would just say js-ts-mode is for JavaScript.
A future trivial js-tsx-mode would be for JavaScriptReact.
Eglot doesn't support the "JavaScriptReact" LSP language-id
because of this, and noone has complained (they have about ts and
tsx tho).
> tsx-ts-mode is probably okay for both :tsx, :jsx and :js but not
> :typescript (in general, because of certain clashing syntax).
Right. Which makes sense. Like my-c++-mode is "probably okay"
for C, but that doesn't mean my-c++-mode isn't the mode for the C++
language (or family of languages commonly denominated as "C++")
Ergo, as I see it, tsx-ts-mode is the mode for TypeScriptReact,
a language which happens to be a superset of some other languages.
> > 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.
>
> It would be a problem if we decide that the major mode function runs the
> language-specific hook, and not set-auto-mode-0 like in my patch
> (because the mmode function would like run the hooks for all supported
> languages, rather than just the current one).
I see. Right.
> > I predict it'll be pretty rare, but I guess you could
> > have this (excuse the ugly CamelCase for demo purposes)
>
> It might indeed be rare enough for this to be a problem, and we might
> even decide to prohibit such usage, keeping the relation many-to-one.
I'd think that is fine.
> > (setq auto-mode-alist '(("\\.js$" . :JavaScript)
> > ("\\.jsx$" . :JavaScriptReact)))
> >
> > (setq m-m-remap-alist '((:JavaScript . js-ts-mode)
> > (:JavaScriptReact . js-ts-mode)))
>
> It indeed should work okay with my proposal, but might be harder to do
> if the languages are inserted as part of the existing modes hierarchy
> (e.g. as "abstract" symbols).
I don't follow. Are you referencing the other mail? That
(:abstract t) idea was mostly crafted for the base-mode approach.
It's not strictly needed with your patch (though I don't see how
it hurts either).
> That is assuming we do want the language
> hook to run - which seems like important goal from my POV.
Not absolutely essential to fix current problems, but yes I agree
it's natural enough that it should be in the proposal.
> > 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)))
>
> There is a bunch of variables to look up: auto-mode-alist,
> magic-mode-alist, interpreter-mode-alist, magic-fallback-mode-alist. I
> didn't want to duplicate the logic from set-auto-mode, but this of
> course could be done.
I was just illustrating the fallback logic.
João
next prev parent reply other threads:[~2024-01-17 10:31 UTC|newest]
Thread overview: 146+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-01-04 22:11 bug#68246: 30.0.50; Add non-TS mode as extra parent of TS modes Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-01-04 23:02 ` João Távora
2024-01-04 23:05 ` Dmitry Gutov
2024-01-04 23:41 ` João Távora
2024-01-04 23:18 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-01-04 23:48 ` João Távora
2024-01-04 23:59 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-01-05 0:35 ` João Távora
2024-01-05 0:43 ` Yuan Fu
2024-01-05 7:51 ` Eli Zaretskii
2024-01-05 11:27 ` João Távora
2024-01-05 13:26 ` Eli Zaretskii
2024-01-05 15:16 ` João Távora
2024-01-05 15:34 ` Eli Zaretskii
2024-01-05 18:02 ` João Távora
2024-01-05 18:56 ` Eli Zaretskii
2024-01-05 23:20 ` João Távora
2024-01-05 23:51 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-01-06 0:16 ` João Távora
2024-01-06 4:08 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-01-06 14:36 ` João Távora
2024-01-06 15:50 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-01-06 22:22 ` João Távora
2024-01-07 6:55 ` Eli Zaretskii
2024-01-08 0:12 ` João Távora
2024-01-08 3:34 ` Eli Zaretskii
2024-01-08 10:50 ` João Távora
2024-01-08 13:13 ` Eli Zaretskii
2024-01-08 14:45 ` João Távora
2024-01-08 17:15 ` Eli Zaretskii
2024-01-14 2:19 ` Yuan Fu
2024-01-14 3:10 ` João Távora
2024-01-14 4:00 ` Yuan Fu
2024-01-14 7:02 ` Eli Zaretskii
2024-01-14 23:40 ` João Távora
2024-01-15 12:38 ` Eli Zaretskii
2024-01-15 14:45 ` João Távora
2024-01-15 15:00 ` Eli Zaretskii
2024-01-15 15:09 ` João Távora
2024-01-15 2:10 ` Dmitry Gutov
2024-01-15 12:46 ` Eli Zaretskii
2024-01-15 18:32 ` Dmitry Gutov
2024-01-15 18:52 ` Eli Zaretskii
2024-01-15 20:17 ` Dmitry Gutov
2024-01-15 20:27 ` Eli Zaretskii
2024-01-15 15:27 ` João Távora
2024-01-15 20:51 ` Dmitry Gutov
2024-01-15 23:11 ` João Távora
2024-01-16 2:09 ` Dmitry Gutov
2024-01-16 11:06 ` João Távora
2024-01-17 2:41 ` Dmitry Gutov
2024-01-17 10:20 ` João Távora
2024-01-18 0:47 ` Dmitry Gutov
2024-01-17 17:08 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-01-18 5:05 ` Dmitry Gutov
2024-01-18 14:17 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-01-18 19:55 ` Dmitry Gutov
2024-01-18 21:24 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-01-19 1:28 ` Dmitry Gutov
2024-01-19 12:43 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-01-19 12:53 ` João Távora
2024-01-19 13:19 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-01-19 14:01 ` João Távora
2024-01-19 18:05 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-01-19 22:47 ` João Távora
2024-01-20 7:03 ` Eli Zaretskii
2024-01-20 10:16 ` João Távora
2024-01-21 0:32 ` Yuan Fu
2024-01-21 9:54 ` Eli Zaretskii
2024-01-24 6:20 ` Yuan Fu
[not found] ` <jwvfrxt5e75.fsf-monnier+emacs@gnu.org>
[not found] ` <86v86ovp6j.fsf@gnu.org>
2024-03-09 15:39 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-01-20 5:43 ` Dmitry Gutov
2024-01-14 6:33 ` Eli Zaretskii
2024-01-14 23:18 ` João Távora
2024-01-15 12:35 ` Eli Zaretskii
2024-01-15 14:49 ` João Távora
2024-01-08 4:11 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-01-08 11:11 ` João Távora
2024-01-08 12:45 ` Eli Zaretskii
2024-01-08 18:57 ` Dmitry Gutov
2024-01-08 19:55 ` Eli Zaretskii
2024-01-08 20:06 ` Dmitry Gutov
2024-01-08 22:12 ` João Távora
2024-01-09 3:28 ` Eli Zaretskii
2024-01-08 19:18 ` Stefan Kangas
2024-01-08 19:57 ` Eli Zaretskii
2024-01-08 20:05 ` Dmitry Gutov
2024-01-09 3:27 ` Eli Zaretskii
2024-01-16 2:32 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-01-16 23:29 ` João Távora
2024-01-17 0:02 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-01-17 0:49 ` João Távora
2024-01-17 3:45 ` Dmitry Gutov
2024-01-19 5:12 ` Yuan Fu
2024-01-20 5:47 ` Dmitry Gutov
2024-01-20 7:46 ` Eli Zaretskii
2024-01-21 0:32 ` Dmitry Gutov
2024-01-08 19:04 ` Dmitry Gutov
2024-01-09 0:10 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-01-09 0:39 ` João Távora
2024-01-09 0:52 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-01-09 1:05 ` João Távora
2024-01-09 1:04 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-01-09 1:11 ` João Távora
2024-01-09 3:49 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-01-09 10:52 ` João Távora
2024-01-10 1:18 ` Dmitry Gutov
2024-01-10 16:11 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-01-11 3:41 ` Dmitry Gutov
2024-01-09 4:49 ` Stefan Kangas
2024-01-09 7:24 ` Kévin Le Gouguec
2024-01-09 1:09 ` Dmitry Gutov
2024-01-09 1:31 ` João Távora
2024-01-09 3:55 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-01-09 11:05 ` João Távora
2024-01-10 1:15 ` Dmitry Gutov
2024-01-10 1:59 ` João Távora
2024-01-10 16:04 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-01-10 17:02 ` Dmitry Gutov
2024-01-10 17:31 ` João Távora
2024-01-10 1:41 ` Dmitry Gutov
2024-01-10 6:24 ` Stefan Kangas
2024-01-10 15:51 ` João Távora
2024-01-11 3:49 ` Dmitry Gutov
2024-01-16 2:35 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-01-16 10:34 ` João Távora
2024-01-16 17:45 ` Dmitry Gutov
2024-01-16 22:00 ` João Távora
2024-01-17 2:05 ` Dmitry Gutov
2024-01-17 10:31 ` João Távora [this message]
2024-01-17 23:37 ` Dmitry Gutov
2024-01-06 8:12 ` Eli Zaretskii
2024-01-06 8:07 ` Eli Zaretskii
2024-01-06 13:52 ` João Távora
2024-01-05 19:03 ` Stefan Kangas
2024-01-05 23:37 ` João Távora
2024-01-06 8:09 ` Eli Zaretskii
2024-01-06 3:19 ` Yuan Fu
2024-01-06 3:36 ` Dmitry Gutov
2024-01-06 4:16 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-01-07 6:59 ` Yuan Fu
2024-01-06 14:54 ` João Távora
2024-01-08 18:16 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-01-05 7:40 ` Eli Zaretskii
2024-01-05 18:43 ` Stefan Kangas
2024-01-05 19:11 ` Stefan Kangas
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CALDnm52ESc7aANH_TTJXg1cKuV2YkY4eq0x=zDyGH1bLfPRcBA@mail.gmail.com' \
--to=joaotavora@gmail.com \
--cc=68246@debbugs.gnu.org \
--cc=casouri@gmail.com \
--cc=dmitry@gutov.dev \
--cc=eliz@gnu.org \
--cc=monnier@iro.umontreal.ca \
--cc=stefankangas@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).