From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii 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 20:56:27 +0200 Message-ID: <831qavvcbo.fsf@gnu.org> References: <83edeww73j.fsf@gnu.org> <83o7dzvrmf.fsf@gnu.org> <838r53vlo5.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="20045"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 68246@debbugs.gnu.org, casouri@gmail.com, 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 Fri Jan 05 19:58:13 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 1rLpOX-0004zw-P2 for geb-bug-gnu-emacs@m.gmane-mx.org; Fri, 05 Jan 2024 19:58:13 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1rLpOL-0007kI-Al; Fri, 05 Jan 2024 13:58: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 1rLpOI-0007fX-4R for bug-gnu-emacs@gnu.org; Fri, 05 Jan 2024 13:57: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 1rLpOH-0003NS-SZ for bug-gnu-emacs@gnu.org; Fri, 05 Jan 2024 13:57:57 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1rLpOM-0005iY-2Y for bug-gnu-emacs@gnu.org; Fri, 05 Jan 2024 13:58:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 05 Jan 2024 18:58: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.170448104021928 (code B ref 68246); Fri, 05 Jan 2024 18:58:02 +0000 Original-Received: (at 68246) by debbugs.gnu.org; 5 Jan 2024 18:57:20 +0000 Original-Received: from localhost ([127.0.0.1]:57913 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rLpNg-0005hc-2w for submit@debbugs.gnu.org; Fri, 05 Jan 2024 13:57:20 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:35108) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rLpNb-0005hL-Uo for 68246@debbugs.gnu.org; Fri, 05 Jan 2024 13:57:17 -0500 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1rLpNQ-0003IO-Li; Fri, 05 Jan 2024 13:57:05 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=MIME-version:References:Subject:In-Reply-To:To:From: Date; bh=Nfuta7OCB0iVKZc14IPs3edmpJI6DlGQcA9Mxeda9yA=; b=sKyCMlFTKn2y2BvwG8Zd aoS2stCeVBsDsIosgkqIyiYEA/mrkdh7bmEvXMJ+pHQaEwTWTBhqYBrhS5rgnUvp29APQgIFi57et rvC5rTSjSRsxF5rJkyV65MoZHkJaCACi17adDI5XLthyJdbmeBF8r9dNS4vL2zOzKHoJo11wcFM0z PMuCaqG0v8WPCLqBHS77ZP/kWpYjLXHs06fnZIXim0DtqaFDWhslLh0EOeBOhYKXTPWMl1D98M9Fw uBt8fIOCTqtP7pOvI5UTLLJVf5aNKXLgwvEKIZmZH3qBA89SZp7B+dHU8sCS08JdXLu5DdnawjVc4 HRtZ4ZNiLt7v4A==; In-Reply-To: (message from =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= on Fri, 5 Jan 2024 18:02:29 +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:277408 Archived-At: > From: João Távora > Date: Fri, 5 Jan 2024 18:02:29 +0000 > Cc: monnier@iro.umontreal.ca, 68246@debbugs.gnu.org > > > > Or consulting documentation. > > > > Again, only the mode's symbol is important. > > No. Say some consult-documentation minor-mode relies on > some setting of 'documentation-function'? I had info-look in mind. > > > Or anything we've built (including muscle memory) that lives on top > > > of syntactic abstractions like forward-sexp. > > > > Here you already bump into a problem, because most languages have no > > notion of "sexp", so making a TS mode do the same as a traditional > > mode is not easy at all. > > 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. > 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. > > 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. In Emacs we have to solve problems that happen in the messy real world, not problems in an ideal world where everything is according to some elegant theory. > 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. > > > At the very least, it seems a common hook would be useful, and that'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. This means that the base-mode hook will not see a mode that is ready for work, only its beginning. > 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. > > 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. > In summary, my position is that regardless of Stefan's patch, which > I'm not opposed to, we should: > > 1. Use add-derived-mode-parents sparingly and consider foo-base-mode when > possible. > > 2. have a remove-derived-mode-parent (for the other bug) > > 3. perhaps tighten up what we mean by derived-mode-p in the docs I have no opinion on that.