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 15:54:34 +0300 Message-ID: <83sfmc2mph.fsf@gnu.org> References: <87y1w5tahv.fsf@gnus.org> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="15742"; 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 15:14:08 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 1oJafv-0003vT-Ua for ged-emacs-devel@m.gmane-mx.org; Thu, 04 Aug 2022 15:14:08 +0200 Original-Received: from localhost ([::1]:45392 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1oJafu-0005tE-T5 for ged-emacs-devel@m.gmane-mx.org; Thu, 04 Aug 2022 09:14:06 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:42834) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oJaN7-0000UQ-My for emacs-devel@gnu.org; Thu, 04 Aug 2022 08:54:41 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:39804) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oJaN5-0006aA-Jl; Thu, 04 Aug 2022 08:54:40 -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=Y/UDcKzsjxxbK2oPGHqqJgB3Gt26XfXraupqVXPmU1Q=; b=jqwbw2BYpKKj 66f7KslCqq/qS90aekZF1SxI1F6W0mgwPcZHdM2oCbd2ZHhuOcRS/JyIbl7jBBvXgRhzsfMmeUJQP 1z6CiEeisScPAzXiJkiYhqU5yy9ON5V11Vph0ZphkKiIM+bepatpYrlwUiy9K+zTVr5gf6MJ2+yf/ kfAO996Ads53rRjL668CB6MR2mFtZyQzvxrvVfyt/V6rPD/1TIfsuJLoJzGIIW5zcYqQf9WCKZ793 Un/vcwj5GFVTbq7TRaD/j/pNvl+54ik+dz/z8Y/mJRkk6OuKTnTSfEBQ9vMhtVdxA25cF+ym8Ud/4 OSlbWSSL9ZwTpPeYyN06lQ==; Original-Received: from [87.69.77.57] (port=4062 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 1oJaN5-0004WJ-3K; Thu, 04 Aug 2022 08:54:39 -0400 In-Reply-To: (message from Alan Mackenzie on Thu, 4 Aug 2022 10: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:293059 Archived-At: > Date: Thu, 4 Aug 2022 10:44:05 +0000 > Cc: emacs-devel@gnu.org, Gregory Heytings > From: Alan Mackenzie > > Hello, Lars. > > On Wed, Aug 03, 2022 at 21:03:56 +0200, Lars Ingebrigtsen wrote: > > Alan Mackenzie writes: > > > > I don't think it is improbable that a C++ hacker will create a long line > > > in a raw string. > > > If you don't think that's improbable, then you should like the new > > optimisations a lot -- .... > > These "optimisations" break CC Mode. They don't "break" it, they cause it occasionally produce inaccurate fontifications. And only when otherwise Emacs becomes unusable. > > .... because if you, instead of a 10K line in that C++ file, inserted > > a 1M line, then Emacs would previously hang indefinitely, but with the > > optimisation, it doesn't. > > 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. If all you are saying is that the default value of long-line-threshold is too low, we can definitely discuss a better value. > Having loaded the file in C++ Mode (without the spiking of > narrow-to-region and widen), it took 90 seconds for M-> (first time). And you consider that reasonable? > Moving point was sluggish, taking perhaps 1 to 3 seconds, as did > scrolling by a screenful. Did you try moving and the beginning of the buffer or at its end? The speed is very different. > Inserting text in the middle of the line caused an overflow in the > regexp engine stack. Interfering with the raw string delimiters > (specifically, changing the identifier in the delimiter at either > end of the string) again took 90 seconds. And this is in your opinion reasonable performance? > 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.