From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.ciao.gmane.io!not-for-mail From: Alan Mackenzie Newsgroups: gmane.emacs.devel Subject: Re: emacs rendering comparisson between emacs23 and emacs26.3 Date: Wed, 8 Apr 2020 07:02:15 +0000 Message-ID: <20200408070215.GA4106@ACM> References: <671b5b41-663d-5ab9-f022-dc6c5ce54dd0@yandex.ru> <83r1x1sqkx.fsf@gnu.org> <83lfn9s63n.fsf@gnu.org> <83h7xvqsgc.fsf@gnu.org> <90749329-ccb1-f96e-29c0-b4ecbb81d1d4@yandex.ru> <837dyrqews.fsf@gnu.org> <20200407201018.GD4009@ACM> <835zeaqz8q.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Injection-Info: ciao.gmane.io; posting-host="ciao.gmane.io:159.69.161.202"; logging-data="54549"; mail-complaints-to="usenet@ciao.gmane.io" Cc: rudalics@gmx.at, rrandresf@gmail.com, emacs-devel@gnu.org, rms@gnu.org, dgutov@yandex.ru To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Wed Apr 08 09:02:55 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 1jM4je-000E6Q-PD for ged-emacs-devel@m.gmane-mx.org; Wed, 08 Apr 2020 09:02:54 +0200 Original-Received: from localhost ([::1]:56766 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jM4jd-0004Tl-O4 for ged-emacs-devel@m.gmane-mx.org; Wed, 08 Apr 2020 03:02:53 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:35221) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jM4j7-00043w-F3 for emacs-devel@gnu.org; Wed, 08 Apr 2020 03:02:22 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1jM4j6-0002vn-Dg for emacs-devel@gnu.org; Wed, 08 Apr 2020 03:02:21 -0400 Original-Received: from colin.muc.de ([193.149.48.1]:24105 helo=mail.muc.de) by eggs.gnu.org with smtp (Exim 4.71) (envelope-from ) id 1jM4j6-0002vT-4g for emacs-devel@gnu.org; Wed, 08 Apr 2020 03:02:20 -0400 Original-Received: (qmail 99665 invoked by uid 3782); 8 Apr 2020 07:02:17 -0000 Original-Received: from acm.muc.de (p4FE15DB5.dip0.t-ipconnect.de [79.225.93.181]) by localhost.muc.de (tmda-ofmipd) with ESMTP; Wed, 08 Apr 2020 09:02:15 +0200 Original-Received: (qmail 4119 invoked by uid 1000); 8 Apr 2020 07:02:15 -0000 Content-Disposition: inline In-Reply-To: <835zeaqz8q.fsf@gnu.org> X-Delivery-Agent: TMDA/1.1.12 (Macallan) X-Primary-Address: acm@muc.de X-detected-operating-system: by eggs.gnu.org: FreeBSD 9.x [fuzzy] X-Received-From: 193.149.48.1 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:246641 Archived-At: Hello, Eli. On Wed, Apr 08, 2020 at 09:15:49 +0300, Eli Zaretskii wrote: > > Date: Tue, 7 Apr 2020 20:10:18 +0000 > > Cc: Dmitry Gutov , rudalics@gmx.at, rrandresf@gmail.com, > > emacs-devel@gnu.org, rms@gnu.org > > From: Alan Mackenzie > > OK, I'm on Line 8759, where I've got: > > else > > cp->status = STATUS_READ_FAILED; > > (I haven't updated for a few days.) Is this the same place? > Yup. > > > FTR, this is in Emacs 27.0.90 built with -Og, but a -O2 compilation of > > > Emacs 26.3 takes only slightly less time in this case. > > Is this not jit-lock-context-time? > I have no idea. But if you are saying that this is "normal", then I > disagree: I don't see why the change in fontification after DEL is > instantaneous, while the change after typing 'e' takes such annoyingly > long time. Is jit-lock-context-time not involved in the former? if > so, why? Is the problem more the asymmetry between the deletion and the insertion than the actual time taken after the reinsertion? We've had context fontification since Emacs 21. I admit I don't remember in detail why after the deletion the font locking region is extended, but not after the reinsertion. Possibly in the former case, context fontification failed to do the job right. > > However, first setting font-lock-support-mode to nil, then > > reinitialising font-lock, deleting then reinserting that "e", the line > > after the else _never_ gets its (lack of) face back. > So this is still rather a mystery, isn't it? It's context fontification. I'm quite sure of that, now. To restart jit-lock with a new j-l-context-time involves explicitly getting rid of a timer and allowing it to restart. > Thanks. -- Alan Mackenzie (Nuremberg, Germany).