From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Alan Mackenzie Newsgroups: gmane.emacs.devel Subject: Re: How the long-lines "optimisation" breaks font locking. Date: Thu, 4 Aug 2022 10:44:05 +0000 Message-ID: References: <87y1w5tahv.fsf@gnus.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="18892"; mail-complaints-to="usenet@ciao.gmane.io" Cc: emacs-devel@gnu.org, Gregory Heytings To: Lars Ingebrigtsen Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Thu Aug 04 12:47:20 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 1oJYNr-0004dK-Ns for ged-emacs-devel@m.gmane-mx.org; Thu, 04 Aug 2022 12:47:19 +0200 Original-Received: from localhost ([::1]:48354 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1oJYNq-0006W6-5m for ged-emacs-devel@m.gmane-mx.org; Thu, 04 Aug 2022 06:47:18 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:48010) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oJYKx-0005Uq-Cp for emacs-devel@gnu.org; Thu, 04 Aug 2022 06:44:20 -0400 Original-Received: from colin.muc.de ([193.149.48.1]:23487 helo=mail.muc.de) by eggs.gnu.org with smtp (Exim 4.90_1) (envelope-from ) id 1oJYKq-0000kM-Jk for emacs-devel@gnu.org; Thu, 04 Aug 2022 06:44:15 -0400 Original-Received: (qmail 58796 invoked by uid 3782); 4 Aug 2022 10:44:09 -0000 Original-Received: from acm.muc.de (p4fe15d23.dip0.t-ipconnect.de [79.225.93.35]) (using STARTTLS) by colin.muc.de (tmda-ofmipd) with ESMTP; Thu, 04 Aug 2022 12:44:09 +0200 Original-Received: (qmail 7330 invoked by uid 1000); 4 Aug 2022 10:44:05 -0000 Content-Disposition: inline In-Reply-To: <87y1w5tahv.fsf@gnus.org> X-Submission-Agent: TMDA/1.3.x (Ph3nix) X-Primary-Address: acm@muc.de Received-SPF: pass client-ip=193.149.48.1; envelope-from=acm@muc.de; helo=mail.muc.de X-Spam_score_int: -18 X-Spam_score: -1.9 X-Spam_bar: - X-Spam_report: (-1.9 / 5.0 requ) BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01 autolearn=ham autolearn_force=no X-Spam_action: no action 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:293053 Archived-At: 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. > .... 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. Having loaded the file in C++ Mode (without the spiking of narrow-to-region and widen), it took 90 seconds for M-> (first time). Moving point was sluggish, taking perhaps 1 to 3 seconds, as did scrolling by a screenful. 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. 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. > Which is the point here. -- Alan Mackenzie (Nuremberg, Germany).