From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Stefan Monnier via "Bug reports for GNU Emacs, the Swiss army knife of text editors" Newsgroups: gmane.emacs.bugs Subject: bug#68246: 30.0.50; Add non-TS mode as extra parent of TS modes Date: Fri, 05 Jan 2024 18:51:41 -0500 Message-ID: References: <83edeww73j.fsf@gnu.org> <83o7dzvrmf.fsf@gnu.org> <838r53vlo5.fsf@gnu.org> <831qavvcbo.fsf@gnu.org> Reply-To: Stefan Monnier 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="12701"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Cc: 68246@debbugs.gnu.org, Eli Zaretskii , casouri@gmail.com 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 Sat Jan 06 00:52:22 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 1rLtzB-00037g-At for geb-bug-gnu-emacs@m.gmane-mx.org; Sat, 06 Jan 2024 00:52:21 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1rLtyr-0005X1-2t; Fri, 05 Jan 2024 18:52:01 -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 1rLtyn-0005WY-GJ for bug-gnu-emacs@gnu.org; Fri, 05 Jan 2024 18:51:58 -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 1rLtyn-0007Vk-7l for bug-gnu-emacs@gnu.org; Fri, 05 Jan 2024 18:51:57 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1rLtyr-00065h-PR for bug-gnu-emacs@gnu.org; Fri, 05 Jan 2024 18:52:01 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Stefan Monnier Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 05 Jan 2024 23:52: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.170449871623402 (code B ref 68246); Fri, 05 Jan 2024 23:52:01 +0000 Original-Received: (at 68246) by debbugs.gnu.org; 5 Jan 2024 23:51:56 +0000 Original-Received: from localhost ([127.0.0.1]:58141 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rLtym-00065O-6J for submit@debbugs.gnu.org; Fri, 05 Jan 2024 18:51:56 -0500 Original-Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:16858) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rLtyk-000659-6q for 68246@debbugs.gnu.org; Fri, 05 Jan 2024 18:51:54 -0500 Original-Received: from pmg1.iro.umontreal.ca (localhost.localdomain [127.0.0.1]) by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id 3F72510009E; Fri, 5 Jan 2024 18:51:44 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1704498703; bh=KDbcOCxvisRvg+sEh8aS0AO/6vuly3DBh1574Rp5dRQ=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=TtFGc6bRwwxx8y79HJfkvqN5Wm3TbvEuz71LYm+B5BRJPYtdqTEmV5gM9T3M0ddSD l7Ouvd4IHmbFDmkl0H0x/7OLYvsFLak2OKOu51a0noyuJu86rw7pnEI1ZSaQU6tk4R KTmx5nxZNc1sBW6WmrGJnghtjbnJUSUywR7wnN9HkGplB0YJQgFRntMXLqP07+RoPv tys3dq4y+Ybrgj4iCh1RrTkGj8pBC3Dsf+n9SLtxh2cypPzN+YajY2jpKJsJ7GoQS1 HSKI0sgfCddeVVZSAH22zqSKyOIdJ5WPdo3x+Wrt6HPIkaX7b1rIUfSKlFYmRyxulL I4Y+knf89/img== Original-Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id 10A49100068; Fri, 5 Jan 2024 18:51:43 -0500 (EST) Original-Received: from milanesa (65-110-221-238.cpe.pppoe.ca [65.110.221.238]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id C6391120C25; Fri, 5 Jan 2024 18:51:42 -0500 (EST) In-Reply-To: ("=?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?="'s message of "Fri, 5 Jan 2024 23:20:26 +0000") 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:277423 Archived-At: [ IMO, it would indeed be a good idea to try and write some abstraction layer so we can share more code between modes parsing with syntax-tables/tree-sitter/wisi/SMIE/younameit. It will also be very useful when tree-sitter goes the way of the dodo. But that's a difficult job, and with limited immediately-visible benefits to the end users. In the mean time, we're stuck with major modes that don't share much code. ] Whether it's worthwhile to have a `FOO-base-mode` or not depends on the specifics, but it's largely an implementation detail. More importantly it's not directly relevant to this here bug, because I want to say "FOO-ts-mode is a kind of mode for FOO, so it's a kind of FOO-mode". There are very few YASnippets for FOO-base-mode, instead they're all for FOO-mode. Similarly, Eglot doesn't have rules for FOO-base-mode, only for FOO-mode. That's why in my patch I add `python-mode` as an extra parent of `python-ts-mode` even though they both share `python-base-mode` as their parent. IOW, in my patch, I'm using `FOO-mode` not really as the name of a major mode, but rather as the name of a *file type*. I already mentioned this distinction in the bug-report where I introduced `major-mode-remap-alist`: Emacs usually conflates file-type and major-mode, which works great where there's only one major mode for a given file type, but less great where there are several alternatives. Stefan Jo=C3=A3o T=C3=A1vora [2024-01-05 23:20:26] wrote: > On Fri, Jan 5, 2024 at 6:57=E2=80=AFPM Eli Zaretskii wrote: > >> > Of course they do!! How else would electric-pair-mode have worked >> > for virtually every language for more than 10 years >> >> forward-sexp moves forward even when there are no parentheses or >> braces anywhere in sight. > > electric-pair-mode uses scan-sexps. Scan-sexps works perfectly to > navigate nested mixed delimiter structures of modes that are not Lisp, > otherwise e-p-m couldn't do it's auto-balancing job. > >> > Well the reason why e-p-m and these things work today for most ts >> > modes is because they are also _using_ the Lisp/C parser based on >> > syntax tables and syntax-propertize-function. >> >> That's because a language parser will not have any notion of a sexp, >> so it cannot help. > > As I am trying to explain, it doesn't have to be a "Lisp sexp". > It just has to be something that scan-sexps can navigate, and > scan-sexps works in all modes. I'd think that at least > with a good enough grammar it's perfectly possible to do > e.g. show-paren-mode with TreeSitter alone. And the way this > could work in Emacs is for TreeSitter to feed into scan-sexps. > >> > > I invite you to compare CC mode with c-ts-mode, and see for yourself >> > > how the common grounds are very small. It seems surprising at first >> > > sight, but once you look at the code, it is very clear. >> > >> > And this is mainly because CC mode is, well, rather corpulent software, >> > let's put it like that. This is why I wrote it makes sense to start >> > from scratch for this one. >> >> A discussion where you brush aside any argument that doesn't fit your >> theory is not a useful one. > > ? You write this precisely in the point where I _agree_ with you. > That's the really the opposite of brushing aside. > >> > But would some kind of c++-base-mode hurt in some way? Presuming Alan >> > allows it, of course. >> >> Feel free to suggest such a base mode. If it works and is helpful, we >> will install it. Frankly, I doubt you could come up with a useful >> base mode like that: the differences are too large. > > As I am trying to explain, even a one-line empty base mode is useful. > >> > > > At the very least, it seems a common hook would be useful, and tha= t's >> > > > what an empty foo-base-mode() would give. >> > > >> > > Where a base mode makes sense, sure. But even that causes problems, >> > > since the base mode leaves some stuff not set up. >> > >> > I don't follow. Can you give an example of a problem? >> >> Yes, look at python.el and sh-script.el. The base mode can only go so >> far, it must stop before it gets into the stuff that is really >> different between the TS and non-TS modes. > > Very well, we are violently agreeing. > >> This means that the >> base-mode hook will not see a mode that is ready for work, only its >> beginning. > > Correct. But a major-mode doesn't have to be "ready for work" (I presume > you mean ready for editing) for the hook to be useful. That hook would > be perfectly suitable for setting variables used by minor modes and other > things. (eglot-server-program, flymake-diagnostic-functions, company-bac= kends, > mode-line-format, etc etc) > For turning on minor modes (eglot-ensure, company-mode, yasnippet-minor-m= ode,) > For binding commands. > > And even without the hook the mere fact that foo-mode and foo-ts-mode > are derived from foo-base-mode according to derived-mode-p makes it > useful. > >> > In fact I'm happy to see exactly the strategy I suggested is already >> > done in ruby-mode.el and ruby-ts-mode.el. What problems are caused >> > by it? >> >> Some modes succeed in that, others don't. I guess it depends on the >> language grammar. > > I don't see the problem, really. Now I see that many mode "base modes" a= lready > exist. That's great! That's at least four simplifications to eglot.el's > eglot-server-programs (ruby, python, js and bash/sh). I'd be happy to > know of more if someone has a fuller list. > > And all the base mode definitions could well have settings for the > upcoming eglot-server-program. > >> > > and this various >> > > things that you'd want to do in a mode hook are impossible in the >> > > base-mode hook. >> > >> > I don't follow this part either. Can you give an example using, say >> > the existing ruby-base-mode. >> >> Again, look at the two examples I mentioned above. > > I couldn't see the problem in either python.el or sh-script.el. What > do you wish you could do in those base mode bodies on have the user > do in the base mode hooks which is impossible? > > Jo=C3=A3o