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#62238: 30.0.50; Unusual interpretation of "S-expressions" in c-ts-mode Date: Sat, 18 Mar 2023 19:27:45 +0200 Message-ID: <83fsa2as1a.fsf@gnu.org> References: <87ilezg0wo.fsf@posteo.net> <7FDC4392-AC34-4EA2-A166-AB10755361CD@gmail.com> <83jzzeb2v6.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="37867"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 62238@debbugs.gnu.org, casouri@gmail.com, theo@thornhill.no, philipk@posteo.net To: Daniel =?UTF-8?Q?Mart=C3=ADn?= Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Sat Mar 18 18:28:25 2023 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 1pdaLv-0009Z6-3J for geb-bug-gnu-emacs@m.gmane-mx.org; Sat, 18 Mar 2023 18:28:23 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1pdaLb-0001Wv-OR; Sat, 18 Mar 2023 13:28:03 -0400 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 1pdaLa-0001Wh-LB for bug-gnu-emacs@gnu.org; Sat, 18 Mar 2023 13:28:02 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1pdaLa-0004nl-Ce for bug-gnu-emacs@gnu.org; Sat, 18 Mar 2023 13:28:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1pdaLa-0001tH-5j for bug-gnu-emacs@gnu.org; Sat, 18 Mar 2023 13:28:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 18 Mar 2023 17:28:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 62238 X-GNU-PR-Package: emacs Original-Received: via spool by 62238-submit@debbugs.gnu.org id=B62238.16791604727244 (code B ref 62238); Sat, 18 Mar 2023 17:28:02 +0000 Original-Received: (at 62238) by debbugs.gnu.org; 18 Mar 2023 17:27:52 +0000 Original-Received: from localhost ([127.0.0.1]:48980 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pdaLP-0001sm-Vt for submit@debbugs.gnu.org; Sat, 18 Mar 2023 13:27:52 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:43822) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pdaLN-0001sW-W3 for 62238@debbugs.gnu.org; Sat, 18 Mar 2023 13:27:50 -0400 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 1pdaLH-0004l4-4F; Sat, 18 Mar 2023 13:27:43 -0400 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=PRmNjOURkRK5pUBzjPLK0V0i47AUOxLa5uAxDW2Rvs8=; b=DzCWxlAbBsrSHbzjIrLN m6Bqvb8BTlpsP8Bu/426EA3SIPxdgUOdCRY88+3Q9d8HUvDTlNc892XDXAiC+6YbnESqIGX1/wL4K 2yWWM5J5LqO0ngD5gX5Z/x8cPNaAPK0K6Klu1u/bOv2xxltPgQbjs/SaEWwbOq6mJxgQqQ11tbciw P2wbf+3aVJDDE7CG08gNq/q1VgqWDHIMw9X5Et+Fb9q/vU1xEoL73sJMKUSQRsjNl2tUrcRP8jwgm 3/CnqDI9aG+IJNEP4TZtAUCr0rcbBNdnPyoIywsdIJmDG3ujLP8m98Lk/vwci54DvVRPocwyewpY5 ATgjCz0NGwAQng==; Original-Received: from [87.69.77.57] (helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1pdaLG-0001bX-FT; Sat, 18 Mar 2023 13:27:42 -0400 In-Reply-To: (message from Daniel =?UTF-8?Q?Mart=C3=ADn?= on Sat, 18 Mar 2023 17:08:25 +0100) 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:258191 Archived-At: > From: Daniel Martín > Cc: casouri@gmail.com, 62238@debbugs.gnu.org, philipk@posteo.net, > theo@thornhill.no > Date: Sat, 18 Mar 2023 17:08:25 +0100 > > Eli Zaretskii writes: > > > I don't understand how you came to that conclusion. Why would we want > > to use syntax tables when we have a parser at our fingertips? And if > > "the Tree-sitter function is general and should work for every > > language", as you say (and I agree), why should we refrain from using > > it for C? > > Note that basing C-M-x on syntax tables (that is, traditional > forward-sexp) does not completely exclude the use of Tree-sitter, AFAIU. > Here's my thought process: To do its job, C-M-x needs to know about some > code structures such as symbol constituents, strings, comments, and > parenthetical groups. If in some language or future version of C the > syntax is complex enough that getting the syntax class of a character > requires proper parsing, the Tree-sitter major modes can augment the > syntax table to make C-M-x work correctly. See > c-ts-mode--syntax-propertize for an example of how Tree-sitter can > augment a buffer's syntax table, if needed. We have already C mode that uses syntax tables. I think it's useful to try syntactic movement using results of parsing as well, and compare the relative merits and demerits. > > There's a huge advantage of using the same function for all the > > supported languages, because that makes that function better, as it is > > tested in many different situations. > > I agree that using a single function for every language is great for > simplicity and maintainability but, should it handle every movement > command as well? My main concern is that a single function > (treesit--navigate-thing) is now being used not only for every language, > but for every structural movement command. I think that it is difficult > that a single piece of logic can handle all structure movement commands > well. There's a good chance that the code will end up being complex and > difficult to maintain. Instead of deciding up front that it could be a problem, I suggest to try the tree-sitter based way and see how well it works. We can always go back to syntax tables if we decide they will work better for some modes. It makes little sense to me to make such decisions without trying the tree-sitter way and trying it well.