From mboxrd@z Thu Jan  1 00:00:00 1970
Path: news.gmane.org!.POSTED!not-for-mail
From: Ryan B <public@ryanb.org>
Newsgroups: gmane.emacs.devel
Subject: Re: Making font-lock handle long lines better
Date: Sun, 13 May 2018 12:44:09 -0700
Message-ID: <CA+caGh8DpwKKn3xMQFE+pqbHOVjWPf=Oc1ZJ5x==wCzEts28Aw@mail.gmail.com>
References: <CA+caGh_JN9FRi71VjUTwvYBKKygG-KuGGoe3GBgjthPRh00nRg@mail.gmail.com>
	<83wpcy2eun.fsf@gnu.org>
	<CAFXAjY4ED1L=T1zB-v=U-_DWbkOaO8+4cDidejBunS-RC3D7zQ@mail.gmail.com>
	<83lgtc3215.fsf@gnu.org>
	<CABr8ebY_0sUTmv_unYQSdZ4VjrCf3KNH3nnE2SW_sd-xEdU9+A@mail.gmail.com>
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: <emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org>
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 <emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org>)
	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 <emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org>)
	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 <public@ryanb.org>) 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 <public@ryanb.org>) 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 <public@ryanb.org>) 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 <public@ryanb.org>) 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 <emacs-devel@gnu.org>; 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: <CABr8ebY_0sUTmv_unYQSdZ4VjrCf3KNH3nnE2SW_sd-xEdU9+A@mail.gmail.com>
X-Gmail-Original-Message-ID: <CA+caGh8DpwKKn3xMQFE+pqbHOVjWPf=Oc1ZJ5x==wCzEts28Aw@mail.gmail.com>
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." <emacs-devel.gnu.org>
List-Unsubscribe: <https://lists.gnu.org/mailman/options/emacs-devel>,
	<mailto:emacs-devel-request@gnu.org?subject=unsubscribe>
List-Archive: <http://lists.gnu.org/archive/html/emacs-devel/>
List-Post: <mailto:emacs-devel@gnu.org>
List-Help: <mailto:emacs-devel-request@gnu.org?subject=help>
List-Subscribe: <https://lists.gnu.org/mailman/listinfo/emacs-devel>,
	<mailto:emacs-devel-request@gnu.org?subject=subscribe>
Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org
Original-Sender: "Emacs-devel" <emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org>
Xref: news.gmane.org gmane.emacs.devel:225278
Archived-At: <http://permalink.gmane.org/gmane.emacs.devel/225278>

--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 <andlind@gmail.com> 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

<div dir=3D"ltr"><div>for the record, i narrowed this down to the maven ele=
ment of `compilation-error-regexp-alist&#39;. if i remove that element, `co=
mpilation-mode&#39; is fast on the minimal test case in <a href=3D"https://=
debbugs.gnu.org/cgi/bugreport.cgi?bug=3D25682">https://debbugs.gnu.org/cgi/=
bugreport.cgi?bug=3D25682</a> .<br><br></div>it&#39;s evidently a somewhat =
known issue:<br><a href=3D"https://blog.danielgempesaw.com/post/12984168203=
0/fixing-a-laggy-compilation-buffer">https://blog.danielgempesaw.com/post/1=
29841682030/fixing-a-laggy-compilation-buffer</a><br><a href=3D"https://www=
.reddit.com/r/emacs/comments/2b2j5m/emacs_unresponsive_during_compilebuild/=
">https://www.reddit.com/r/emacs/comments/2b2j5m/emacs_unresponsive_during_=
compilebuild/</a><br><a href=3D"http://comments.gmane.org/gmane.emacs.bugs/=
28783">http://comments.gmane.org/gmane.emacs.bugs/28783</a>=C2=A0 (currentl=
y down)<br> <br></div><br><div class=3D"gmail_quote"><div dir=3D"ltr">On Sa=
t, Feb 11, 2017 at 3:09 PM Anders Lindgren &lt;<a href=3D"mailto:andlind@gm=
ail.com">andlind@gmail.com</a>&gt; wrote:<br></div><blockquote class=3D"gma=
il_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-lef=
t:1ex"><div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quot=
e"><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;bord=
er-left:1px solid rgb(204,204,204);padding-left:1ex">Since it&#39;s slow in=
 Fundamental mode as well, it&#39;s unrelated to<br>
font-lock, and thus to this thread.=C2=A0 Display of very long lines is<br>
known to be slow in Emacs.<br></blockquote><div><br></div><div>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).</div><div><br></div><di=
v>A quick experiment suggested that the problem is the member `font-lock-ex=
tend-region-wholelines&#39; of `font-lock-extend-region-functions&#39; 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.)</div><div><br></div><div>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&#39;t split in the middle of identifie=
rs.</div><div><br></div><div>=C2=A0 =C2=A0/ Anders</div><div><br></div><div=
>Ps. In case anybody is interested in looking further into this, you can us=
e the tool=C2=A0<a href=3D"https://github.com/Lindydancer/highlight-refonti=
fication" target=3D"_blank">https://github.com/Lindydancer/highlight-refont=
ification</a> to get visual feedback on the font-lock refontification proce=
ss.</div><div><br></div></div></div></div>
</blockquote></div><br clear=3D"all"><br>-- <br><div dir=3D"ltr" class=3D"g=
mail_signature" data-smartmail=3D"gmail_signature"><a href=3D"https://snarf=
ed.org/" target=3D"_blank">https://snarfed.org/</a></div>

--0000000000007ed3e0056c1b98df--