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: Wed, 17 Jan 2024 05:45:34 +0200 Message-ID: References: <83edeww73j.fsf@gnu.org> <83o7dzvrmf.fsf@gnu.org> <838r53vlo5.fsf@gnu.org> <831qavvcbo.fsf@gnu.org> <83bk9wq9ho.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="29759"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Mozilla Thunderbird Cc: 68246@debbugs.gnu.org, Eli Zaretskii , casouri@gmail.com, joaotavora@gmail.com To: Stefan Monnier , Stefan Kangas Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Wed Jan 17 04:46:21 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 1rPwsd-0007Z5-CZ for geb-bug-gnu-emacs@m.gmane-mx.org; Wed, 17 Jan 2024 04:46:20 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1rPwsP-0003if-CO; Tue, 16 Jan 2024 22:46:05 -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 1rPwsL-0003hq-BY for bug-gnu-emacs@gnu.org; Tue, 16 Jan 2024 22:46: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 1rPwsL-0003ct-3Z for bug-gnu-emacs@gnu.org; Tue, 16 Jan 2024 22:46:01 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1rPwsL-0003NL-SI for bug-gnu-emacs@gnu.org; Tue, 16 Jan 2024 22:46:01 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Dmitry Gutov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 17 Jan 2024 03:46: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.170546314811681 (code B ref 68246); Wed, 17 Jan 2024 03:46:01 +0000 Original-Received: (at 68246) by debbugs.gnu.org; 17 Jan 2024 03:45:48 +0000 Original-Received: from localhost ([127.0.0.1]:50330 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rPws7-00031U-Js for submit@debbugs.gnu.org; Tue, 16 Jan 2024 22:45:48 -0500 Original-Received: from out4-smtp.messagingengine.com ([66.111.4.28]:34983) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rPws6-0002pa-0S for 68246@debbugs.gnu.org; Tue, 16 Jan 2024 22:45:46 -0500 Original-Received: from compute7.internal (compute7.nyi.internal [10.202.2.48]) by mailout.nyi.internal (Postfix) with ESMTP id 08AC55C008C; Tue, 16 Jan 2024 22:45:39 -0500 (EST) Original-Received: from mailfrontend1 ([10.202.2.162]) by compute7.internal (MEProxy); Tue, 16 Jan 2024 22:45:39 -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=1705463139; x=1705549539; bh=x0OxOnCC7oYQJYrT8fEn2eBeg59Bc3XEjZGkjUb0TAY=; b= TlRbu6Ui1xqGHXUpCFVSdqdVH3I5UHjPRmZxn9qeyCuwXc/kWzdfDnxCBf6WmQgB cHyZpy8elybi7/wFrdC9Gj4ciUjjY29FumMxIFTUUc/gjQNhIreUnXN8eMoLI2P2 LSvBpCsD+eNAohX3rbB9KXerkVWBvQutmRsHhwYHbPGpJ4ku9FT+NLdjWKWvViEO jZsWuUsvw2i0W4pgQLLCm1Pm9MF3O3y7N0SXmN0QRrsZAB6zD0VPSoUj6cKQNz1t hTGWicC9eNrdsyIWGUWg+hRUz2x0owcuo/VVcKz5nAk9XnXQJpSasOqqtBSfs6Jx 6DYTUNKVgVL5/OJI8P7wgA== 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=1705463139; x= 1705549539; bh=x0OxOnCC7oYQJYrT8fEn2eBeg59Bc3XEjZGkjUb0TAY=; b=e ZMZnMKXSWjxwT5H1Jau/w2+fTYFYa1ujj7T2B8TXtz1Y77KPAWH59JmrDhmksHD7 3Zk3kmXzY8kcABr0SWvF4wOALs4BKw+yZl10IwqjUMQ2t+vR6zi40jaIswwoe3gq 8gMuIdnxdoTfO/ALZRFPzRaVfSXEpOrfzON4qieXKRxVzZ47g4kPhfmICytp2h2K uAWctJgGQtn7Zi9iXRZmV2IBsbMeqLWSxkrKxewAXr6n1IfaJZ6Y0YkbTYNN4lP9 DnAOROC1zCfXhohZX+GdESou2khGvYkSFiSPcqUFYhAztiY8Hj6jS96HCQQMCFtV Z//K4TwLxqmhfWbdGfIpg== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvkedrvdejgedgieduucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepkfffgggfuffvvehfhfgjtgfgsehtjeertddtvdejnecuhfhrohhmpeffmhhi thhrhicuifhuthhovhcuoegumhhithhrhiesghhuthhovhdruggvvheqnecuggftrfgrth htvghrnhepteduleejgeehtefgheegjeekueehvdevieekueeftddvtdevfefhvdevgedu jeehnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepug hmihhtrhihsehguhhtohhvrdguvghv X-ME-Proxy: Feedback-ID: i0e71465a:Fastmail Original-Received: by mail.messagingengine.com (Postfix) with ESMTPA; Tue, 16 Jan 2024 22:45:36 -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:278374 Archived-At: On 16/01/2024 04:32, Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors wrote: >>> Please don't call it "language". That'd be confusing. LSP is about >>> programming languages, so "language" is natural there. But in Emacs, >>> a major mode is more general than that. For example, it is not >>> unthinkable to consider mail-mode to be the extra-parent of >>> message-mode (or vice versa) -- but what is the "language" in that >>> case? >> Isn't the language for such modes in this paradigm just the empty set? > > I'm not too worried about those cases, indeed. > I'm more worried about the taxonomy of languages. > We currently have the taxonomy of major modes, with which we're pretty > familiar, and we've had many years to learn about its downsides, > complexity, as well as how to deal with them, but for languages we're > only familiar with the easy cases, which makes us judge the idea in > a way that may prove naive. Some of us perhaps familiar with more cases than others. > IME, deciding what is the type of the content of a buffer is usually > trivial but with some notable caveats, such as XPM or Postscript files, > or "container formats" (like `.deb` or `.odt`, as well as things like > DocBook which can be considered either as their own format or as XML), Sounds like DocBook could be viewed using different major modes. I'm not sure whether they should be classified as different languages in general in such cases, but here is sounds like :doc_book vs :xml. > or "sublanguages" such as C being a subset of C++, or Javascript being > a subset of Typescript. And I suspect the info we need will not always > be quite the same. So far my understanding is that "languages" would not have a hierarchy - no relation of being a "subset" or etc, because different applications will likely need different relations between such languages. Or none at all, most of the time. When a major mode is suitable for a number of languages, it can be expressed externally, e.g. using several entries in major-mode-alist-alist. > So while there might be a good case to be made to add some API functions > to query the language/type(s) of a given buffer (I'm not sure we'd need > the language of a given major mode, OTOH), or to find the preferred > mode(s) for a given language/type, I think it's worthwhile to try and > tweak our major mode taxonomy because it is information we must have > and information we know we will always have, so we should strive to make > it as good as we can. > > It shouldn't make it any harder to add language/type API functionality. > On the contrary it should make it easier. > > [ As suggested elsewhere in this thread, we could even try and merge > those taxonomies, e.g. using extra parents of the form `LANG-lang`. ] Inserting an extra parent called LANG-lang could work to contain the (mode->lang) mapping, but only if we decide that a mode can correspond to only one language, or if we are not going to run the language hook in the mode function. But if we don't, the extra complexity seems not worth it: we'll need the lang->mode mapping somewhere else anyway. And looking there (in major-mode-remap-alist) we could fetch the reverse relation just as well. This also wouldn't bring any of the other features I enumerated together with my patch.