From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= Newsgroups: gmane.emacs.bugs 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 Message-ID: References: <33f46561-7830-424d-bfee-ba3748f977e2@gutov.dev> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="25454"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 68246@debbugs.gnu.org, Eli Zaretskii , Yuan Fu , Stefan Monnier , Stefan Kangas To: Dmitry Gutov Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Wed Jan 17 11:32:52 2024 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1rQ3E3-0006Oj-TX for geb-bug-gnu-emacs@m.gmane-mx.org; Wed, 17 Jan 2024 11:32:52 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1rQ3DL-0001v4-LX; Wed, 17 Jan 2024 05:32:08 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1rQ3DF-0001tw-JG for bug-gnu-emacs@gnu.org; Wed, 17 Jan 2024 05:32:01 -0500 Original-Received: from debbugs.gnu.org ([2001:470:142:5::43]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1rQ3DF-0002zq-Af for bug-gnu-emacs@gnu.org; Wed, 17 Jan 2024 05:32:01 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1rQ3DG-00049j-5a for bug-gnu-emacs@gnu.org; Wed, 17 Jan 2024 05:32:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 17 Jan 2024 10:32:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 68246 X-GNU-PR-Package: emacs Original-Received: via spool by 68246-submit@debbugs.gnu.org id=B68246.170548752015967 (code B ref 68246); Wed, 17 Jan 2024 10:32:02 +0000 Original-Received: (at 68246) by debbugs.gnu.org; 17 Jan 2024 10:32:00 +0000 Original-Received: from localhost ([127.0.0.1]:50918 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rQ3DD-00049S-CE for submit@debbugs.gnu.org; Wed, 17 Jan 2024 05:31:59 -0500 Original-Received: from mail-lj1-x235.google.com ([2a00:1450:4864:20::235]:49471) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rQ3DC-00049D-1Q for 68246@debbugs.gnu.org; Wed, 17 Jan 2024 05:31:58 -0500 Original-Received: by mail-lj1-x235.google.com with SMTP id 38308e7fff4ca-2ccbc328744so131021571fa.3 for <68246@debbugs.gnu.org>; Wed, 17 Jan 2024 02:31:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1705487511; x=1706092311; darn=debbugs.gnu.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=iLJkmqzZE/WyYpk2wcp81AqEV2bnspaO061P80ZGbOM=; b=AorLhywfhdWgo7eN4SK3l2oz1lh/l5MTc6b/Cjpx7VphHqxFJEc1OyAeUVd21hipvE exXOiVWpxzeJ1ONg5tE6K5ttYCdiDPEuC8aUuKNKEvSb2EoKLwUCzrjNNQCvXHAto95z bkKRJGJU+UuZVxpzDXJsKyp4M99qzLx1TtxoQKSJrKjvp+WMTRFZ9w1Zd5Q+0FY2q+E/ TUjzKLbxKA+Io8VXbpm7kIqm4aikbRJUC65qclL6bH4K/2OrRgpsJFR4eQkyZg5VuSmD 6TKSFukaG5J47BXoGQyhqhvp/q3/w6Kkd/jZ409KpCidhkqZLEUOBK8Gwu9saBG/ckTJ 8pEQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1705487511; x=1706092311; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=iLJkmqzZE/WyYpk2wcp81AqEV2bnspaO061P80ZGbOM=; b=a2/oZuP0NCV8QZfAEeWPHiJIcnihm2+IeiIVdTaOLk7uJUztYFWpiV3TzN0uRuIdv7 XVRQGg6ojcCTF8iFUfSQbcdpYjOb2k0Y+ZLCoiR1QSgihadODa03t6sgUq61G68cVhip Fnm1KDiuHhxISrp9Ok43AiBTjSbIRiFzfgs7Lag5UqIG3sx57HIwrXyUa4VPZY/jzG7n gOjZ8KeB6oz/qSpOZFFT26zb7NlpidQ5rGLCX0HBx8pmTxzCA+jVBIj9tC2QMLcHXGav FpcuB+IQH8ASbyH54725CVJm4rAmKZHP/f/ZNqs0WB3znop8KRhiS0NdrcECd7koiJdP Y+Eg== X-Gm-Message-State: AOJu0YzMf4H/Yj14yp7vQLlQ40jCiZAXN6PgPgS6/iIdhNcOUEj4DZwl higtsnKsC2UD94M1mlnjj73illzjAQ9vAmwhF9E= X-Google-Smtp-Source: AGHT+IFUAguH3hyda+oQuyDAE4RQXrIxCtffwxH4G2HcQiIbtShUiUKp9PXWrTtPZhYmtyOEp+KoUTOV2G7B98i3HfY= X-Received: by 2002:a2e:824b:0:b0:2cd:13bf:78df with SMTP id j11-20020a2e824b000000b002cd13bf78dfmr4073315ljh.11.1705487510807; Wed, 17 Jan 2024 02:31:50 -0800 (PST) In-Reply-To: X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.bugs:278379 Archived-At: On Wed, Jan 17, 2024 at 2:06=E2=80=AFAM Dmitry Gutov wro= te: > > On 17/01/2024 00:00, Jo=C3=A3o T=C3=A1vora wrote: > > On Tue, Jan 16, 2024, 17:45 Dmitry Gutov wrote: > >> > >> On 16/01/2024 12:34, Jo=C3=A3o T=C3=A1vora 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=C3=A3o