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: [SPAM UNSURE] Re: How to add pseudo vector types Date: Thu, 22 Jul 2021 01:09:13 -0400 Message-ID: <293541a0-cb75-242d-8627-6a2c0586be7c@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> <1a776770-50b7-93cd-6591-c9a5b3a56eb8@gmail.com> <86a6mh54ko.fsf@stephe-leake.org> <680f895c-a787-0a05-d29e-f90525cbc376@gmail.com> <86k0lj4nfu.fsf@stephe-leake.org> <83im134fd6.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="18462"; 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 Cc: emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Thu Jul 22 07:09:54 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 1m6Qy1-0004dx-N8 for ged-emacs-devel@m.gmane-mx.org; Thu, 22 Jul 2021 07:09:53 +0200 Original-Received: from localhost ([::1]:42098 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1m6Qy0-0001yP-Ag for ged-emacs-devel@m.gmane-mx.org; Thu, 22 Jul 2021 01:09:52 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:33372) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1m6QxS-0001I3-8O for emacs-devel@gnu.org; Thu, 22 Jul 2021 01:09:18 -0400 Original-Received: from mail-qv1-xf2f.google.com ([2607:f8b0:4864:20::f2f]:46953) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1m6QxQ-00072l-Fx; Thu, 22 Jul 2021 01:09:17 -0400 Original-Received: by mail-qv1-xf2f.google.com with SMTP id kl28so136784qvb.13; Wed, 21 Jul 2021 22:09:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=Y2YKFd5zmYM27qUJN9t76n0lHJyMUr9pdSxtXNkndhE=; b=nkrBwe1X3YyXHnxjnO8ZrD+hujCxmC3yvT7r7h17bXasVlRICsKAwobai9DrJirLvB wMyHOlm17gYfoBfMRNgGY12Sn+7+XeBCRiG6kAtKWgFx+yltrxjNw8QYIZH9ZpjG3WNs w7LnY5VYdcKOZ9c/jMLzZUcqHnogTCaDVfsol17te4COhxzzupYEtLmVvnLZJ525GZ9W sjJFguxSkwJUDdtwUjnYboRti3VwxCtKOVNT6xZ1JzyJ5frVfd2nYRMTTa+DwtXCR/FG Jtm/9eVxJctX9wJB2QLHF5d85dK8q3Jo9b6XHr7TxLb70pwuDkkKcY+HyTI1r+ZkLdeu SG0g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=Y2YKFd5zmYM27qUJN9t76n0lHJyMUr9pdSxtXNkndhE=; b=rjBH3cGxPor1SikK55rc7L+Kyug0xo84JhD4Bz/cgmjI41wj6WSOtp+iMiswRnXIml WUhdjYkDIASobm6kB5u7ZfyhWWuB2z8uGwOMSxb/AKQb/3xaqhPfLkwh2KyWXrZhjyul 5eZKFviDqWCwT4USDUj9k0ZE61xMWQyTDbXPjYiAaMdorEVqoXdKXLdvwSnlVswGfC38 0idsbxGsRnHSCYUJbySnytQ8q/Vu0KJ53aLcjmSKldYlY4Mii5tNpB+ae5op9GIjrztI TAJPg/ZunAIkozL50TPO01EXXPmGTVZQWWwfpn/Wrhm5bQOG9zGocTdWKEbqTFjGlmRz loyg== X-Gm-Message-State: AOAM532Sap4PuYc7U+hlEUln4mLpapIIyAmpIhNapvDLxqm20hb5SQGg IUm9QH0XfVslnv1UTJD0TxjnXGaQKgc= X-Google-Smtp-Source: ABdhPJwG4M/C17KcLLx3TSr61fVwt1pfkTjcPmfmi8iWWcjmkSEo8SPbOtLSMP2p8IpcbFJPAvj+dA== X-Received: by 2002:ad4:5386:: with SMTP id i6mr39609580qvv.2.1626930554686; Wed, 21 Jul 2021 22:09:14 -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 h10sm10011362qta.74.2021.07.21.22.09.13 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 21 Jul 2021 22:09:14 -0700 (PDT) In-Reply-To: <83im134fd6.fsf@gnu.org> Content-Language: en-GB Received-SPF: pass client-ip=2607:f8b0:4864:20::f2f; envelope-from=cpitclaudel@gmail.com; helo=mail-qv1-xf2f.google.com X-Spam_score_int: -21 X-Spam_score: -2.2 X-Spam_bar: -- X-Spam_report: (-2.2 / 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.117, 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:271448 Archived-At: On 7/21/21 3:49 PM, Eli Zaretskii wrote: >> From: Clément Pit-Claudel >> Date: Wed, 21 Jul 2021 13:12:16 -0400 >> >> On 7/21/21 12:54 PM, Stephen Leake wrote: >>> Hmm. Perhaps you are not talking about interrupting the parse; you are >>> assuming that the parse for each change completes before the next change >>> arrives. >> >> Neither of these. I'm assuming that you open a file, launch a parse, batch up changes until that first parse completes, then launch a second parse, during which additional changes are batched up, then launch a third parse, etc. > > But how would the "launched parse" access the buffer text if it runs > in parallel to normal editing? We've discussed the difficulties with > that, and you seem to ignore them here? Lots of magic handwaving: IOW, I don't have a solution, just a general hope that minimal synchronization and decent error recovery would help (for example, maybe it's enough to synchronize only when TS requires a chunk of memory). But for the discussion above, Stefan's copying solution works fine. >> Any time you actually need the info (for navigating, or for fontification, or…) then you either use the last parse if it was recent enough, or (more likely) you block until you can complete a synchronous parse. > > Which means the results will many times be slightly wrong, because the > parse info you use is outdated? Maybe. In practice if the delay between requesting the info and getting it is perceptible, then displaying outdated info is better than freezing until you get up-to-date info, no? Either you're getting info so fast that the user doesn't realize that you're outdated by 1ms; or you're getting info so slowly that the user realizes that you're running one second behind — but it's much better than freezing for one second. Less relevant details below: This is a problem we have all the time with Flycheck btw: you send the text of the buffer to a compiler, it returns 3 seconds later, and you want to display errors as reported by the compiler. By the time we get errors to display, the locations they come with are outdated. We don't have a good solution. Visual Studio in the old days had a really beautiful solution for this. There was a (basically) free API you could call to snapshot a buffer at a point in time; then there was a function that translated positions in that snapshot to position in the current buffer (think of it as magically putting a marker into the past buffer when the snapshot was taken, and then querying its current position). So positions returned by the compiler or any other tools were still relevant if they referred to a three-seconds old buffer, since you could translate them to the current buffer. Clément.