From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Dmitry Gutov Newsgroups: gmane.emacs.bugs Subject: bug#68246: 30.0.50; Add non-TS mode as extra parent of TS modes Date: Fri, 19 Jan 2024 03:28:16 +0200 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> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="29236"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Mozilla Thunderbird 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: Stefan Monnier Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Fri Jan 19 02:29:25 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 1rQdhD-0007Rm-TJ for geb-bug-gnu-emacs@m.gmane-mx.org; Fri, 19 Jan 2024 02:29:24 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1rQdgs-0001Kb-Rn; Thu, 18 Jan 2024 20:29:03 -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 1rQdgr-0001KS-38 for bug-gnu-emacs@gnu.org; Thu, 18 Jan 2024 20:29: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 1rQdgq-0000WB-Rb for bug-gnu-emacs@gnu.org; Thu, 18 Jan 2024 20:29:00 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1rQdgs-00066u-FC for bug-gnu-emacs@gnu.org; Thu, 18 Jan 2024 20:29:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Dmitry Gutov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 19 Jan 2024 01:29: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.170562771123441 (code B ref 68246); Fri, 19 Jan 2024 01:29:02 +0000 Original-Received: (at 68246) by debbugs.gnu.org; 19 Jan 2024 01:28:31 +0000 Original-Received: from localhost ([127.0.0.1]:57042 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rQdgM-000660-8A for submit@debbugs.gnu.org; Thu, 18 Jan 2024 20:28:30 -0500 Original-Received: from out1-smtp.messagingengine.com ([66.111.4.25]:46745) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rQdgJ-00065m-BH for 68246@debbugs.gnu.org; Thu, 18 Jan 2024 20:28:28 -0500 Original-Received: from compute7.internal (compute7.nyi.internal [10.202.2.48]) by mailout.nyi.internal (Postfix) with ESMTP id 42F295C0078; Thu, 18 Jan 2024 20:28:20 -0500 (EST) Original-Received: from mailfrontend1 ([10.202.2.162]) by compute7.internal (MEProxy); Thu, 18 Jan 2024 20:28:20 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gutov.dev; h=cc :cc:content-transfer-encoding:content-type:content-type:date :date:from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:subject:subject:to:to; s=fm1; t=1705627700; x=1705714100; bh=USdfc+qfe5GM7Dc4guaWoh/tf/2JKmQL7CpCB6jAlrA=; b= rq9h2H32TMpj+n7vO0/vaCZcRWpLj+CPkAUUOMYrl2OAy0XtPP2ArdJ10BoCbM7L bhoOJvwJdp6UZ89VX73z/mgGaq3c52RjELuLJQC75VcJhy1arZrxysqf7rbdMvd0 ao8mlMjRKIQmQ1VnaeZGlZCCBUcBqy8jrtlIRnhSIavMPK7x3C1yBEMxDKOk3tLc gR0mZnDlPSCaSBk90c5allhUINZVPt8PfbFl9kqH2mZurlhil5u1pAE1vaEaGNku raMzD8MGStQAS49ZkX+LHBPY6+Ww27KGTOV5/60m4wzWJ8F+gmqxUUvYdN0ErdgD Bz1mUeE8KyonwyTz6ppstw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-transfer-encoding :content-type:content-type:date:date:feedback-id:feedback-id :from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:subject:subject:to:to:x-me-proxy:x-me-proxy :x-me-sender:x-me-sender:x-sasl-enc; s=fm3; t=1705627700; x= 1705714100; bh=USdfc+qfe5GM7Dc4guaWoh/tf/2JKmQL7CpCB6jAlrA=; b=Z k05GiNDSfZZ3S2dz15sqqM6mNPGUrA0DjjSnKaTYR6JElOqxbwcdTR42q5L4Zc+U BRBe9c8lo91uHaE3O3QoealZu9szVSc1cTODBdDyi++eLllQTp6HHXJNEYY/xUv2 p0GozSyfQCUhs8GIvgJ0LCGz7/IglEe9K7omtNeJLREbTR/CN5E0NNiRxQnF7ycS CmFBN9lLTLNGXPFMv4IoLfFgcJ+bBozPpMOGOwOl6y8adlCPGQ2z2Qezq5fwiH3d /Lx0724vS+9OJEwlbmXLilzd3SVDCwKpohp2QJDs6KLO46vzmSN9lDiRteDQvagq SvCPg+W9y0d2bgQiY3gFw== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvkedrvdejledgfeeiucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepkfffgggfuffvvehfhfgjtgfgsehtkeertddtvdejnecuhfhrohhmpeffmhhi thhrhicuifhuthhovhcuoegumhhithhrhiesghhuthhovhdruggvvheqnecuggftrfgrth htvghrnhepgeelfeetkefghfdvhfdtgeevveevteetgeetveegtedthefhudekteehffeu keeknecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepug hmihhtrhihsehguhhtohhvrdguvghv X-ME-Proxy: Feedback-ID: i0e71465a:Fastmail Original-Received: by mail.messagingengine.com (Postfix) with ESMTPA; Thu, 18 Jan 2024 20:28:17 -0500 (EST) Content-Language: en-US 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:278465 Archived-At: On 18/01/2024 23:24, Stefan Monnier wrote: >> 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 ⊂ application/xml ⊂ text/plain I meant to try to clarify your meaning when you said that content-types are to languages the same as what languages are to major modes. That might mean that a content-type corresponds to a number of languages, just like a language corresponds to a number (open set) of major modes. But I don't see how. Please enlighten. Speaking of the relation of inclusion, as I said before we might not want to make languages hierarchical (even though it might help for certain cases), because the relation might not be universal across uses. And if you had the idea of expressing it through major mode inheritance as well, it's likely to have adverse effects, something like: (derived-mode-add-parents 'c++-ts-mode 'c++-lang) + (derived-mode-add-parents 'c++-lang 'c-lang) = (provided-mode-derived-p 'c++-ts-mode 'c-lang) Which can lead some callers to decide that c++-ts-mode's language is C. >>>> 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)) >> 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. Okay. The side-effect of this approach is that we basically declare a mode's language twice: once in the attribute above, and once in the major-mode-remap-alist which is put into autoloads. But it's probably minor enough. And if languages are distinct from major modes in naming, the :language attribute in define-derived-mode could make it run the corresponding hook at the end. Which seems good. >>>> 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 have >> 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? In my picture that was just the natural conclusion. What I was trying to do, is put a level of control above the major modes - the mapping from languages to modes, and make it more easy to control and configurable. It didn't seem that the presence of a major mode was required to detect the expected language, hence the addition of the new values. At that point it seemed natural to both allow the absence of a configured major mode (why not), and to run the language hook anyway, for reliability. If we really don't need any of that, then the auto-mode-alist and the companion vars don't even have to change, and the only place where the language name could feature (aside from the code looking it up), is the mode definitions. >>>>> 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. >> 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 🙂 > Now `-mode` is again included in `derived-mode-all-parents` for > those new modes. If the language is called -lang instead (of without suffix), then the major mode could also run the language-specific hook, which in your patch it cannot do. > 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. I think I've included some thoughts on this subject in my previous email. They don't seem to be quoted/commented on here. >> 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. The latter feature (suggest which major modes to install) has come up recently. It's not that difficult to implement (with a whitelist of packages), and fundamental-mode is most likely *the* major mode which would be used until the suitable major mode is installed. >> 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. Okay, ODT. Which we can view with either doc-view-mode or xml-mode. Languages :doc or :xml. We configure one of these langauges to be used by default, and switch to another at will. Not sure it's useful to consider both modes somehow active at the same time. Although this example does underscore the problem of major modes needing to be able to specify/change the current language themselves. At least if we don't want such modes as doc-view to have to be rewritten. On the third hand, external tools (lsp servers, ripgrep, etc) will view such files as a certain type only - just ODT. Which might make us a disservice if the current detected language changes as we change the major mode. Hmm. And since xml-mode itself doesn't know ODT, it won't be able to "compute" that language value either (same would likely be true for other "container" modes). > 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. I think the "languages" feature seems to cover the same functionality as your patch, and then some. Although at the expense of the downstream callers having to use the new feature, rather than having things work "automagically" (as soon as they stop supporting Emacs 29.1, that is).