From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.ciao.gmane.io!not-for-mail From: Dmitry Gutov Newsgroups: gmane.emacs.devel Subject: Re: Reliable after-change-functions (via: Using incremental parsing in Emacs) Date: Thu, 2 Apr 2020 19:17:07 +0300 Message-ID: References: <83o8sf3r7i.fsf@gnu.org> <2E218879-0F24-4A20-B210-263C8D0BEEA4@gmail.com> <838sjh2red.fsf@gnu.org> <83369o3bvb.fsf@gnu.org> <83imik1qbq.fsf@gnu.org> <835zek1kpv.fsf@gnu.org> <83v9mkz5oo.fsf@gnu.org> <83pncsym6l.fsf@gnu.org> <4a9d6bb2-458d-89b0-5389-d1f883ef24a1@yandex.ru> <74f34b72-725d-2390-faea-c61daad43350@yandex.ru> <83eet7z4if.fsf@gnu.org> <838sjfyz6k.fsf@gnu.org> <7599f566-ab1d-0b79-063e-673b7fc39c8a@yandex.ru> <83sghmx8xx.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Injection-Info: ciao.gmane.io; posting-host="ciao.gmane.io:159.69.161.202"; logging-data="23644"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.4.1 Cc: casouri@gmail.com, akrl@sdf.org, 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 Thu Apr 02 18:17:48 2020 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 1jK2XM-00063m-Je for ged-emacs-devel@m.gmane-mx.org; Thu, 02 Apr 2020 18:17:48 +0200 Original-Received: from localhost ([::1]:44286 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jK2XL-0002gS-Lg for ged-emacs-devel@m.gmane-mx.org; Thu, 02 Apr 2020 12:17:47 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:34306) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jK2Wn-0002Bm-0i for emacs-devel@gnu.org; Thu, 02 Apr 2020 12:17:14 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1jK2Wl-00047Y-Tz for emacs-devel@gnu.org; Thu, 02 Apr 2020 12:17:12 -0400 Original-Received: from mail-wm1-x329.google.com ([2a00:1450:4864:20::329]:55728) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1jK2Wl-00043w-N5; Thu, 02 Apr 2020 12:17:11 -0400 Original-Received: by mail-wm1-x329.google.com with SMTP id r16so4010155wmg.5; Thu, 02 Apr 2020 09:17:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=RjJOmWkHydrXpXs/3T9/81NXTfniv30QhlJv1y3UNlA=; b=q42YgF085eHUTBQeKPbFFedgZ3rcW7QhjL6ImzJTVa41i//BZmITg6kjBsEyQRX1Xt BaSyWg+H8Yb4SOU3n4PmWI6K9VRF1qXH9hsK21YPE26eIIrExmPAFAUYvnUX6Hhhzv06 XwB7AWtwbFO/bYrvIsDxG0J4n8mevnNI/bMN8NpZH0SJRxk8Qktx4ZNXXWSdwT+Qiy1P WDJoeJvDQ2aU/J6g7njjSroGurV90TflPkWuxtSqDr77LEsFtLK0QebFPQ2rude4752l djXgXx/JqAmzq+MRnWFmdjH6010iytAPKGmzIvlnLUXJ3zHX1lz8y2F/h0E2sCOtMF15 SnvA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:subject:to:cc:references:from:message-id :date:user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=RjJOmWkHydrXpXs/3T9/81NXTfniv30QhlJv1y3UNlA=; b=FztUvmxwmRwt7btS2ioTvEJVkIIvqZptighfr8Tsx5Gir4IGXs7oeoP0qhYV3nBZl6 YZuBLkfnxxESr75TMxIgaYSkiT9WOK2GTtxUuWcm5JLkYOv93kZBbsoZ90bpOGmAv9Bq 5P0STQMQB05DHTjd+iwZ7CqCI4dGvmusgRnM3Kmpb8rg0wQBbgX9tSoJgJNt6kWGuOVV OV4YD/CDv+knj/N/tbiX7acflefQTvbNt/yTUvEo3VlRHOMF6IQ9APTKAXnKFGbHMwNS v2ko0YRpqhn+7ekdOCxo1CcJPQgNZQ3m6oyXhNCDQYfey67bUH2D+wgQk3rN0RxP1cCE QpAQ== X-Gm-Message-State: AGi0PuY9HwpGt7MAvgAymZkJ98xuaYB7XdP+dZU/2lhO1bFzj6aXVZ9P pAq5n/yMmIWkpc9bzIPLWxk= X-Google-Smtp-Source: APiQypLo+NpxHftOTYeaTSWyIvweir6GRjxw2OJBadMd3NEn9rnUdy0oeIDr20iDb0xXI0zPC/HfLw== X-Received: by 2002:a1c:a3c5:: with SMTP id m188mr4122809wme.176.1585844230327; Thu, 02 Apr 2020 09:17:10 -0700 (PDT) Original-Received: from [192.168.0.2] ([66.205.73.129]) by smtp.googlemail.com with ESMTPSA id n11sm7330355wmi.10.2020.04.02.09.17.08 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 02 Apr 2020 09:17:09 -0700 (PDT) In-Reply-To: <83sghmx8xx.fsf@gnu.org> Content-Language: en-US X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 2a00:1450:4864:20::329 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:246273 Archived-At: On 02.04.2020 17:23, Eli Zaretskii wrote: >> Comparing both, looks like redisplay (when at eob, at least) takes >> approx. the same amount of time? > > About 55% taken by redisplay (almost all of it due to fontification), > and the other 45% are the C mode "preprocessing" when the mode is > turned on in a buffer. So, all in all, when xdisp.c is opened at eob, it will be displayed after ~2.5 seconds, I guess. >>> So you are saying that we should do that up-front computation just >>> because CC mode currently does it? That we shouldn't try to eliminate >>> such preprocessing? I don't think so. >> >> AFAIU CC Mode could actually eliminate it, but that would require a >> significant rework of its internals. > > Are we still talking about integrating a completely different parsing > engine into CC Mode? Then redesign is a must, right? No, that's without TreeSitter. >> I'm just pointing out that apparently you didn't even notice an even >> larger delay (1.7s), and were fine with it until now. > > I didn't "didn't notice", I actually filed several bug reports and > complaints about the various slow aspects of CC mode, because the > slowdown in CC mode over the years annoys me quite a lot. Some of the > problems were fixed, some weren't (due to limitations of the current > design, I was told). I'm not at all complacent about this. Still, compare that with 0.15 sec, which is the current estimate of parsing xdisp.c. It could probably be improved still by supporting a no-copy buffer-string in modules. > I cannot tell the volunteers what to do and where to invest their > resources. But I can provide feedback on the design ideas, based on > what I know and on my experience, and I can suggest how to design and > implement this to achieve good and scalable performance. We shouldn't, however, create an impression that unless they follow our ideas to a T we won't help them realize their own preferred approach (e.g. by improving the module API). > In > particular, I think that it is useful to know what we have tried in > the past and what were the lessons we learned from that. I hope what > I say is of some help, and I hope we will soon have such engine > available to Emacs. I'm fairly confident that implementing deferred/on-demand parsing in emacs-tree-sitter can be done later without requiring a major redesign. It will require, however, an extra layer of complexity either way.