From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.ciao.gmane.io!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: emacs rendering comparisson between emacs23 and emacs26.3 Date: Wed, 08 Apr 2020 09:40:50 +0300 Message-ID: <831royqy31.fsf@gnu.org> References: <86tv2h2vww.fsf@gmail.com> <20200322123818.GB32470@ACM> <87eetk5swm.fsf@gnu.org> <20200326193128.GC14092@ACM> <86d08y4zsx.fsf@gmail.com> <83sghs7qdz.fsf@gnu.org> <83h7y63sjj.fsf@gnu.org> <834ku43c61.fsf@gnu.org> <83k12zz6ds.fsf@gnu.org> <054393f3-3873-ab6e-b325-0eca354d8838@gmx.at> <83eet0sqb2.fsf@gnu.org> Injection-Info: ciao.gmane.io; posting-host="ciao.gmane.io:159.69.161.202"; logging-data="97508"; mail-complaints-to="usenet@ciao.gmane.io" Cc: rudalics@gmx.at, rrandresf@gmail.com, acm@muc.de, emacs-devel@gnu.org To: rms@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Wed Apr 08 08:41:51 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 1jM4PH-000PG4-2m for ged-emacs-devel@m.gmane-mx.org; Wed, 08 Apr 2020 08:41:51 +0200 Original-Received: from localhost ([::1]:56634 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jM4PG-0007qg-3H for ged-emacs-devel@m.gmane-mx.org; Wed, 08 Apr 2020 02:41:50 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:33335) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jM4OU-0007H9-89 for emacs-devel@gnu.org; Wed, 08 Apr 2020 02:41:08 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:47275) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1jM4OT-0002ZW-G4; Wed, 08 Apr 2020 02:41:01 -0400 Original-Received: from [176.228.60.248] (port=4377 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1jM4OK-0006kn-4Z; Wed, 08 Apr 2020 02:40:52 -0400 In-Reply-To: (message from Richard Stallman on Tue, 07 Apr 2020 22:29:21 -0400) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] 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:246639 Archived-At: > From: Richard Stallman > Cc: rudalics@gmx.at, rrandresf@gmail.com, emacs-devel@gnu.org, > acm@muc.de > Date: Tue, 07 Apr 2020 22:29:21 -0400 > > > > > Recent Emacsen either ignore that variable or silently reset it to nil > > > > internally so it doesn't get into their way. Their progmodes either > > > > always scan an entire buffer from its beginning or use some elaborate, > > > > fragile techniques to find such a top level position. Moreover, our > > > > underlying mechanism for syntax highlighting always marks the entire > > > > rest of a buffer as dirty after every single editing change. This has > > > > the consequence that that entire part has to be continuously rescanned > > > > when some of it is shown in another window. > > but I want to point out a small > > inaccuracy: redisplay doesn't "continuously rescan the entire rest of > > the buffer", it only rescans the part(s) shown in windows. (It might > > happen that some major mode's font-lock definitions end up rescanning > > much more, but that's a separate issue.) > > Isn't that separate issue the issue we are talking about. I'm not sure. The text says "scan an entire buffer" and "the entire part has to be continuously rescanned", which could be interpreted as though this rescanning is the main culprit for the slowness. I wanted to point out that these aspects are not forced by the infrastructure that causes the displayed text to be fontified just in time, but by some of the major mode's fontification functions called by the infrastructure. It is IMO important to understand where to look for code that needs to be sped up, to avoid wasting effort on optimizing places that don't contribute significantly to the slowdown. > And frankly, what would we > > like Emacs to do instead? > > It would scan only from the last open-paren-in-column-zero, as it did > in the past. That would produce incorrect display, as I explained later: > A change in a buffer can potentially affect > > the fontification of the rest of the buffer, and I don't think we > > would like Emacs to fail to update other windows showing the same > > buffer > > I have a feeling there has been a change of topic here, but I can't be > sure. I surely didn't mean to change the topic. If the argument was that stopping considering the fontification at some arbitrary point in the buffer will improve performance, my point was that it OTOH might produce inaccurate display, which I consider not a good idea.