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: Wed, 28 Jul 2021 13:47:42 -0400 Message-ID: References: <83h7gw6pyj.fsf@gnu.org> <46BBFF88-76C3-4818-8805-5437409BEA93@gmail.com> <83wnpq46uk.fsf@gnu.org> <533BD53B-4E85-4E9E-B46A-346A5BBAD0F5@gmail.com> <258CB68D-1CC1-42C8-BDCD-2A8A8099B783@gmail.com> <1a776770-50b7-93cd-6591-c9a5b3a56eb8@gmail.com> <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> <83r1fluikh.fsf@gnu.org> <88007ACB-31E5-440F-876D-9F43C8EE02CC@gmail.com> <86fsw05lom.fsf@stephe-leake.org> <8A3823DD-5D5A-4A33-8EF9-93F05497CE4C@gmail.com> <864kcf5cmv.fsf_-_@stephe-leake.org> <18D745F5-DBB1-46CC-91D3-4ADAA9D37AB9@gmail.com> <834kcetmly.fsf@gnu.org> 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="38226"; mail-complaints-to="usenet@ciao.gmane.io" Cc: cpitclaudel@gmail.com, Stephen Leake , monnier@iro.umontreal.ca, emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Wed Jul 28 19:48:37 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 1m8nfZ-0009hf-3x for ged-emacs-devel@m.gmane-mx.org; Wed, 28 Jul 2021 19:48:37 +0200 Original-Received: from localhost ([::1]:56004 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1m8nfX-0007l7-JG for ged-emacs-devel@m.gmane-mx.org; Wed, 28 Jul 2021 13:48:35 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:46568) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1m8nem-00074g-8n for emacs-devel@gnu.org; Wed, 28 Jul 2021 13:47:48 -0400 Original-Received: from mail-qv1-xf35.google.com ([2607:f8b0:4864:20::f35]:36364) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1m8nek-0002La-PE; Wed, 28 Jul 2021 13:47:48 -0400 Original-Received: by mail-qv1-xf35.google.com with SMTP id w6so1983490qvh.3; Wed, 28 Jul 2021 10:47:44 -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=HWF0qfSfVEi7ZHs/SeBu6q/Z6Ihe9zFne2vEfgDUUXw=; b=L4CWM9tjw/SdOA/hiAP32+Vax5ZWNcF2WtTyOWtEmmU2ZJp/ybvkLPiS0ohTr1cCPf MUAJvZkpmqFfxZhZFaHgrDH5R/eFcnoiNrbk/NxeZg4lS3WISEfqDMut1V6I9UZSSUJt L04ppFB4CybyRbKYUgWtHX8P6TpCJ3GhuHDtb7Q7vIZSDZJmzoese/+SAWX/EfxkQzfi YtZ9mkv20ee8sNbLcPsroJwPDv+CuYpsIMP141DyqzuCCnjdkz4AuVfRP5PKCCuLD2PW 2Uk6AlzvtmkUCRejJrrwopCxC2w/UAE3AeJcD3SdKQt7ivnLSqzvwJpPZdEspiQouoQy fDmQ== 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=HWF0qfSfVEi7ZHs/SeBu6q/Z6Ihe9zFne2vEfgDUUXw=; b=F4Jh+28EREFP2/3B/InU3l3JFZTDhbyFsqYlWqJ5XYSkmYNY8X2nuAU2nfn/qkMefT 6AFRZW2QpS67F1riJg7zcViKudinG2VUetdV6myWm93poQZYf/efjC69uiqGuSuleo15 YsMzGwKWDjt9PxZZxdG3VL5ic2K8MkSEeePV6/3ujWvuadFMz6fHU63IJM8ovqA7COW1 Kvma+CXOMu8JZdiynIafGbEb3gFo1OoDHKPhTHiuw40sgVrZTCpES6I6hKvvH33Tnnhy 8qEhobUT/0o/uaKlvj0DC8oOgSQikl0u1d4qVNFoj/yAjukTstXH7TBaEesbgX275nhV bDJA== X-Gm-Message-State: AOAM53000U2Gw2Lg6LnN2J9JCUxAo+BBwkjMu3GHD4ghUzHGpL0EFHi8 rpf3bPu1yJ8rn4XA8J2zwJizu7eKkVf2aA== X-Google-Smtp-Source: ABdhPJwKJ6wliZjHM1feSFL+KJsP20O5s9xPIXjjn0ORWJTZNYzHwChQJX+Sg612evXWz7PHHlqS4Q== X-Received: by 2002:a0c:e6a4:: with SMTP id j4mr1320110qvn.16.1627494463409; Wed, 28 Jul 2021 10:47:43 -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 b204sm346582qkg.76.2021.07.28.10.47.42 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Wed, 28 Jul 2021 10:47:42 -0700 (PDT) In-Reply-To: <834kcetmly.fsf@gnu.org> X-Mailer: Apple Mail (2.3654.60.0.2.21) Received-SPF: pass client-ip=2607:f8b0:4864:20::f35; envelope-from=casouri@gmail.com; helo=mail-qv1-xf35.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:271775 Archived-At: > On Jul 28, 2021, at 12:43 PM, Eli Zaretskii wrote: >=20 >> From: Yuan Fu >> Date: Wed, 28 Jul 2021 12:36:33 -0400 >> Cc: Eli Zaretskii , >> Cl=C3=A9ment Pit-Claudel , >> monnier@iro.umontreal.ca, emacs-devel >>=20 >>> What, exactly, will the buffer-text fetch code do if tree-sitter >>> violates the narrowing (by some error in tree-sitter or user code)? >>> throw an exception? return a null string? >>=20 >> In my current implementation, if tree-sitter access buffer content = outside of narrowed region, it reads whitespaces, if it access buffer = content outside of the buffer, it reads null string. Neither case throws = an error. >=20 > What does TS expect the reader function to return when it hits the > beginning or end of buffer text? I think we should behave the same > when it tries to go beyond the accessible portion. There should be no > difference between going beyond the restriction and going beyond EOB. >=20 It expect the read function set *read_bytes to 0 when it reached the end = of the buffer. Tree-sitter never =E2=80=9Chit the beginning of the = buffer text=E2=80=9D because it doesn=E2=80=99t read backward. I=E2=80=99m= pretty sure tree-sitter expects to always be able to read from BOB. Could you describe the desired effect on tree-sitter when the buffer is = narrowed? If we just deny accessibility of the hidden region from = tree-sitter, tree-sitter is still aware of the hidden text, because it = has previously parsed the hidden text and stored the result in the parse = tree. My current implementation is to =E2=80=9Creplace=E2=80=9D the hidden = region with whitespaces. When the buffer is narrowed and tree-sitter is = asked to re-parse (by some user command), I tell tree-sitter that the = hidden portion of the buffer has changed, then during the re-parse, = tree-sitter will re-scan those parts, and reads whitespaces. Yuan=