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: How the long-lines "optimisation" breaks font locking. Date: Thu, 04 Aug 2022 19:09:56 +0300 Message-ID: <83fsic2dnv.fsf@gnu.org> References: <87y1w5tahv.fsf@gnus.org> <83sfmc2mph.fsf@gnu.org> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="17736"; mail-complaints-to="usenet@ciao.gmane.io" Cc: larsi@gnus.org, emacs-devel@gnu.org, gregory@heytings.org To: Alan Mackenzie Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Thu Aug 04 18:15:31 2022 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 1oJdVT-0004S7-11 for ged-emacs-devel@m.gmane-mx.org; Thu, 04 Aug 2022 18:15:31 +0200 Original-Received: from localhost ([::1]:38634 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1oJdVR-0001HC-VR for ged-emacs-devel@m.gmane-mx.org; Thu, 04 Aug 2022 12:15:29 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:35282) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oJdQ8-00024e-ML for emacs-devel@gnu.org; Thu, 04 Aug 2022 12:10:00 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:44230) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oJdQ8-0005pP-3Z; Thu, 04 Aug 2022 12:10:00 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=qBK/HftsEMh1g13Ls8II291XF0/TCnpHHR0imN2NoDw=; b=FNfFLbIltYvx N5tHOCJVgdK9f3FI/m9yi/Zlt5n0D1caeLK96F6D/qIQUm0Q3deDL/s1TE6/6RhQMX5nn6WexRRwr UlRjglWeESAWT1UIT4keUao4XCzj1s9WrrnF8M7nW+Jc5E0BOyEvgo5XSdWDxJU3XEBXACIDtZTva URNo3yjYWTjwe7QhOlE15LIWfIFGIwlPudOUw+saKQz5p+65EDbMsrENAu8SNksMd+iLwSqSPvT6x HpVFQPfZeQItr2xuL/yHzdSNSBNgyBHqZ+a5hFun2RNQr1veurEUypL+Wx9rS+rrjjJfvJiZcaUlz hOHJYWZ9A7vkpC4ruufOCQ==; Original-Received: from [87.69.77.57] (port=4071 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 1oJdQ7-0005Zr-Hq; Thu, 04 Aug 2022 12:09:59 -0400 In-Reply-To: (message from Alan Mackenzie on Thu, 4 Aug 2022 14:44:05 +0000) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.29 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:293074 Archived-At: > Date: Thu, 4 Aug 2022 14:44:05 +0000 > Cc: larsi@gnus.org, emacs-devel@gnu.org, gregory@heytings.org > From: Alan Mackenzie > > > > Well I tried CC Mode with a 1,000,000 character raw string. It was > > > indeed a bit sluggish but "hang indefinitely" is an exaggeration. > > > Try it with a 20MB raw string, then. And, for good measure, in an > > unoptimized build. These are the cases we are trying to make > > workable. > > No matter what criterion one deems "workable", there will be some size of > buffer, or line, which renders Emacs "unworkable". Not with narrowing, no. Because the size of the narrowed region is independent of the buffer size. That's the main idea of these changes, and that's why the idea is IMO a good one. > > > Doing these things in the current master branch indeed appeared to be > > > fast, but at one point an error in an after-change-function caused > > > after-change-functions to get set to nil, crashing CC Mode. > > > If you can show a recipe for this problem, we will fix it. This code > > is WIP, so some problems definitely remain and should be reported and > > fixed. > > I'll see if I can recreate it. TIA.