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 04:41:00 +0200 Message-ID: <4105c743-45d0-48a0-a8bb-1ab457b9a256@gutov.dev> 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> 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="5297"; 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 Wed Jan 17 03:42:26 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 1rPvsn-00019d-Kr for geb-bug-gnu-emacs@m.gmane-mx.org; Wed, 17 Jan 2024 03:42:26 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1rPvsS-0006xz-4J; Tue, 16 Jan 2024 21:42: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 1rPvsQ-0006xj-Fg for bug-gnu-emacs@gnu.org; Tue, 16 Jan 2024 21:42: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 1rPvsP-0002N8-K4 for bug-gnu-emacs@gnu.org; Tue, 16 Jan 2024 21:42:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1rPvsP-0005o2-SX for bug-gnu-emacs@gnu.org; Tue, 16 Jan 2024 21:42: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 02:42: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.170545927522242 (code B ref 68246); Wed, 17 Jan 2024 02:42:01 +0000 Original-Received: (at 68246) by debbugs.gnu.org; 17 Jan 2024 02:41:15 +0000 Original-Received: from localhost ([127.0.0.1]:50262 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rPvrb-0005md-SL for submit@debbugs.gnu.org; Tue, 16 Jan 2024 21:41:15 -0500 Original-Received: from out1-smtp.messagingengine.com ([66.111.4.25]:52739) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rPvra-0005mO-Gi for 68246@debbugs.gnu.org; Tue, 16 Jan 2024 21:41:11 -0500 Original-Received: from compute7.internal (compute7.nyi.internal [10.202.2.48]) by mailout.nyi.internal (Postfix) with ESMTP id 855635C00C7; Tue, 16 Jan 2024 21:41:04 -0500 (EST) Original-Received: from mailfrontend2 ([10.202.2.163]) by compute7.internal (MEProxy); Tue, 16 Jan 2024 21:41:04 -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=1705459264; x=1705545664; bh=7YYlokI3IpQ2hksg3zgDIxTnof7mXFfpkdTAieX63mU=; b= J3Oqcrycb/IhThM1KN7cefKd9IEILzgOlTzuCrBZWnVthX/ElccY2UwBj7yweJit +OvW1+cAiGC4/I2d7QX4gPtl5GIPjWhL03IGhBbgRXr614c6fLqAGDlBl3aF/1AK Xqdirv7hLT5ajMN/xMAW4a04hrqVFuHVTJ6l7VvCskQtK38e3HlfzKqJB1w6mTO3 NH9bwHRaK0gQ5FnuqdZzEpeH7WhsgMnwi6t9NL+tGO3YMFkXxfPqiAoTOHYyE2EL sRbeH7uhTAzFCuqeV4uk+f3yTV49GqiJfoRfyWLAtZfyWw+oh9reVbvMhuZhOmFr GKdqI1UfVOopwKHMxssmsg== 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=1705459264; x= 1705545664; bh=7YYlokI3IpQ2hksg3zgDIxTnof7mXFfpkdTAieX63mU=; b=P bH4YAbAVhbr9roywtlCHgqq4AGvAFQRXbpra3ffNkWd0u3pTqUpDo7WAPmGvVOEE /5OonHyAAadV7LesaU5jGL2Cr5reNPfK08CK1ILGjdjEkw9siisom6WEoFH2eBAe /b6iw2stSIaxfqyeyCrjvTOB4PT3Qy2TvpAE3CueMPQBnW5n2lmEJXsQamVY2qSY dkMAUQxsVmoen9nmuRho2Newms92hcuDny0MFb1zzzVfoYlCavW0q20IvInucZtT kY+ZExvt853jObfPXvxBQYeSrAcjAlwodES7zFEMJIYaZW8619TyannPG8toGkWF qCkZHB0QklvH3OUmtu43g== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvkedrvdejgedggeelucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepkfffgggfuffvvehfhfgjtgfgsehtkeertddtvdejnecuhfhrohhmpeffmhhi thhrhicuifhuthhovhcuoegumhhithhrhiesghhuthhovhdruggvvheqnecuggftrfgrth htvghrnhepgeelfeetkefghfdvhfdtgeevveevteetgeetveegtedthefhudekteehffeu keeknecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepug hmihhtrhihsehguhhtohhvrdguvghv X-ME-Proxy: Feedback-ID: i0e71465a:Fastmail Original-Received: by mail.messagingengine.com (Postfix) with ESMTPA; Tue, 16 Jan 2024 21:41:02 -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:278370 Archived-At: On 16/01/2024 13:06, João Távora wrote: > Agree. And this is why I'm not crazy about the solution either. But as > to cluttering the function namespace we could say that (:abstract t) modes > do _not_ generate a function (or do not generate them in the public > namespace -- as I think the function still has to exist for any > concrete submodes down the line to call it). An "abstract" mode is supposedly one that doesn't do anything. So it doesn't have to be callable. Anyway, that's +1 feature required for the implementation. >>>> This choice is coupled with the corresponding logic in 'buffer-language' >>>> (whether to keep the replace-regexp-in-string branch). >>> >>> Yes. I think we should err on the side on convenience. What exactly are >>> the defects can we get? I can't see anything else but the tuareg-mode, and we >>> can plug that on our side. Maybe you can see more. >> >> For example, it would sometimes return ugly non-existent languages like >> :help-fns--edit-value, :org-lint--report or :xref--xref-buffer. > > What if we filter by prog-mode? It would leave the ':ruby-base' and > ':python-base' as false positives, I guess. But then we could reasonably > say that anything ending with '-base' is abstract (or use the > aforementioned explicit abstract prop). We would also filter out :css, for example. TeX modes also do not derive from prog-mode. TeX does have an LSP server, however. > It would also make ':lisp-data' a language. But that's not bad. > lisp-data-mode is actually a useful concrete prog-mode derivative, > so I think it's OK to have ':lisp-data' as a language. > > We can then have exceptions for some notable cases. 'lisp-mode' is > as we know, for Common Lisp only. >>>> Are there specific uses for get-mode-for-language when there is no >>>> existing buffer? >>> >>> Yes, I'd say this markdown-mode use is exactly that. Markdown inserts >>> some text into a buffer and all it knows is the language it's supposed >>> to fontify it with. The major mode has that logic, so it must invoke >>> the correct (and preferred) major-mode function. >> >> Sorry, I meant get-language-for-mode (which is the one implemented as >> buffer-language currently). >> >>> Another use is allowing the user to choose major modes for languages, >>> say from a tutorial or wizard or at Emacs startup. Say, I prefer >>> ruby-ts-mode for Ruby, but c++-mode for C++. It'd be helpful to summarize >>> those preferences. >> >> This would require capabilities like "get all modes for a language" (not >> one of the set of functions mentioned so far, and it'll need a full scan >> of major-mode-remap-alist) and "get current mode for a language" (this >> one matches markdown-mode's function you posted). > > Yes. I don't see the full scan of m-m-remap-alist as problematic > from a effiency perspective. If we decide it's the database, it's > the database. It's unfortunate that the "alist" implementation is > hardcoded in the name (which is why I would prefer a (:language "Foo") > kwarg to define-derived-mode) but we can abstract the alist aspect > away with accessors and do the usual "Do not change this variable > directly, use these accessors instead". I'm not saying in advance that it will be slow. Just that it's a different function. >> BTW, get-current-mode-for-language could be implemented in terms of >> set-buffer-language. > > What does get-current-mode-for-language do exactly? The major-mode currently configured to be used for the language (through m-m-a-alist, in the current proposal). set-auto-mode will choose it. >>>> 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. >>> >>> Yes. buffer-language isn't bad, it's a useful helper. But buffer-language >>> should be just >>> >>> (with-current-buffer buffer (get-language-for-mode major-mode)) >>> >>> Right? Modulo some caching if it turns out to be very inneficient >>> (which I really doubt) >> >> Again: this won't work for files where no suitable major mode is >> available (e.g. not installed yet). > > Right. So maybe > > (or (with-current-buffer buffer (get-language-for-mode major-mode)) > (let (kw) > (and buffer-file-name > (keywordp (setq kw (alist-get buffer-file-name auto-mode-alist))) > kw)) > (consult-oracles) > (error "Don't know what language this is, sorry")) Replied to this one in another email: referring to the results of the computation of set-auto-mode is easier. But that's a technical detail.