From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Gregory Heytings Newsgroups: gmane.emacs.bugs Subject: bug#62333: 30.0.50; Issue with tree-sitter syntax tree during certain changes Date: Thu, 30 Mar 2023 16:28:58 +0000 Message-ID: References: <87fs9yur7r.fsf@gmail.com> <83jzz5c8ml.fsf@gnu.org> <83edpdc6sn.fsf@gnu.org> <1ca302bf-99dc-7f9e-8544-063064a1cb21@yandex.ru> <831qlcdisi.fsf@gnu.org> <398721ad-79b0-3f6d-97b3-4902d9bfbe39@yandex.ru> <83wn34c2qa.fsf@gnu.org> <3b3d82d1-f0f6-a768-a5db-8dc9386a5a34@yandex.ru> <83r0tcbz8g.fsf@gnu.org> <1967361679760225@umbzx4hqxrw5qxo7.sas.yp-c.yandex.net> <83mt40bxzd.fsf@gnu.org> <83jzz4bugh.fsf@gnu.org> <3d64520c-54da-a04a-ed0d-a66b4e753f8a@yandex.ru> <831qlcaysh.fsf@gnu.org> <29679184-7366-0167-9e94-def97048f663@yandex.ru> <83v8inal29.fsf@gnu.org> <9886ffa5-ead2-50d5-a325-f6704b736ada@yandex.ru> <83fs9q9vak.fsf@gnu.org> <10aa98b6-908b-c467-7c77-767906692088@yandex.ru> <83h6u585si.fsf@gnu.org> <5c683b3b-48e8-5099-8ab1-459c348d1f88@yandex.ru> <83jzyz7qmy.fsf@gnu.org> <83h6u2444x.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="11713"; mail-complaints-to="usenet@ciao.gmane.io" Cc: wkirschbaum@gmail.com, casouri@gmail.com, 62333@debbugs.gnu.org, dgutov@yandex.ru To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Thu Mar 30 18:30:28 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 1phvAS-0002qG-1z for geb-bug-gnu-emacs@m.gmane-mx.org; Thu, 30 Mar 2023 18:30:28 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1phvA5-0000K7-EK; Thu, 30 Mar 2023 12:30:05 -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 1phvA3-0000Jw-Qe for bug-gnu-emacs@gnu.org; Thu, 30 Mar 2023 12:30:03 -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 1phvA3-0003E1-IG for bug-gnu-emacs@gnu.org; Thu, 30 Mar 2023 12:30:03 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1phvA3-0004Ii-3L for bug-gnu-emacs@gnu.org; Thu, 30 Mar 2023 12:30:03 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Gregory Heytings Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 30 Mar 2023 16:30:03 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 62333 X-GNU-PR-Package: emacs Original-Received: via spool by 62333-submit@debbugs.gnu.org id=B62333.168019374216432 (code B ref 62333); Thu, 30 Mar 2023 16:30:03 +0000 Original-Received: (at 62333) by debbugs.gnu.org; 30 Mar 2023 16:29:02 +0000 Original-Received: from localhost ([127.0.0.1]:59298 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1phv94-0004Gn-5c for submit@debbugs.gnu.org; Thu, 30 Mar 2023 12:29:02 -0400 Original-Received: from heytings.org ([95.142.160.155]:60550) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1phv92-0004GW-DP for 62333@debbugs.gnu.org; Thu, 30 Mar 2023 12:29:01 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=heytings.org; s=20220101; t=1680193738; bh=cMFSGEfEJZ4BxEuM2squRMQBg9k0xOdUl3+1N3BV5Mw=; h=Date:From:To:cc:Subject:In-Reply-To:Message-ID:References:From; b=PnjI4VhvxBZFDImumDbKJNv2pz6Gri/AdqzwXoxSuUMVHRQ4BRpWYawz5djjkVBKS 2r0WAKMi+DdMUVhf6oeHMrDOhVwqPjmSfWSp2PAoL1uKISa+9+Qwm0byAWvqZX8PW6 QnEmiaEO0c4REDxBwgHyLrmTYWHakuFtzp8hwoTTg77HKuF73ipUqfztl1IRpgBp+i g65kpIThLPs0j9hi7yBtzl9345dEOQH97gfR+P7CAparrRayL+xxJ8yE4qEaHwQs1v ylPUtCy0dRwgHjyie7eVWgXKnZf08bWnrYRtpvXbQeHna+w7Ihikap1RsOmHXc4D15 zgK9uytj2juFw== In-Reply-To: <83h6u2444x.fsf@gnu.org> 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:258937 Archived-At: >> Could you perhaps explain, with some fictitious code, what kind of >> solution you imagine? I'm not sure I understand (euphemism for: I'm >> sure I don't understand) the problem statement. > > Something like > > (treesit-make-parser LANGUAGE BUFFER nil START END) > > and > > (treesit-parser-set-included-ranges RANGES...) > > (the latter already exists). > Where "RANGES..." are included in [START..END], right? >> In what way would the restrictions you have in mind be different from >> those of a regular narrowing? > > User-defined narrowing will never contradict parser restrictions. > You mean, they will be independent, right? In other words, if the user sets the narrowing to 1000-1200 in a buffer in which treesit-make-parser has been called, say, once with 'php 400 1100' and once with 'js 1100 1500', the two parsers will continue to have access to these ranges? >> Also, would such a parser always/never/sometimes obey the user >> narrowing? > > It will always obey narrowing (it must), but we can then widen the > buffer temporarily inside some functions without caring about the > semantics of the narrowing and its source/purpose. > Here I'm confused, that sentence seems to contradict the previous one. "It" in "it will always obey narrowing" is the parser, right, and "narrowing" is "the narrowing bounds set by 'treesit-make-parser'", right?