From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: [SPAM UNSURE] Re: How to add pseudo vector types Date: Thu, 22 Jul 2021 09:44:45 +0300 Message-ID: <838s1y4zky.fsf@gnu.org> 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> <293541a0-cb75-242d-8627-6a2c0586be7c@gmail.com> 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="30393"; mail-complaints-to="usenet@ciao.gmane.io" Cc: emacs-devel@gnu.org To: =?utf-8?Q?Cl=C3=A9ment?= Pit-Claudel Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Thu Jul 22 08:46:47 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 1m6STn-0007gu-Fe for ged-emacs-devel@m.gmane-mx.org; Thu, 22 Jul 2021 08:46:47 +0200 Original-Received: from localhost ([::1]:45784 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1m6STl-0004wa-Q2 for ged-emacs-devel@m.gmane-mx.org; Thu, 22 Jul 2021 02:46:45 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:43604) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1m6SSQ-00049x-HF for emacs-devel@gnu.org; Thu, 22 Jul 2021 02:45:22 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:43526) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1m6SSQ-0007gC-A9; Thu, 22 Jul 2021 02:45:22 -0400 Original-Received: from 84.94.185.95.cable.012.net.il ([84.94.185.95]:2377 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1m6SS6-0002Bg-S2; Thu, 22 Jul 2021 02:45:05 -0400 In-Reply-To: <293541a0-cb75-242d-8627-6a2c0586be7c@gmail.com> (message from =?utf-8?Q?Cl=C3=A9ment?= Pit-Claudel on Thu, 22 Jul 2021 01:09:13 -0400) 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:271451 Archived-At: > Cc: emacs-devel@gnu.org > From: Clément Pit-Claudel > Date: Thu, 22 Jul 2021 01:09:13 -0400 > > > 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: Hand-waving always works, of course. > > 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. The time doesn't matter here: the amount of changes does. IME, display based on outdated information is NOT okay. The discrepancy between the actual stuff on the screen and its fontification based on outdated buffer context could be quite annoying, for example. > 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. We can do that as well. It's again something very similar to the undo-list info we already collect.