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: Tue, 16 Jan 2024 04:09:07 +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> 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="1595"; 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 Tue Jan 16 03:10:51 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 1rPYuf-000AVz-Nf for geb-bug-gnu-emacs@m.gmane-mx.org; Tue, 16 Jan 2024 03:10:51 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1rPYu6-0003SU-Sh; Mon, 15 Jan 2024 21:10:15 -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 1rPYtu-0003Ru-Ua for bug-gnu-emacs@gnu.org; Mon, 15 Jan 2024 21:10: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 1rPYtu-0008BE-B2 for bug-gnu-emacs@gnu.org; Mon, 15 Jan 2024 21:10:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1rPYtu-0005fL-4W for bug-gnu-emacs@gnu.org; Mon, 15 Jan 2024 21:10: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: Tue, 16 Jan 2024 02:10: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.170537096021722 (code B ref 68246); Tue, 16 Jan 2024 02:10:02 +0000 Original-Received: (at 68246) by debbugs.gnu.org; 16 Jan 2024 02:09:20 +0000 Original-Received: from localhost ([127.0.0.1]:47342 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rPYtD-0005eI-F9 for submit@debbugs.gnu.org; Mon, 15 Jan 2024 21:09:19 -0500 Original-Received: from out5-smtp.messagingengine.com ([66.111.4.29]:56369) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rPYtA-0005e4-G9 for 68246@debbugs.gnu.org; Mon, 15 Jan 2024 21:09:17 -0500 Original-Received: from compute6.internal (compute6.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id 1CDE35C017D; Mon, 15 Jan 2024 21:09:11 -0500 (EST) Original-Received: from mailfrontend1 ([10.202.2.162]) by compute6.internal (MEProxy); Mon, 15 Jan 2024 21:09:11 -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=1705370951; x=1705457351; bh=hLSWlxDUg65lImz5NfsWs/HpZ4m93tvyzMcaCUE/5IU=; b= FINF/j8XTtwg2o8/PjNIbtBN6fNhMWLnMHji+FneUEBYLnsQ+xJZujCPvAx/0i5P qvzJWMxAS8FSOX9EH0fYtlAiQM4SicrhgOnW5PmcLINi20Ec4cWePpOE3WCxtHei 0k5q6imIgNpY4U/himFiy+bAboSJYAWCu2NrIEMqOtaaS6bAbLRygcZxR3BPFoam aRstjWntB+sYleTwhuVeROrAiJbtMPSMr8m87JR0Rm+Othr0Ch7V2v+iZtKe5+kp BNvKKifx683VYsnaM9Qe6NvTavowvDHFcdxQFz6gLkKWTc9WN3JihFqHut4prwXU 0dE2lIHCDhMY+/Fl7mRp2A== 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=1705370951; x= 1705457351; bh=hLSWlxDUg65lImz5NfsWs/HpZ4m93tvyzMcaCUE/5IU=; b=O 0seXYkolGGE12OTkZth4+Qy1h321z9hQHk5RubaTFj1O91WPq1UppW5r4voKYaAU K/IcLNZUcN/BQ14qaMmdCnp8xzLX0JNIolLwylNbUUH5PBh2Qk/6LoXBpVp8Fckp Y52unrjKDqs4qOjnn/ngSOBc3pqV2pFrbyRYenGoJGFRAgs03CgnWizCqYGZxoVB d8ZGKVsGbEMuoD/WdGsR5vIPLQYyLojfrgeXTc2ZNDIKzFvf4PVG4WKAyNIw0lM6 JJJt/XA0pbSAu6JPHnU8i+SkcEn3fM3bApdj6ZXPZhidr3DWkQy42peBGLfl/Vwa 54QfH9PMmPYTHVeGq7Log== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvkedrvdejvddggeegucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepkfffgggfuffvvehfhfgjtgfgsehtkeertddtvdejnecuhfhrohhmpeffmhhi thhrhicuifhuthhovhcuoegumhhithhrhiesghhuthhovhdruggvvheqnecuggftrfgrth htvghrnhepgeelfeetkefghfdvhfdtgeevveevteetgeetveegtedthefhudekteehffeu keeknecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepug hmihhtrhihsehguhhtohhvrdguvghv X-ME-Proxy: Feedback-ID: i0e71465a:Fastmail Original-Received: by mail.messagingengine.com (Postfix) with ESMTPA; Mon, 15 Jan 2024 21:09:09 -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:278313 Archived-At: On 16/01/2024 01:11, João Távora wrote: > On Mon, Jan 15, 2024 at 8:51 PM Dmitry Gutov wrote: > >>> 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, > > We could define them all in batch in a macro, that's not too bad. And > then let the existing fleshed out ones overwrite those definitions by > making sure to load them later. A keyword for define-derived-mode like (:base t)? That would work. > The main advantages of the foo-base-mode approach is that: > > * it is easily grokkable by everybody, as it is very simply based on > simple inheritance, which everybody knows already. > > * there's already a fair number of such modes in the tree. Agree. I guess the part I don't quite like is adding a lot more new -base- modes (we'll have to add one for every prog mode, at least), most of which would stay unused, but unlike hook variables, clutter the function namespace. > But I do like your patch better, it seems pretty useful to introduce the > language concept, as it solves this and more problems more cleanly. So > let's see where that goes. Great. >> 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. In most cases that would be harmless, but OTOH the callers would miss out on the opportunity to see that the language is nil and apply their own fallbacks right away. I don't have a real problem scenario in mind, though. Perhaps some commands that would act on the language of the current buffer might want to say "no language is associated", but could not with the "convenience" approach. >> 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). BTW, get-current-mode-for-language could be implemented in terms of set-buffer-language. >> 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).