From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Stefan Monnier via "Bug reports for GNU Emacs, the Swiss army knife of text editors" Newsgroups: gmane.emacs.bugs Subject: bug#68246: 30.0.50; Add non-TS mode as extra parent of TS modes Date: Thu, 18 Jan 2024 09:17:15 -0500 Message-ID: References: <83a5phskd5.fsf@gnu.org> <83h6joqz0t.fsf@gnu.org> <834jfoq86m.fsf@gnu.org> <831qarrbjx.fsf@gnu.org> <87a5p84nlh.fsf@gmail.com> <83edekfldq.fsf@gnu.org> <8e6935bc-2a60-4a14-8e63-d6057a7e2af7@gutov.dev> Reply-To: Stefan Monnier Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="26715"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Cc: 68246@debbugs.gnu.org, Eli Zaretskii , casouri@gmail.com, =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= , Stefan Kangas To: Dmitry Gutov Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Thu Jan 18 15:18:24 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 1rQTDr-0006fg-C6 for geb-bug-gnu-emacs@m.gmane-mx.org; Thu, 18 Jan 2024 15:18:23 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1rQTDY-0005wS-J3; Thu, 18 Jan 2024 09:18:04 -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 1rQTDW-0005w5-6Q for bug-gnu-emacs@gnu.org; Thu, 18 Jan 2024 09:18:02 -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 1rQTDV-0004Gz-UZ for bug-gnu-emacs@gnu.org; Thu, 18 Jan 2024 09:18:01 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1rQTDW-0003xF-I9 for bug-gnu-emacs@gnu.org; Thu, 18 Jan 2024 09:18:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Stefan Monnier Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 18 Jan 2024 14:18: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.170558745915171 (code B ref 68246); Thu, 18 Jan 2024 14:18:02 +0000 Original-Received: (at 68246) by debbugs.gnu.org; 18 Jan 2024 14:17:39 +0000 Original-Received: from localhost ([127.0.0.1]:54586 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rQTD8-0003wc-4U for submit@debbugs.gnu.org; Thu, 18 Jan 2024 09:17:39 -0500 Original-Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:36050) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rQTD2-0003wK-Pf for 68246@debbugs.gnu.org; Thu, 18 Jan 2024 09:17:36 -0500 Original-Received: from pmg3.iro.umontreal.ca (localhost [127.0.0.1]) by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id 09A5A444184; Thu, 18 Jan 2024 09:17:24 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1705587441; bh=cqmEuhVpX4uYkFYRPGqj9LAqBW1MxphIYjfKuBCGeXM=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=jVDlx/gDPKtKtkwLbLQNDbCmIYHgg1cCYWPirc2Hy/pibtS+UAusshVSuDhmW+ZcY DW1Oy6csiKrBsUbJNw3pG84Qcnp8C/FJ6onGHgLnmfImBaTut+bJ8u7vKQPJJewOSm 0dhgVXo2fMoOutn0mNSa9TO7w0ZKM2UY1nOdbe+naeC4A6UUlCZ/ulJtMUH7ITy/DJ iMMdeLRT3EJzIp8UiG3LcM8UYyPlMctQPW5eOrgGjPdyoi0lUlE9AdnRq1MHt/r9i2 iiYk5j4np/u2/pWcWzKnIuCcZ/4N3G5CSKkpW3kWXR0s2u0aYrC17kHC8RFxMD5IMb W8Npu9qttR/TA== Original-Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id DB5D4444180; Thu, 18 Jan 2024 09:17:21 -0500 (EST) Original-Received: from pastel (unknown [45.72.229.100]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id A0CDC120470; Thu, 18 Jan 2024 09:17:21 -0500 (EST) In-Reply-To: <8e6935bc-2a60-4a14-8e63-d6057a7e2af7@gutov.dev> (Dmitry Gutov's message of "Thu, 18 Jan 2024 07:05:55 +0200") 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:278433 Archived-At: > away). The language-specific version of major-mode-remap-alist looks > necessary after all. It doesn't have to be specifically about languages. It can just be a "default" set of "major mode" remappings. >>> @@ -3206,10 +3209,10 @@ interpreter-mode-alist >>> ("emacs" . emacs-lisp-mode))) >>> "Alist mapping interpreter names to major modes. >>> This is used for files whose first lines match `auto-mode-interpreter-regexp'. >>> -Each element looks like (REGEXP . MODE). >>> +Each element looks like (REGEXP . MODE-OR-LANGUAGE). >>> If REGEXP matches the entire name (minus any directory part) of >>> the interpreter specified in the first line of a script, enable >>> -major mode MODE. >>> +MODE-OR-LANGUAGE. >> There's a similar need for "content type" rather than "language". If we >> want to mention "language" we should also take the opportunity to >> mention other related categorizations like "content type". > Are "content type" and "language" going to be different things? > They seem the same to me. I think there's the same kind of difference between "language" and "content type" as between "language" and "major mode" :-) > OTOH, the major mode can only run the language hook, I think, if any major > mode can correspond only to one language. Not so. A major mode can easily do (run-mode-hooks (compute-the-hook)) > Though I suppose if set-auto-mode-0 saves the currently "detected" > language somewhere, the major mode definitions could pick it up and > call the corresponding hook. Major modes are not activated solely via `set-auto-mode-0`, so relying on that is a crutch/hack, not something on which to base a design. >> I'm not comfortable enshrining the "-ts-mode" convention here. > We can still go the "strict" approach, where when no language is assigned, > we don't try to guess it. I think the `-mode` heuristic is acceptable, because it's been *the* convention used in Emacs. >> Also I think if we want a `buffer-language` function, it should not rely >> on how the mode was installed (e.g. `set-auto-mode--last`) but only on >> the major mode itself, i.e. something like >> (defun buffer-language () >> (or buffer-language > Where would the buffer-language variable be set, if not inside > set-auto-mode-*? In the major mode? >> (some heuristic based on major-mode and/or derived-modes))) > If we're sure we don't want several languages to be able to refer to the > same major mode... A major mode can (setq major-mode ...) If/when such "generic" major modes become a thing, and the `(setq major-mode ...)` hack becomes too inconvenient, we can devise a better solution (e.g. extending/tweaking the way `derived-mode-*` work). >> [ Of course, I already mentioned that I also suspect that there can/will >> be sometimes several languages (or none). ] > I'm not clear on this. You mentioned complex cases - like an xml inside an > archive? But depending on the usage, only one of the languages might be > "active" at a given time. But depending on what "the language/type/mode" is used for, we may not care really about which language/type/mode is "active" but about which languages/types/modes are applicable (e.g. for `.dir-locals.el`). >>> +(defun set-buffer-language (language) >>> + "Set the language of the current buffer. >>> +And switch the major mode appropriately." >>> + (interactive >>> + (list (let* ((ct (mapcan >>> + (lambda (pair) (and (keywordp (car pair)) >>> + (list (symbol-name (car pair))))) >>> + major-mode-remap-alist)) >>> + (lang (completing-read "Language: " ct))) >>> + (and lang (intern lang))))) >>> + (set-auto-mode-0 language)) >> I see several issues with this function (name and implementation), but >> I wonder when we'd ever need such a thing. > > It seemed like a missed opportunity not to provide a more high-level command > to switch to a specific language for the buffer. E.g. how we sometimes use > 'M-x foo-major-mode' when a file type's been misdetected, or the buffer is > non-file-visiting (perhaps very temporary). > > A command which does this with exhaustive completion across the configured > languages seems handy. At least that's my impression from briefly testing > it out. We can do the same with major modes, of course (just `mapatom` and filter out the non-major modes), so feel free to add such a command, but it doesn't seem like offering it for "languages" is particularly more useful than offering it for "major modes". > Also, get-current-mode-for-language can be implemented in terms of > set-buffer-language (see my earlier email to Joao). That seems to be a roundabout way to go about it. `get-current-mode-for-language/type/mode` should be used by `set-auto-mode` rather than other way around, no? > -mode is lexically indistinguishable from -mode. If we used > the names like -lang, at least one could tell whether one of the > parents of a given -mode is a language. Other than for Eglot, where does this distinction matter? >> Another issue I see if we don't use something like >> `derived-mode-add-parents` is that all the various places where we use >> mode-indexing, such as `.dir-locals.el`, `ffap`, YASnippet, etc... will >> need to be extended with a way to use "languages" as well, and then we >> also need to define a sane precedence between settings that apply to >> a given mode and settings that apply to a given language (setting for >> `js-ts-mode` should presumably take precedence over settings for >> `:js` which should take precedence over settings for `prog-mode`). > That's a good point: if "languages" as a separate notion gets added, it > would make sense to use them in more places (not 100% necessary, but good > for consistency). With the associated complexity that you mention. And if it's not merged into the same hierarchy as major modes, how do you get `:js` (i.e. "language") to be sometimes higher-precedence and sometimes lower precedence than a mode? Stefan