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 17:27:02 +0000 Message-ID: References: <87fs9yur7r.fsf@gmail.com> <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> <83edp642h8.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; format=flowed; charset=us-ascii Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="35675"; 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 19:28:24 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 1phw4V-00090q-Cq for geb-bug-gnu-emacs@m.gmane-mx.org; Thu, 30 Mar 2023 19:28:23 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1phw4C-0002QC-Iz; Thu, 30 Mar 2023 13:28:04 -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 1phw4B-0002Pp-Ak for bug-gnu-emacs@gnu.org; Thu, 30 Mar 2023 13:28: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 1phw4B-0002S5-1l for bug-gnu-emacs@gnu.org; Thu, 30 Mar 2023 13:28:03 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1phw4A-0005mM-B6 for bug-gnu-emacs@gnu.org; Thu, 30 Mar 2023 13:28:02 -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 17:28:02 +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.168019723022155 (code B ref 62333); Thu, 30 Mar 2023 17:28:02 +0000 Original-Received: (at 62333) by debbugs.gnu.org; 30 Mar 2023 17:27:10 +0000 Original-Received: from localhost ([127.0.0.1]:59353 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1phw3J-0005lG-MX for submit@debbugs.gnu.org; Thu, 30 Mar 2023 13:27:10 -0400 Original-Received: from heytings.org ([95.142.160.155]:60614) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1phw3D-0005l4-SA for 62333@debbugs.gnu.org; Thu, 30 Mar 2023 13:27:08 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=heytings.org; s=20220101; t=1680197222; bh=ZTIwf8bN/+lnaiA/qi9XsE6zPapK9BmVmWvYwdN5/dY=; h=Date:From:To:cc:Subject:In-Reply-To:Message-ID:References:From; b=P5Exg7O0g7+qoujIMrrLX1U+DzQCv0BoCKsG7opWFf8PQ3RP2UL53BzK55wQxHumu crUFjiz65CNONCqBe9bRwxPvJZ4uXDmzbzdOACHDIT7jzJOu+7see2/hagBmNrYhWw ZwsE/vCaCJnkONEINGj/4kwIJ9URMhXkZwsR3L6CYGVxWE8KY9RRAgi81U9eyazXU9 V7UzAlWn0uA8G6VxoQpnWuld4klDNyIEpChhp1iGxLrOE2PUiG7CnLHYYOtmLgeBXB 64cWf78txmbc7sa4C+VbrBtWDr1RuwLw2701SMmqGmdrOpqDiVpzVQzDnIzIRjhavK w4l5V4P2UUL6g== In-Reply-To: <83edp642h8.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:258941 Archived-At: >>> 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? > > The parsers _can_ have access to those ranges, if they need it for some > reason. In general, everything in Emacs should honor the current > restriction, unless there's a good reason to ignore it. > Okay, so in the above example by default the parsers will only have access to 1000-1100 for the first one, and 1100-1200 for the second one until the user removes the restrictions. Unless they need to widen the buffer for some (good) reason. If they do widen, will the parsers get access to [400..1100] and [1100..1500], or to the whole buffer? Or will they have two ways to widen, one to get access to the whole region on which they have been defined, and another one to get access to the whole buffer? > > The problem with ignoring it is that we can never know which code/user > defined the restriction and for what purpose. I hope that keeping the > parser's restrictions as part of the parser itself will allow us to > break free of that issue when we have to widen. > At least it's a possibility that seems worth investigating.