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: Sat, 06 Jan 2024 10:07:09 +0200 Message-ID: <83v886ubpu.fsf@gnu.org> References: <83edeww73j.fsf@gnu.org> <83o7dzvrmf.fsf@gnu.org> <838r53vlo5.fsf@gnu.org> <831qavvcbo.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="1529"; 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 Sat Jan 06 09:08:25 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 1rM1jE-000094-5O for geb-bug-gnu-emacs@m.gmane-mx.org; Sat, 06 Jan 2024 09:08:24 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1rM1ip-00088j-Ch; Sat, 06 Jan 2024 03:07:59 -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 1rM1in-00087V-TR for bug-gnu-emacs@gnu.org; Sat, 06 Jan 2024 03:07:57 -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 1rM1in-0005VW-LL for bug-gnu-emacs@gnu.org; Sat, 06 Jan 2024 03:07:57 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1rM1ir-0003qn-V6 for bug-gnu-emacs@gnu.org; Sat, 06 Jan 2024 03:08:01 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 06 Jan 2024 08:08: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.170452847114783 (code B ref 68246); Sat, 06 Jan 2024 08:08:01 +0000 Original-Received: (at 68246) by debbugs.gnu.org; 6 Jan 2024 08:07:51 +0000 Original-Received: from localhost ([127.0.0.1]:58496 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rM1ig-0003qM-MA for submit@debbugs.gnu.org; Sat, 06 Jan 2024 03:07:51 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:43604) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rM1ie-0003q8-AM for 68246@debbugs.gnu.org; Sat, 06 Jan 2024 03:07:49 -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 1rM1iT-0005TU-VE; Sat, 06 Jan 2024 03:07:37 -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=ETOj8mZ5qPE6Tb1v4sz8TdlYfH1ubDYKrklzprESquw=; b=IlaCKgDWJ+QH1u8G8Rg2 MAMcSV6qEaqlE061FlEWhj7LFR5hGndJ5U5W3GM7IzZb3cy3k3cc9mkike9y7fcBAnaL8BIlUov8M kB/MQcdoITbkEeoPCbjRA7k2KGLw3ztbvV8KVu3vhuMQbF+qHjMl2blyO8KPYRrTu7FxwmWz6iEEX G5B58BwmRunp/NtS1ijzTZMB3CBfcTCAxKAGD1usXXa1tQZs6Z4+kM6bFGc2sK16DyIxXla6Czq4+ UYIuw/9NmGpbeQyIOnN+6Owd6Bty/0UfT8dnZ0wM2AM/7NOmit3v0f0K5JAcpJZBqI8GzY0BVDOma 0Sn7mhkF1uPUKQ==; In-Reply-To: (message from =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= on 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:277433 Archived-At: > From: João Távora > Date: Fri, 5 Jan 2024 23:20:26 +0000 > Cc: casouri@gmail.com, monnier@iro.umontreal.ca, 68246@debbugs.gnu.org > > On Fri, Jan 5, 2024 at 6:57 PM 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. You are thinking about forward-sexp and scan-sexps in the situations where you start from a parenthesis. But scan-sexps, like forward-sexp, handles situations where the "sexp" is not a balanced parenthesized expression. It uses syntax tables that in the case where you start not from a paren yield ad-hoc results whose relation to "sexps" is arbitrary. Therefore, doing something similar with results of parsing the source code will always produce arbitrary results that are different, and make as little sense as what forward-sexp does. There was a discussion not long ago how to define a "sexp" in TS-based modes so that it would make sense. You can see there that the conclusions are not self-evident. But we digress. My point in talking about sexps was that basing it on syntax tables (like we do in traditional modes) will produce different results than if we base them on TS parsers. If you still disagree, let's agree to disagree, because I already explained this twice at least. > > > 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. scan-sexps is not using the results of parsing by TS, so it doesn't really understand the structure of the source code, and in particular cannot provide reasonable movements by portions of expressions in at least some languages. Again, if you disagree, let's agree to disagree. > 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. Why do you think so? Does a TS parser produce any information about matching parens/braces, let alone characters like <> etc? > And the way this could work in Emacs is for TreeSitter to feed into > scan-sexps. I'm not sure I understand how TS could feed scan-sexps. Did you look at the implementation of scan-sexps? AFAICT, there's no way to base the code there on TS, except by providing a completely different implementation (assuming TS parsers even provide the required information). > > > > 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. You "agree" for the wrong reasons. You are, in fact, claiming that the CC mode cannot be an example of a problem because of unrelated reasons. I'm saying that the reasons are related. > > 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-backends, > mode-line-format, etc etc) > For turning on minor modes (eglot-ensure, company-mode, yasnippet-minor-mode,) > For binding commands. Stefan's patch solves these cases in a simpler manner. > 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. Stefan's patch solves this in a simpler manner. > > > > 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. Search for bugs in those two files, and you will see the issues that I had in mind.