From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= 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 11:06:25 +0000 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" Content-Transfer-Encoding: quoted-printable Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="22682"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 68246@debbugs.gnu.org, Eli Zaretskii , casouri@gmail.com, Stefan Kangas , monnier@iro.umontreal.ca To: Dmitry Gutov Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Tue Jan 16 12:07:30 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 1rPhI1-0005er-UH for geb-bug-gnu-emacs@m.gmane-mx.org; Tue, 16 Jan 2024 12:07:30 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1rPhHg-00030v-Vs; Tue, 16 Jan 2024 06:07:09 -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 1rPhHa-0002xd-8p for bug-gnu-emacs@gnu.org; Tue, 16 Jan 2024 06:07: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 1rPhHZ-000205-WB for bug-gnu-emacs@gnu.org; Tue, 16 Jan 2024 06:07:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1rPhHZ-0007li-U4 for bug-gnu-emacs@gnu.org; Tue, 16 Jan 2024 06:07:01 -0500 X-Loop: help-debbugs@gnu.org Resent-From: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 16 Jan 2024 11:07: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.170540320629837 (code B ref 68246); Tue, 16 Jan 2024 11:07:01 +0000 Original-Received: (at 68246) by debbugs.gnu.org; 16 Jan 2024 11:06:46 +0000 Original-Received: from localhost ([127.0.0.1]:47897 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rPhHJ-0007lA-BJ for submit@debbugs.gnu.org; Tue, 16 Jan 2024 06:06:45 -0500 Original-Received: from mail-lj1-x22e.google.com ([2a00:1450:4864:20::22e]:53290) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rPhHH-0007ky-MR for 68246@debbugs.gnu.org; Tue, 16 Jan 2024 06:06:44 -0500 Original-Received: by mail-lj1-x22e.google.com with SMTP id 38308e7fff4ca-2cca5d81826so126494851fa.2 for <68246@debbugs.gnu.org>; Tue, 16 Jan 2024 03:06:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1705403197; x=1706007997; darn=debbugs.gnu.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=MuTJUMlazdn3QDK/TlSrLsXg8kiarmLbgii70UeVbxA=; b=WpcV20SnqxGr9yg3SVbVwXtqzrvIvftzZ1fV2ApvRiFNIM+enThqlaEfHO7g1Q4+4M G1bjRJfu+BE0KWPlB58/ms6rVdXK0lRj9QQH5EMkVefWmGO86B+TaCE+DJMN1nzxe1dA phO11ZQhNwG7rzXiaqD/aaTAnPGxjed7zqnRoMUnho87KaWlU/pIjZ3PMKixzAhxo1d2 kRKbD4UpAWFTx8ZmsUms2C464v89PA+oOQHApO1y345WPhDZ5aF/MtQYU5SXGbT5LQa2 fH2YujcWR56lmaeIQrXy/yzSwfPaXYJLr7bk7kbKwa9/Jl862r9gEAtzAXNzx4qnGKrW qLPg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1705403197; x=1706007997; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=MuTJUMlazdn3QDK/TlSrLsXg8kiarmLbgii70UeVbxA=; b=ZplHrp4EJ1JfxaDLf4QuvXmiCUxVbF3dkmb6B109rSEYK2Vka+0BlptgzTfyptGj7+ 8lpjrIkbeEbP0lvDRnrkSUQXSi8dBVT8wMEJsxPqrm7klpQ+ZIMVm5pj7Eb9DiNuDd0Z +N1nPA8slopnzHoPj+w3nVFvEx3lhOway0Z+U7mt0oaIW/LqWpxWmiA+zeeoy1SfEqaW NBTlNsZ23SLS+DnK2GPnAuYFAznLd8wMxd0/RV4/skQP/pfhG2R7O25GUOGeu/1erJpg /mT5RxAB6X/3kpFpF06vj3NIy3J982082b+xG1omRLWzgymRQjfc+saRoW6gjI2MXqiN R9Mw== X-Gm-Message-State: AOJu0YxUcrPMBd6uTzetQL2Rl/7eErF1xgOyYjsV5ztxlwXesNae5fMD Hb+lnLVhPA1FmW8E00Qkcg9nyadzMWaSUyeOO2A= X-Google-Smtp-Source: AGHT+IG5RpAT31hm3gAv4JM5qxzl/r/T+++c5vRfGOdbLb1LeHIvLkYMtqVHKfHwXmdqkuZhgmApm8Zs2slzWAhxPnM= X-Received: by 2002:a2e:8395:0:b0:2cd:5e2b:52e3 with SMTP id x21-20020a2e8395000000b002cd5e2b52e3mr3772711ljg.54.1705403196727; Tue, 16 Jan 2024 03:06:36 -0800 (PST) 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:278329 Archived-At: On Tue, Jan 16, 2024 at 2:09=E2=80=AFAM Dmitry Gutov wro= te: > > 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. I think that would just clash with the existing PARENT one (when would one of those bases _not_ be the parent). For base modes, I think the current approach is mostly fine. There's something we can do for the existing ones (and future ones) though, which is to explicitly mark them abstract somehow. > > 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. 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). > > But I do like your patch better, it seems pretty useful to introduce th= e > > 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-languag= e' > >> (whether to keep the replace-regexp-in-string branch). > > > > Yes. I think we should err on the side on convenience. What exactly a= re > > 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). 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. > 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. Neither do I, but I agree we should be as accurate as possible. > 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. For sure. > >> 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 summar= ize > > 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". > BTW, get-current-mode-for-language could be implemented in terms of > set-buffer-language. What does get-current-mode-for-language do exactly? > >> We could have both functions: buffer-language and get-language-for-mod= e > >> ('get-mode-language'?). Or define one initially and add the other as n= eeded. > > > > Yes. buffer-language isn't bad, it's a useful helper. But buffer-lang= uage > > 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")) ?