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.devel Subject: Re: Update on tree-sitter structure navigation Date: Fri, 08 Sep 2023 16:08:44 +0300 Message-ID: <83r0n8x15v.fsf@gnu.org> References: <5E7F2A94-4377-45C0-8541-7F59F3B54BA1@gmail.com> <87h6odhxs6.fsf@localhost> <87msxzsee1.fsf@localhost> <83v8cn1mse.fsf@gnu.org> <87zg1w98i9.fsf@localhost> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="433"; mail-complaints-to="usenet@ciao.gmane.io" Cc: casouri@gmail.com, emacs-devel@gnu.org, danny@dfreeman.email, theo@thornhill.no, jostein@secure.kjonigsen.net, dev@rjt.dev, wkirschbaum@gmail.com, pedz@easesoftware.com, dgutov@yandex.ru To: Ihor Radchenko Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Fri Sep 08 15:10:01 2023 Return-path: Envelope-to: ged-emacs-devel@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 1qebFI-000ATb-9l for ged-emacs-devel@m.gmane-mx.org; Fri, 08 Sep 2023 15:10:00 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qebEK-0006n6-S8; Fri, 08 Sep 2023 09:09:00 -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 1qebEI-0006mT-PI for emacs-devel@gnu.org; Fri, 08 Sep 2023 09:08:58 -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 1qebEF-0004j4-7a; Fri, 08 Sep 2023 09:08:55 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=Iiz/IqxdjtLSfz31MIAfOS/tRpo98Qb/2hr1YbJ/PZY=; b=FlztXacbZsvH xWL5Jn1qU7wjXfN7VdaTuCwmT2AaGwEjzTXV5YqXLDlwF2GEEIBibaF+KJVvJsVDcJ2i41kbY3Obp zT9cUu8Xp3+29LTqus24KkzIgU4YY4tUo9Es2j05Da2W3/VHgP9BLhbhSuBwL7n9KZr0ovtT8OkQY am2jl9Ljn172w/cW4TiIwZ8BMYNH/gzydkuoj2Y/y1fRbj6P30lXuN3TvReIV/+CUqFdwmJYGkETk y2ZuuIcn8mivbp8DkUt+ENWYDvKCFN/lcZqLCbX3jVaMQYdv6CQBW/0rrqvTPRZ4qlfY7Pr/a+3VL FDqp2c1Cyx2ZhUCbYqC+JQ==; In-Reply-To: <87zg1w98i9.fsf@localhost> (message from Ihor Radchenko on Fri, 08 Sep 2023 12:03:58 +0000) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.devel:310329 Archived-At: > From: Ihor Radchenko > Cc: casouri@gmail.com, emacs-devel@gnu.org, danny@dfreeman.email, > theo@thornhill.no, jostein@secure.kjonigsen.net, dev@rjt.dev, > wkirschbaum@gmail.com, pedz@easesoftware.com, dgutov@yandex.ru > Date: Fri, 08 Sep 2023 12:03:58 +0000 > > Eli Zaretskii writes: > > > https://lists.gnu.org/archive/html/emacs-devel/2022-12/msg01251.html > > https://lists.gnu.org/archive/html/emacs-devel/2022-12/msg01293.html > > Thanks! > > According to the discussion, the main problem is that interleaving > ts-related and ts-unrelated code in the same mode is risky. It is safer > to have a dedicated foo-ts-mode rather than modifying the existing > foo-mode. No, that's the wrong conclusion. The main reason is that mixing these modes makes no sense in most cases, due to completely different infrastructures they use. The main aspects of a major mode -- font-lock, indentation, and defun- and expression-level navigation -- are based on such different grounds that you cannot possibly reuse them. And once those are implemented on a different basis, what is left to share? > However, separate *-ts- and *- modes create a problem when user config > tailored for old, non-ts mode will no longer work. There's no argument that this is a disadvantage that causes problems to users. The challenge is to find a good solution. The basic requirements from such a solution are: . as much as possible, provide the same or equivalent features . allow easy migration of customizations from an old mode to a TS mode . allow to switch easily between the two kinds of modes for the same PL, in both directions (for example, to let users try the TS mode and switch back if they don't like it) . avoid complicating the maintenance too much > For example, c-ts-mode has `c-ts-mode-indent-offset', while cc-mode > has c-basic-offset in `c-style-alist'. Yes, but CC Mode's indentation customizations cannot be ported to c-ts-mode because they are based on a completely different classification of syntactic elements, so what do you propose as the solution for this particular schism? As for c-style-alist, the elements of the style are also completely different. So for now, we provide a different variable for c-ts-mode which supports the subset of built-in styles supported by CC Mode. If you have a concrete proposal for a better solution, let's hear it. > Ideally, user-facing API should be shared between the modes: defcustoms, > faces, and certain high-level functions like `c-set-style'. Again, there's no argument about the ideal, and never was. We just couldn't find a way of implementing this ideal without bumping into serious problems. May I suggest to study the code of at least a few pairs of modes, and see what I'm talking about? > One might slowly: > 1. Add support of foo-mode's defcustoms to foo-ts-mode, when applicable > 2. Create a shared API between foo-mode and foo-ts-mode that will call > the appropriate implementation depending on which mode is active. This sounds great in the abstract, but in practice bumps into serious implementation problems. The names of the variables are the least of our problems; the fact that we provide different names in the TS modes is to make sure no one expects the non-TS customizations to work with TS modes, because that's currently impossible: the internal structure of the data of the variables, as well as the way the related internal functions work, is too different. As an exercise, try to create an API for font-lock that could be shared by a TS and a non-TS mode. If you succeed, and if the result is significantly different from what we already have, please present the solution, because maybe we have missed something.