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 16:24:46 -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> <1a0802a1-7c25-4188-9984-f54b0e56ab5e@gutov.dev> Reply-To: Stefan Monnier 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="5416"; 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 22:26:13 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 1rQZtt-00019w-9t for geb-bug-gnu-emacs@m.gmane-mx.org; Thu, 18 Jan 2024 22:26:13 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1rQZti-0005h8-Pp; Thu, 18 Jan 2024 16:26:02 -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 1rQZtg-0005gy-RU for bug-gnu-emacs@gnu.org; Thu, 18 Jan 2024 16:26: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 1rQZtg-00036F-JE for bug-gnu-emacs@gnu.org; Thu, 18 Jan 2024 16:26:00 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1rQZth-0007Lj-Rd for bug-gnu-emacs@gnu.org; Thu, 18 Jan 2024 16:26:01 -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 21:26:01 +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.170561310428168 (code B ref 68246); Thu, 18 Jan 2024 21:26:01 +0000 Original-Received: (at 68246) by debbugs.gnu.org; 18 Jan 2024 21:25:04 +0000 Original-Received: from localhost ([127.0.0.1]:56851 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rQZsm-0007KF-0b for submit@debbugs.gnu.org; Thu, 18 Jan 2024 16:25:04 -0500 Original-Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:48982) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rQZsk-0007Je-2S for 68246@debbugs.gnu.org; Thu, 18 Jan 2024 16:25:02 -0500 Original-Received: from pmg1.iro.umontreal.ca (localhost.localdomain [127.0.0.1]) by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id 3BC3B10007D; Thu, 18 Jan 2024 16:24:53 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1705613087; bh=415vTDOJ6NCHmwDEkrEw/fOVND7qfzyM3TUPBbn9UFU=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=o+eFHQwMN7v9ODoiXfSGriJOLhscp+bnq+fPULCxSBZ9cAoHaq+unoUmC+ydOrAJQ K+pioDj6BgB39y+QgZ+JzCQjey6V8iE8mXeC/jZOeeGy9Nsw15cI3CHUloA7S7w0V2 bcf6zE6oWnuRCrKY1yDnkGN2MJ+gJnfxrF8FdIk5tS2u/GrPWfn4LOHplWFHhCQQva QDxbvhvps5C3eAC2R9q53cZ6h4PKsk9dNE3lx+nw4r/3+G8fto1uo5dc7quxqkwsw1 gNesHD0+k0B0n4i/JRAsd1T2DmXKX8KH3FZymGGNE9GquJtbeDSBr1qevUEjMi39Hj +VXChad7V2Yxg== Original-Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id 7BC2510001D; Thu, 18 Jan 2024 16:24:47 -0500 (EST) Original-Received: from alfajor (modemcable005.21-80-70.mc.videotron.ca [70.80.21.5]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 45DE7120224; Thu, 18 Jan 2024 16:24:47 -0500 (EST) In-Reply-To: <1a0802a1-7c25-4188-9984-f54b0e56ab5e@gutov.dev> (Dmitry Gutov's message of "Thu, 18 Jan 2024 21:55:34 +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:278456 Archived-At: > Still not sure how that would work. I mean, we could have content-type > like text/html or application/json, but neither splits into two > languages, really. Not sure what you mean by "split", but just as with major modes and "languages", MIME content-types have inclusion properties, such as application/atom+xml =E2=8A=82 application/xml =E2=8A=82 text/plain >>> OTOH, the major mode can only run the language hook, I think, if any ma= jor >>> mode can correspond only to one language. >> Not so. A major mode can easily do >> (run-mode-hooks (compute-the-hook)) > I guess that would mean that the language hook is not run automatically, > that each major mode would need explicit code to compute it and run. Not necessarily, e.g. you could specify the language to `define-derived-mode` with something like :language (compute-the-language) and then have `define-derived-mode` compute the hook name from that. This said, I suspect that generic major modes supporting many languages will not be very numerous (after all, that's the point of being generic, no?), so it should be OK if they have to do some things manually. >>> 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. > The major mode could compute which language it is for. But the algorithm > could be undecidable if the buffer is not visiting a file yet, doesn't ha= ve > an interpreter comment, etc. That's where the command set-buffer-language > was supposed to come in handy. That still doesn't justify the major mode relying on `set-auto-mode-0`. AFAICT you seem to want to standardize how the user controls the language of language-generic major modes. I'm not sure we need such a standard. Do we even have such a generic major mode yet? >>>> I'm not comfortable enshrining the "-ts-mode" convention here. >>> We can still go the "strict" approach, where when no language is assign= ed, >>> we don't try to guess it. >> I think the `-mode` heuristic is acceptable, because it's been >> *the* convention used in Emacs. > We are now getting a whole set of new modes for which this heuristic isn't > going to work Cue the patch I submitted when I open this bug report =F0=9F=99=82 Now `-mode` is again included in `derived-mode-all-parents` for those new modes. Admittedly, it doesn't fully give a solution to the problem of computing "the" language of a buffer. But that gets us back to one of my recent questions: beside Eglot, which other package needs that? Is "the" language always unique and always the same for all those packages? Is it really the only thing those packages need? In the case of Eglot, at least it doesn't seem to be the case: we don't just need the language, but also the name of the language server to use. And for some buffers there can be several applicable language servers, and they don't necessarily all accept the same language. So we need either the major mode to provide the name of the server, or a central database that maps from language/type/mode to server name. In both cases, adding the language info to the server name is a non-issue. And in neither case is it necessary to know "the" language in order to find the server. My patch makes the central database work better. > The major-mode could be fundamental-mode. If the language were to be > specifiable through settings external to major modes, we could still do > useful things while in fundamental-mode (e.g. do some useful editing with > Eglot, provided it supports indentation and completion), or suggest which > major modes to install from ELPA. I don't see the interest of using specifically `fundamental-mode` for that. In any case, this seems too hypothetical at this stage to have a good idea of what we'd need in such circumstances. > Would we really care that an xml file inside an archive is applied both > archive-subfile-mode and xml-mode dir-locals settings? No, I wasn't thinking of XML files inside archives, but about files which are both archives and something else (e.g. ODT). The same applies for most other "generic" data containers, like XML and JSON. > Perhaps dir-locals.el could get a syntax for specifying variables when > specific minor modes are enabled as well. Or we could do something like (defun derived-mode-p (modes) (provided-mode-derived-p (or (funcall major-mode-function) major-mode) modes) or (defun derived-mode-current-all-parents () (or (funcall major-mode-all-parents-function) (derived-mode-all-parents major-mode))) So your XML major mode can indicate that the current buffer is actually in `xml+atom-mode` (which is a child of `xml-mode`). Anyway, as I mentioned elsewhere, I think this discussion of "languages" is only tangentially related to my proposed patch. There is some overlap, but they serve different purposes, and they're not mutually exclusive. Stefan