From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Ryan B Newsgroups: gmane.emacs.devel Subject: Re: Making font-lock handle long lines better Date: Sun, 13 May 2018 12:44:09 -0700 Message-ID: References: <83wpcy2eun.fsf@gnu.org> <83lgtc3215.fsf@gnu.org> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="0000000000007ed3e0056c1b98df" X-Trace: blaine.gmane.org 1526252011 16854 195.159.176.226 (13 May 2018 22:53:31 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sun, 13 May 2018 22:53:31 +0000 (UTC) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon May 14 00:53:27 2018 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1fHzrp-0004Hk-Ux for ged-emacs-devel@m.gmane.org; Mon, 14 May 2018 00:53:26 +0200 Original-Received: from localhost ([::1]:33637 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fHztw-0006a6-UH for ged-emacs-devel@m.gmane.org; Sun, 13 May 2018 18:55:36 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:48585) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fHzOx-0005GM-9X for emacs-devel@gnu.org; Sun, 13 May 2018 18:23:38 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1fHwuw-0008V7-Bl for emacs-devel@gnu.org; Sun, 13 May 2018 15:44:29 -0400 Original-Received: from smtp1.cs.stanford.edu ([171.64.64.25]:48695) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1fHwuw-0008Ud-4s for emacs-devel@gnu.org; Sun, 13 May 2018 15:44:26 -0400 Original-Received: from mail-ua0-f173.google.com ([209.85.217.173]:35136) by smtp1.cs.Stanford.EDU with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.90_1) (envelope-from ) id 1fHwus-00081x-Kt for emacs-devel@gnu.org; Sun, 13 May 2018 12:44:23 -0700 Original-Received: by mail-ua0-f173.google.com with SMTP id a2-v6so6950924uak.2 for ; Sun, 13 May 2018 12:44:22 -0700 (PDT) X-Gm-Message-State: ALKqPwcJJFc8JL0hkI3npQnJNBK7prAsNAmwEoeJvWWKeFNcx9fK4e6c 6r/3VzlxgIwXyNMdFAnl+aJTef+0LfCpYrSdz5I= X-Google-Smtp-Source: AB8JxZpzoGnx+N3lxOt2vba9MpCREoFxFhzUDNNV8j/MxpTvjoyvy5V1U8hOi0J7aPj87JrYnUOHwGMvxuqiS7wceKY= X-Received: by 2002:ab0:7039:: with SMTP id u25-v6mr8788559ual.60.1526240661916; Sun, 13 May 2018 12:44:21 -0700 (PDT) In-Reply-To: X-Gmail-Original-Message-ID: X-Scan-Signature: dfe9a19d2d5d3f4658608889c96f7beb X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x [fuzzy] X-Received-From: 171.64.64.25 X-Mailman-Approved-At: Sun, 13 May 2018 18:54:36 -0400 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.21 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.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.org gmane.emacs.devel:225278 Archived-At: --0000000000007ed3e0056c1b98df Content-Type: text/plain; charset="UTF-8" for the record, i narrowed this down to the maven element of `compilation-error-regexp-alist'. if i remove that element, `compilation-mode' is fast on the minimal test case in https://debbugs.gnu.org/cgi/bugreport.cgi?bug=25682 . it's evidently a somewhat known issue: https://blog.danielgempesaw.com/post/129841682030/fixing-a-laggy-compilation-buffer https://www.reddit.com/r/emacs/comments/2b2j5m/emacs_unresponsive_during_compilebuild/ http://comments.gmane.org/gmane.emacs.bugs/28783 (currently down) On Sat, Feb 11, 2017 at 3:09 PM Anders Lindgren wrote: > Since it's slow in Fundamental mode as well, it's unrelated to >> font-lock, and thus to this thread. Display of very long lines is >> known to be slow in Emacs. >> > > I believe this is a font-lock problem. If you disable > global-font-lock-mode before you open the file, it opens in seconds. If > global-font-lock-mode is active Emacs stops responding (I gave up after a > few minutes). > > A quick experiment suggested that the problem is the member > `font-lock-extend-region-wholelines' of `font-lock-extend-region-functions' > that ensures that whenever font-lock highlights keywords in a region, the > full line is rehighlighted (in the case of the example, the full 18M). By > removing it, font-locking the file is done in seconds. (I assume that only > the visible parts of the buffer is highlighted.) > > Clearly, simple dropping the function is not a good idea, as keyword > fontification could start anywhere on the line, e.g. in the middle of > identifiers. A better approach would be to extend the region to include > 10KB in either direction, plus ensure that the region isn't split in the > middle of identifiers. > > / Anders > > Ps. In case anybody is interested in looking further into this, you can > use the tool https://github.com/Lindydancer/highlight-refontification to > get visual feedback on the font-lock refontification process. > > -- https://snarfed.org/ --0000000000007ed3e0056c1b98df Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
for the record, i narrowed this down to the maven ele= ment of `compilation-error-regexp-alist'. if i remove that element, `co= mpilation-mode' is fast on the minimal test case in https://debbugs.gnu.org/cgi/= bugreport.cgi?bug=3D25682 .

it's evidently a somewhat = known issue:
https://blog.danielgempesaw.com/post/1= 29841682030/fixing-a-laggy-compilation-buffer
https://www.reddit.com/r/emacs/comments/2b2j5m/emacs_unresponsive_during_= compilebuild/
http://comments.gmane.org/gmane.emacs.bugs/28783=C2=A0 (currentl= y down)


On Sa= t, Feb 11, 2017 at 3:09 PM Anders Lindgren <andlind@gmail.com> wrote:
Since it's slow in= Fundamental mode as well, it's unrelated to
font-lock, and thus to this thread.=C2=A0 Display of very long lines is
known to be slow in Emacs.

I believe th= is is a font-lock problem. If you disable global-font-lock-mode before you = open the file, it opens in seconds. If global-font-lock-mode is active Emac= s stops responding (I gave up after a few minutes).

A quick experiment suggested that the problem is the member `font-lock-ex= tend-region-wholelines' of `font-lock-extend-region-functions' that= ensures that whenever font-lock highlights keywords in a region, the full = line is rehighlighted (in the case of the example, the full 18M). By removi= ng it, font-locking the file is done in seconds. (I assume that only the vi= sible parts of the buffer is highlighted.)

Clearly= , simple dropping the function is not a good idea, as keyword fontification= could start anywhere on the line, e.g. in the middle of identifiers. A bet= ter approach would be to extend the region to include 10KB in either direct= ion, plus ensure that the region isn't split in the middle of identifie= rs.

=C2=A0 =C2=A0/ Anders

Ps. In case anybody is interested in looking further into this, you can us= e the tool=C2=A0https://github.com/Lindydancer/highlight-refont= ification to get visual feedback on the font-lock refontification proce= ss.



--
--0000000000007ed3e0056c1b98df--