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: Mon, 15 Jan 2024 22:51:32 +0200 Message-ID: References: <831qavvcbo.fsf@gnu.org> <83a5phskd5.fsf@gnu.org> <83h6joqz0t.fsf@gnu.org> <834jfoq86m.fsf@gnu.org> <831qarrbjx.fsf@gnu.org> <87a5p84nlh.fsf@gmail.com> <83edekfldq.fsf@gnu.org> 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="24677"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Mozilla Thunderbird Cc: 68246@debbugs.gnu.org, Eli Zaretskii , casouri@gmail.com, Stefan Kangas , monnier@iro.umontreal.ca To: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Mon Jan 15 21:52: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 1rPTwW-0006BK-G2 for geb-bug-gnu-emacs@m.gmane-mx.org; Mon, 15 Jan 2024 21:52:25 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1rPTwD-0001p4-P5; Mon, 15 Jan 2024 15:52: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 1rPTwB-0001oo-0Z for bug-gnu-emacs@gnu.org; Mon, 15 Jan 2024 15:52:03 -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 1rPTwA-0005o5-Lk for bug-gnu-emacs@gnu.org; Mon, 15 Jan 2024 15:52:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1rPTwA-00083e-DB for bug-gnu-emacs@gnu.org; Mon, 15 Jan 2024 15:52: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: Mon, 15 Jan 2024 20:52: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.170535190530945 (code B ref 68246); Mon, 15 Jan 2024 20:52:02 +0000 Original-Received: (at 68246) by debbugs.gnu.org; 15 Jan 2024 20:51:45 +0000 Original-Received: from localhost ([127.0.0.1]:47127 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rPTvs-000832-R6 for submit@debbugs.gnu.org; Mon, 15 Jan 2024 15:51:45 -0500 Original-Received: from wout3-smtp.messagingengine.com ([64.147.123.19]:47463) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rPTvq-00082o-HF for 68246@debbugs.gnu.org; Mon, 15 Jan 2024 15:51:43 -0500 Original-Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailout.west.internal (Postfix) with ESMTP id D96313200A91; Mon, 15 Jan 2024 15:51:35 -0500 (EST) Original-Received: from mailfrontend1 ([10.202.2.162]) by compute5.internal (MEProxy); Mon, 15 Jan 2024 15:51:36 -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=1705351895; x=1705438295; bh=2L9ZiGhm7W9CW/keZXLDJIvwlt+DIqMKzg44s3FXShY=; b= QlR4YqedBT/IHl29AYQAoVnQ/AStVzhrUzIMHHuMLboMij3RlQw/8ALMlZfQE5kF iwqKQVcfZsB5PmLfKBg4NP/TPF/qFWt/KiQA5LtiyYftDD6RRAQlOujVDko0rUcq q2TR4j2SaBx5QAvcs8/Bpoaw7JMIdY4g3m11O6SYRte42eWB8+d2HQnTjixZuHxj phyAcBkMqNhqo+1ZxusifVTLf9mnl4DGTS9XBnRRRuPAvFj4R1HuxfyTgIDZfge3 iCH34n5Z1J4/gRJuBtR53gyqxeXsua6jBHPFsWv1WjUsYUbiu01fG0B0euL41h4l NXkyb1N6oy5VE/jkTxQpZg== 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=1705351895; x= 1705438295; bh=2L9ZiGhm7W9CW/keZXLDJIvwlt+DIqMKzg44s3FXShY=; b=y t8PwCe4NlDLhnen++J4giIgetgMBjo21Tgfo77dQYrm4/dPN7HrIdpqvwqcS0Vx1 CieNKpsfsBV70tYnLe/KvdSgn5Nhcj+80HoiIp3A7FzaWyFbIc7m++6vEo9PIRx4 Z72HxNFmHmj6VsFf1VyqwqH7hqG6IW8y1YF+9/jbhCCJMMVb3wFaVi6DEATC/kDd /UymfDUrQXdBcLyUxf8/umWu1Gy+FLTnWxF74yv5m6Cu8rAGYBYp8/t76WNqg30K GKKZl68VadKFEYNu77Hz8EIdb6ZsnwsGCEBHnciTaU2AAxYxo/kegitwlf+hkJDy 5t9W1Co3mw72vYoPKt4vw== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvkedrvdejuddgudegfecutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmd enucfjughrpefkffggfgfuvfevfhfhjggtgfesthekredttddvjeenucfhrhhomhepffhm ihhtrhihucfiuhhtohhvuceoughmihhtrhihsehguhhtohhvrdguvghvqeenucggtffrrg htthgvrhhnpeegleefteekgffhvdfhtdegveevveetteegteevgeettdehhfdukeetheff ueekkeenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpe gumhhithhrhiesghhuthhovhdruggvvh X-ME-Proxy: Feedback-ID: i0e71465a:Fastmail Original-Received: by mail.messagingengine.com (Postfix) with ESMTPA; Mon, 15 Jan 2024 15:51:33 -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:278307 Archived-At: On 15/01/2024 17:27, João Távora wrote: > On Mon, Jan 15, 2024 at 2:10 AM Dmitry Gutov wrote: >> > >> It's not like we don't have an existing solution for this: if there are >> two different modes to configure, change the settings for both modes, or >> alter two hooks. Less magical and more verbose, but being explicit can >> be good. > > I don't think there's anything magical about a base mode. But I like your > solution too. As "magical", I meant the original patch for this report. I wouldn't mind the "base mode" approach, but I guess its still suffers from not being suitable for using with earlier Emacs versions. And every programming mode will have to come with -base-mode defined, otherwise we'll have to revisit this every time a new third-party -ts-mode appears. >> Here's a draft patch of how a "language" could work. It doesn't alter >> every entry, but it is backward compatible. > > I think something like this can work, yes. > > - (funcall (alist-get mode major-mode-remap-alist mode)) > + ;; XXX: When there's no mapping for `:', we could also > + ;; look for a function called `-mode'. > + (funcall (alist-get mode major-mode-remap-alist (if (keywordp mode) > + #'fundamental-mode > + mode))) > + (when (keywordp mode) ;Perhaps do that unconditionally. > + (run-hooks (intern (format "%s-language-hook" (buffer-language))))) > (unless (eq mode major-mode) > > Regarding the "XXX", this is basically the same questions in the > two headings, I think, which is whether to consider the in existing > -mode as language. I think we can do it yes. Eglot and other > packages [*] have been doing it for quite some time. It will fail very > rarely, only for major modes outside Emacs (like "tuareg-mode" for > Ocaml) and we can probably fix that in-tree. It's a choice between embedding the implicit logic here, or returning nil and allowing the callers to do their own fallbacks. I'm not sure, personally, which is the better. One might be convenient, but the other more strict, possibly leaning to fewer defects. This choice is coupled with the corresponding logic in 'buffer-language' (whether to keep the replace-regexp-in-string branch). > The only thing that leaves me some doubts is the 'set-buffer-language' > entry point. It's a new thing not strictly required. Normally the > databases are edited (via whatever means) and then the buffer is > reverted for a mode change. So I don't think we need to introduce > this user convenience just yet (though, like the other user conveniences > you have imagined, I'm not necessarily opposed to it). I was thinking of what would be required to make "language" a first-class entity, so that users could interact with them instead of major modes. To prove the validity of the feature. Because it's something that people do (I, at least): invoke the major mode to choose a different language/content-type for a buffer (one not visiting a file yet, perhaps). And if we have an abstraction over mmodes, it would make sense to use it. The interactive behavior of set-buffer-language seems to justify it, I think: when you try to enable a major mode, you get all the session's functions as completions. But 'M-x set-buffer-language TAB' gives you a neat and tidy list of known languages, it's a tangible improvement. > Also 'buffer-language' could be 'get-mode-language', so you don't > have to have an actual buffer handy to get this association. The > implementation would just be a reverse search in major-mode-remap-alist This makes it dependent on the major mode already being applied. Which is a valid strategy, but then it can't be used in the last two features from my list ("Further possible additions") - they're about the case when there is no major mode defined. > Other than that, I think the solution is workable. > > The other package [*] that does exactly the same thing as Eglot, and > invented it independently is markdown-mode: > > (defun markdown-get-lang-mode (lang) > "Return major mode that should be used for LANG. > LANG is a string, and the returned major mode is a symbol." > (cl-find-if > #'markdown--lang-mode-predicate > (nconc (list (cdr (assoc lang markdown-code-lang-modes)) > (cdr (assoc (downcase lang) markdown-code-lang-modes))) > (and (fboundp 'treesit-language-available-p) > (list (and (treesit-language-available-p (intern lang)) > (intern (concat lang "-ts-mode"))) > (and (treesit-language-available-p (intern > (downcase lang))) > (intern (concat (downcase lang) "-ts-mode"))))) > (list > (intern (concat lang "-mode")) > (intern (concat (downcase lang) "-mode")))))) > > It uses this to know what major-mode to use to fontify GitHub style > markdown code blocks (which have a little language cookie after the > three backticks). Like Eglot's similar code, I think it could be trivially > rewritten if something like your patch were in place. Yup, it could use the entries in major-mode-remap-alist. > Bug#68217 is also relevant here. Eglot calls into markdown-mode.el > to fontify LSP documentation snippets and sometimes the mode picked > by markdown-mode.el to do the fontification is not the same the user > is using for the buffer. It most clearly should be. So > get-language-for-mode and get-(preferred)-mode-for-language are two > evidently needed helpers. Are there specific uses for get-mode-for-language when there is no existing buffer? Hmm, I suppose it could be the better option when either the current buffer is not visiting a file (but you want to have code completion in it anyway), or the user switched to a different major mode explicitly, one that does not correspond to buffer-file-name in the current configuration. We could have both functions: buffer-language and get-language-for-mode ('get-mode-language'?). Or define one initially and add the other as needed.