From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Yuan Fu Newsgroups: gmane.emacs.devel Subject: Re: How to add pseudo vector types Date: Tue, 27 Jul 2021 10:49:44 -0400 Message-ID: <4EA6F686-9408-4739-8552-110C24655966@gmail.com> References: <8335s64v10.fsf@gnu.org> <5380C92B-6C15-4490-A1E0-1C3132DBB16A@gmail.com> <83k0li2shw.fsf@gnu.org> <86wnpg82v3.fsf@stephe-leake.org> <83lf5wyn0z.fsf@gnu.org> <86pmv66yqg.fsf@stephe-leake.org> <83a6maw705.fsf@gnu.org> <20210726234053.za5axe3m646ps7wr@Ergus> Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.60.0.2.21\)) 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="19529"; mail-complaints-to="usenet@ciao.gmane.io" Cc: Eli Zaretskii , emacs-devel@gnu.org, Stephen Leake , =?utf-8?Q?Cl=C3=A9ment_Pit-Claudel?= , Stefan Monnier To: Ergus Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Tue Jul 27 16:50:30 2021 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 1m8OPd-0004vu-L6 for ged-emacs-devel@m.gmane-mx.org; Tue, 27 Jul 2021 16:50:29 +0200 Original-Received: from localhost ([::1]:45406 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1m8OPc-00078l-HG for ged-emacs-devel@m.gmane-mx.org; Tue, 27 Jul 2021 10:50:28 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:41096) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1m8OOy-0006R2-PD for emacs-devel@gnu.org; Tue, 27 Jul 2021 10:49:48 -0400 Original-Received: from mail-qk1-x72a.google.com ([2607:f8b0:4864:20::72a]:40632) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1m8OOx-0002V9-4E; Tue, 27 Jul 2021 10:49:48 -0400 Original-Received: by mail-qk1-x72a.google.com with SMTP id z24so12557252qkz.7; Tue, 27 Jul 2021 07:49:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=KWemG1p+2AqtNZsIVSRz8Zr/b6e29AjNUjAG3n4ssYE=; b=tZLv/3AKunOchcCyN5wYcyzz20lfA2cKG4lR+6rFw9CPq7SkReWHeXxSvg6W9s71jk A05L2qmHOcFU1MzK45vEibR4lcdz+voCrDeqUcLhfHG4zmNsllArmA3zS2jImc5QkKah iuy1Ybe3RPGAp4aojQcLkbeZVpekHu9p+KaYmvzhfFB1whUUr+CeSAYA+rEbpGItjmr6 jnBIaHG8EofBsnj02YsbOvRbbzEDv30NHp/o20PBByaO+urhiJ3e5t7j/A4miIQcxRZK QoyQFuueH9HxSgNXv4bP4CxDl+GSLm3W5UQhhXfg4zsUJIfHv2ReviLQdQxdegZTxixh iK0w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=KWemG1p+2AqtNZsIVSRz8Zr/b6e29AjNUjAG3n4ssYE=; b=NTMgbADTQL3p3O0U0kOkjutu0GUbZlxIXcPl5JuR48hd1xIyU7YP58AnZ1ysmkYVby hsyNr5NZEUEWfZ8YwDTVq+Oz5JKeBqkr3D/1TRe1vmmLiBgG74LrSbBAmE3KRosNiP8O Af7QuiVxUgU9H7LAqWgbJ0u/ee1RWQwdAi6MW6pDu6jk1xo5/ZooxmXJaErjLzPR1DKc 8sz8clLsfWyQyhCzW/IXjSKMZ1jLLiKGZxfIE7NZUA/VmuLSBJMFxRgxnRqg97BInZni 2DJ8J5PHd4bjsDQYzKH0Yj9q5l5S56IVD7JC1SWef9xiRNzh82w6eip7F5YC+bqhuh3o btBQ== X-Gm-Message-State: AOAM532sQLRpDhwiR/IxSdksKuUPXMQb/Y4R0eS4EhLxYlWpG/CBZ8LS 3dWDrKNjUcj5VrFzOfjJa9Y= X-Google-Smtp-Source: ABdhPJycsT3hxVsrbdUge8WFGBcCarBiTLhdaR6mT63hy4Pj06WaYcpRusfcplS+j47/8+llEr0lFg== X-Received: by 2002:a37:a358:: with SMTP id m85mr23065556qke.285.1627397385878; Tue, 27 Jul 2021 07:49:45 -0700 (PDT) Original-Received: from 2603-7080-0302-635e-540d-2222-3fe9-1314.res6.spectrum.com (2603-7080-0302-635e-540d-2222-3fe9-1314.res6.spectrum.com. [2603:7080:302:635e:540d:2222:3fe9:1314]) by smtp.gmail.com with ESMTPSA id x21sm1928645qkn.0.2021.07.27.07.49.44 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 27 Jul 2021 07:49:45 -0700 (PDT) In-Reply-To: <20210726234053.za5axe3m646ps7wr@Ergus> X-Mailer: Apple Mail (2.3654.60.0.2.21) Received-SPF: pass client-ip=2607:f8b0:4864:20::72a; envelope-from=casouri@gmail.com; helo=mail-qk1-x72a.google.com X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.23 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" Xref: news.gmane.io gmane.emacs.devel:271696 Archived-At: >=20 > =46rom my absolute ignorance on tree_sitter and your changes. There is = a > function ts_parser_set_included_ranges that is a way I used once to > reduce the parsing region and improve (notably) the performance in a > test api. >=20 > Can't narrow regions use that? I think it is the same idea but I am > probably wrong. We could use ts_parser_set_included_ranges to implement narrowing, but = that would limit the usefulness of ts_parser_set_included_ranges: = ts_parser_set_included_ranges allows us to set multiple discontinuous = ranges, and narrowing only allows us to narrow to a single continuous = range. Therefore I=E2=80=99d like to expose = ts_parser_set_included_ranges in a separate function. >=20 > Limiting the region to parse to the modified region (that in emacs may > be known thanks to the gap and maybe the undo-tree) and using the = output > tree from the previous parse as the `old_tree` parameter in > ts_parser_parse_string made tree_sitter incredibly fast in my case = (and > useful to run it on every key press). Interesting, the official documentation doesn=E2=80=99t mention that = trick. It only tells me to re-parse with the old tree. If I limit the = range to the modified region before re-parse, re-parse, do I get the = tree for the entire buffer, or do I only get the tree of the limited = range? >=20 > In my case using old_tree reduced the time by a factor of 10 in a big > source file; and limiting the parser to the "changed" region only made > it almost instantly in more than 80% of the executions with small > modifications. (I repeat; it was a much simpler use case) >=20 >> And about language definitions and font-locking, I just realized that >> tree-sitter language definitions provides highlighting patterns, and = we >> only need to minimally modify them to use them for Emacs, so there >> aren=E2=80=99t much manual effort involved. >>=20 > I think tree-sitter has many more language definitions than Emacs in > some languages, and probably we may want to properly support them. So > maybe: instead of just modifying what is on tree-sitter to make it > similar to what emacs currently has; we could just use the node's > syntactic information and then let emacs use it adding more faces if > needed... Does it makes sense? The current code does the latter, if I understand you correctly. > The idea is to have real syntactic information on the text itself > because that may help in the future to implement indentation and > navigation commands using three-sitter's information (commands like > up-list or forward-sexp) will be the equivalent to > ts_tree_cursor_goto_parent or ts_tree_cursor_goto_next_sibling. You mean adding syntactic information to the text as text properties? = That=E2=80=99s an interesting idea, maybe that=E2=80=99s easier to use = than using tree-sitter=E2=80=99s api. Yuan=