From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: =?UTF-8?Q?Cl=c3=a9ment_Pit-Claudel?= Newsgroups: gmane.emacs.devel Subject: Re: How to add pseudo vector types Date: Fri, 16 Jul 2021 22:23:26 -0400 Message-ID: <1a776770-50b7-93cd-6591-c9a5b3a56eb8@gmail.com> References: <83h7gw6pyj.fsf@gnu.org> <45EBF16A-C953-42C7-97D1-3A2BFEF7DD01@gmail.com> <83y2a764oy.fsf@gnu.org> <83v95b60fn.fsf@gnu.org> <00DD5BFE-D14E-449A-9319-E7B725DEBFB3@gmail.com> <83r1fz5xr9.fsf@gnu.org> <1AAB1BCC-362B-4249-B785-4E0530E15C60@gmail.com> <83czri67h0.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> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="30861"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.11.0 To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sat Jul 17 04:24:22 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 1m4a04-0007p9-VN for ged-emacs-devel@m.gmane-mx.org; Sat, 17 Jul 2021 04:24:20 +0200 Original-Received: from localhost ([::1]:44742 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1m4a02-0001AP-SP for ged-emacs-devel@m.gmane-mx.org; Fri, 16 Jul 2021 22:24:18 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:48014) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1m4ZzI-0000Tu-Nc for emacs-devel@gnu.org; Fri, 16 Jul 2021 22:23:32 -0400 Original-Received: from mail-qk1-x731.google.com ([2607:f8b0:4864:20::731]:46780) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1m4ZzF-0003Z0-Iu for emacs-devel@gnu.org; Fri, 16 Jul 2021 22:23:32 -0400 Original-Received: by mail-qk1-x731.google.com with SMTP id 201so10663901qkj.13 for ; Fri, 16 Jul 2021 19:23:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language:content-transfer-encoding; bh=uMN7xPD8sHaPnIUHoP6L8J1/MPNAsNR75n8Qa/N+TIA=; b=MM7YfYAa5WRCMHACu+OZgNZmsabP/S+1GBfojV1I2VGjXsDMC0OqkNAakKzczDCF4g AgEXmwk60GomLalKPIU6AxOyjau3B0CeFCHcHsHuRiSBI5DyUqA+oXMcoBVMUasdCXcc YdfXasG0jTxbRuJS+djrRlmIYst7vGylN3usZJeV6XfNYDkXIcq7fKn9PeWwmIn0c2Hi 8V3idNHtlqU8MZ+pnS/3FlszsKUN89wEq5m67b2xFGrMRYvmWRT22m+ydwCZBXfN8B9+ eUMzuXJH9tCbIJgsdDSYAnMeyAk7FFnV96GtgIdVqj+hG1vgh4ea4lkH87HoN0QjWhz7 sD4w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=uMN7xPD8sHaPnIUHoP6L8J1/MPNAsNR75n8Qa/N+TIA=; b=DYu43JXcIlNKcUZ1daUpV1yqJZMr4JGYcLwEDxEicj887BKVT0fkWb8cFOoDgRt9Yv qkAXUyCfIMmVVEnxrHMcI5saBcBseaEwGIcW3ILxDUseUsw76KoGgFp8jIj5QLFLFEPE crdpx2GVjbGW4aZsvEwj4i88pyZ9Va6N0I5sl1dhDHiuGThitLUTmWv7UWxAZ24QvxCm X3jjJQ2eoq/gNu377dGYSuCyulBV7tpTdu42EmxHxMMKPq49X7zo1YNoetCcfNRvTX1b mzsywp8FOVTC4lVOD5Wq5zeZEZ+IQAIqQRWGdc64nkW/6+JkEIEvKqVZgS5lHYsDAWrA sCyA== X-Gm-Message-State: AOAM530fl8cL7h0CkLkBKvYYwoKgRLdxSwe4hM/ZBbGgNbmht3WHLrUb lT1pILuBKWPO5+ulMSDpx3dCdV5h1lg= X-Google-Smtp-Source: ABdhPJzwBffhsTc/Gy6gZj3cmuPOkSE17kpjDXw0jTpp7j7d4lQQzUpIddyyzlG03lpNQbFYbQ0tWA== X-Received: by 2002:a05:620a:2006:: with SMTP id c6mr12559016qka.337.1626488607693; Fri, 16 Jul 2021 19:23:27 -0700 (PDT) Original-Received: from [192.168.1.11] (c-24-61-240-80.hsd1.ma.comcast.net. [24.61.240.80]) by smtp.googlemail.com with ESMTPSA id bj37sm4688987qkb.78.2021.07.16.19.23.27 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 16 Jul 2021 19:23:27 -0700 (PDT) In-Reply-To: <258CB68D-1CC1-42C8-BDCD-2A8A8099B783@gmail.com> Content-Language: en-GB Received-SPF: pass client-ip=2607:f8b0:4864:20::731; envelope-from=cpitclaudel@gmail.com; helo=mail-qk1-x731.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, NICE_REPLY_A=-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:271323 Archived-At: On 7/16/21 10:05 PM, Yuan Fu wrote: > My conclusion is that after-change-hook is pretty insignificant, and the initial parse is a bit slow (on large files). I have no idea if it makes sense, but: does the initial parse need to be synchronous, or could you instead run the parsing in one thread, and the rest of Emacs in another? (I'm talking about concurrent execution, not cooperative threading). In most cases there should be very limited contention, if at at all: in large buffers most of Emacs' activity will be focused on the (relatively few) characters around the gap, and most of the parser's activity will be reading from the buffer at other positions. You do need to be careful to not read the garbage data from the gap, but otherwise seeing stale or even inconsistent data from the parser thread shouldn't be an issue, since tree-sitter is supposed to be robust to bad parses. In fact, depending on how robust tree-sitter is, you might even be able to do the concurrency-control optimistically (parse everything up to close to the gap, check that the gap hasn't moved into the region that you read, and then resume reading or rollback). Alternatively, maybe you could even do a full parse with minimal concurrency control: you'd make sure that the Emacs thread records not just changes to the buffer text but also movements of the gap, and then you could use that list of changes for the next parse? Anyway, thanks for working on this!