From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Paul Pogonyshev Newsgroups: gmane.emacs.bugs Subject: bug#57804: An infinite loop in a `fontify-region' function causes Emacs to hang indefinitely Date: Fri, 16 Sep 2022 00:53:37 +0200 Message-ID: References: <2b58b8f5429a6e3aecda@heytings.org> <834jx85tyv.fsf@gnu.org> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="00000000000060672d05e8bf1e89" Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="3288"; mail-complaints-to="usenet@ciao.gmane.io" Cc: Eli Zaretskii , 57804@debbugs.gnu.org, Lars Ingebrigtsen To: Gregory Heytings Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Fri Sep 16 00:54:18 2022 Return-path: Envelope-to: geb-bug-gnu-emacs@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 1oYxkP-0000gE-Pg for geb-bug-gnu-emacs@m.gmane-mx.org; Fri, 16 Sep 2022 00:54:17 +0200 Original-Received: from localhost ([::1]:49946 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1oYxkM-0002lu-NG for geb-bug-gnu-emacs@m.gmane-mx.org; Thu, 15 Sep 2022 18:54:16 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:56972) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oYxkA-0002lh-N4 for bug-gnu-emacs@gnu.org; Thu, 15 Sep 2022 18:54:02 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:42572) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1oYxkA-0001sG-EE for bug-gnu-emacs@gnu.org; Thu, 15 Sep 2022 18:54:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1oYxkA-0001zs-4g for bug-gnu-emacs@gnu.org; Thu, 15 Sep 2022 18:54:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Paul Pogonyshev Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 15 Sep 2022 22:54:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 57804 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: wontfix Original-Received: via spool by 57804-submit@debbugs.gnu.org id=B57804.16632824417672 (code B ref 57804); Thu, 15 Sep 2022 22:54:02 +0000 Original-Received: (at 57804) by debbugs.gnu.org; 15 Sep 2022 22:54:01 +0000 Original-Received: from localhost ([127.0.0.1]:59504 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oYxk8-0001zc-Mg for submit@debbugs.gnu.org; Thu, 15 Sep 2022 18:54:01 -0400 Original-Received: from mail-ej1-f48.google.com ([209.85.218.48]:46631) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oYxk3-0001zL-GD for 57804@debbugs.gnu.org; Thu, 15 Sep 2022 18:53:58 -0400 Original-Received: by mail-ej1-f48.google.com with SMTP id bj12so45343151ejb.13 for <57804@debbugs.gnu.org>; Thu, 15 Sep 2022 15:53:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date; bh=QQWwvPwWm8LfFrOXczxHdbboT8HEl685eTC1eAHdYLc=; b=Wn7QlI9wsR1uNA/aB5U7xYRuROi44R/eUgTGNRnodVVKZ9mKed6vVWicwMnrd+J94O JV6syk5yR7b5IBAiFno1a1h0Bz1/tzR6MZzMhZyThCErUC4fPtejG/bMpjo2dqIG/ITj kfrbuc8oJMzn3adGSoSLCaRQGlWig7WbjteWH0ertVfqjpsUvgVIpkaQtR+UQC5CgZZq iGybw8oB7hye6wP0im5Q9zTZHOO8faetAmgimEs3z4tyoFNJflq3UVnhKNG7s8xket9t dOEks8IgHM8Zs8DQga65Jsg2sIq9qiAYIERhTCYZmqsy6Dbjm7pv3MJIhIt4wukI0+CG hykQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date; bh=QQWwvPwWm8LfFrOXczxHdbboT8HEl685eTC1eAHdYLc=; b=DMRoTadBifvCzmt/Z01ulEbCGQnquWXxLVuffnI50Di8JYx5jFwhqjW3nYJ63P2Twu UWnOeZ0rorTROZ4fgnJHSVUrkR/XX2fwBTEANX4+XtX/VGsNAWnauWv6LSaUb0U5YrLs ar2wo/o4X7UMCsX1eZvZpY+L62+W/cDqAixCi0VU50xTTsBZSPKT/Eb4fqwIeYCZ/Ugo JNl98HQ/TU5CvQ3cqi8Zggh2rT9cLuW4MQ3oGeP/PK6Lga9z0R3QSDpom8PhM0WOZM5f MQES8j5WiemJItkXL8tC8TunPBM2ODOPsvPwPasYBdtA6iKLQgDme6Buj7MpSSkfaucq 7Tgw== X-Gm-Message-State: ACrzQf33bKYc8WVH6u6ybtmdm9kuDAVnba/m64H9HH1lYRJxv41HhH1i xL5CN8X0GwuwukIG4RfQ5Q78JiO6tn9shbKEHA== X-Google-Smtp-Source: AMsMyM4LT7exmIP2udDrgxPK4TEh+F/ppYCBNQRrY8pSCbB+d1iCZDfWVXWJ8sJnGjInk8PI3M5SOXTgvhzUV5PokxA= X-Received: by 2002:a17:906:6a0e:b0:77c:a049:7cfc with SMTP id qw14-20020a1709066a0e00b0077ca0497cfcmr1402391ejc.732.1663282429583; Thu, 15 Sep 2022 15:53:49 -0700 (PDT) In-Reply-To: X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.io gmane.emacs.bugs:242666 Archived-At: --00000000000060672d05e8bf1e89 Content-Type: text/plain; charset="UTF-8" > > I don't know why, this is a hypothetical, but fairly realistic > > situation, right? > > Discussing hypothetical issues leads nowhere, according to my experience. > Let's focus on actual issues. I have shown you a simple way how your supposed can break things. Yes, it's not an everyday occurence, but if I could think of one easily, this or something else to this effect will be used in reality. As a reminder, Emacs self-advertises itself as "advanced, extensible" editor. You are making some extensions illegal, because maybe something somewhere might become slow. You are sacrificing functionality in the name of performance. > It is for example possible to parse the buffer outside of > fontification-functions You are ignoring that this is not only about fontification. It can happen anywhere, because I may need full access to the buffer at any time. > and to use the result of that parsing inside > fontification-functions. Parsing is done lazily. You are saying I need to prepare parsing results everywhere in the whole buffer at once (which easily can be 10 MB - I have seen logs 250 MB in size, but not ones with lines longer than ~50 K characters), because I don't know in advance where fontification (or whatever else) might be needed. > Yet another method would be to use a simpler fontification method in > buffers with too long lines. Yet another method would be to turn > font locking off in buffers with too long lines. I don't want to lose fontification in a 10 MB buffer because one line somewhere there is over 10000 characters. > Yet another method would be to truncate too long lines. Eh? And corrupt the log? Otherwise, even if it is invisible it stays in the buffer. > I also cannot understand why it is necessary, in log files in > which all lines are independent No they are not. Typically Java exceptions are logged like this: 2022-09-15 23:11:00.014 ERROR [some.Class] (some-thread) bla-bla-bla exception.Class: bla-bla-bla at some.Class and so on. Exceptions are not the only multiline entries. I have already complained about this often-seen-here "I also cannot understand", which implies "therefore no-one will ever need", but you said it was bad attitude from me. > > Will I be able to lift locked narrowing restrictions without knowing the > > tag? > > This is akin to a security mechanism, there is no reason to make it > possible to turn it off "too easily". Security against what, for fuck's sake? By trying to prevent "making it too easily", you are preventing this at all in general case. And what are the gains? Paul On Fri, 16 Sept 2022 at 00:16, Gregory Heytings wrote: > > > > > I don't know why, this is a hypothetical, but fairly realistic > > situation, right? > > > > Discussing hypothetical issues leads nowhere, according to my experience. > Let's focus on actual issues. > > > > > Now, let's say function `logview-do-bla-bla-bla' cannot work with > > narrowed buffer (half of functions in Logview cannot). > > > > You said I'm not allowed to tell you that your code could do things > differently, but that doesn't mean it isn't true. It is for example > possible to parse the buffer outside of fontification-functions and to use > the result of that parsing inside fontification-functions. Yet another > method would be to use a simpler fontification method in buffers with too > long lines. Yet another method would be to turn font locking off in > buffers with too long lines. Yet another method would be to truncate too > long lines. I also cannot understand why it is necessary, in log files in > which all lines are independent, to move beyond the beginning and end of a > line to decide how it must be fontified. > > > > > Will I be able to lift locked narrowing restrictions without knowing the > > tag? > > > > This is akin to a security mechanism, there is no reason to make it > possible to turn it off "too easily". > --00000000000060672d05e8bf1e89 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
> > I don't know why, this is a hypothetical, bu= t fairly realistic
> > situation, right?
>
> Discussi= ng hypothetical issues leads nowhere, according to my experience.
> L= et's focus on actual issues.

I have shown you a simple way how y= our supposed can break things. Yes,
it's not an everyday occurence, = but if I could think of one easily,
this or something else to this effec= t will be used in reality. As a
reminder, Emacs self-advertises itself a= s "advanced, extensible"
editor. You are making some extension= s illegal, because maybe
something somewhere might become slow. You are = sacrificing
functionality in the name of performance.

> It is = for example possible to parse the buffer outside of
> fontification-f= unctions

You are ignoring that this is not only about fontification.= It can
happen anywhere, because I may need full access to the buffer at= any
time.

> and to use the result of that parsing inside
&= gt; fontification-functions.

Parsing is done lazily. You are saying = I need to prepare parsing
results everywhere in the whole buffer at once= (which easily can be 10
MB - I have seen logs 250 MB in size, but not o= nes with lines longer
than ~50 K characters), because I don't know i= n advance where
fontification (or whatever else) might be needed.
> Yet another method would be to use a simpler fontification method in<= br>> buffers with too long lines.=C2=A0 Yet another method would be to t= urn
> font locking off in buffers with too long lines.

I don&#= 39;t want to lose fontification in a 10 MB buffer because one line
somew= here there is over 10000 characters.

> Yet another method would b= e to truncate too long lines.

Eh? And corrupt the log? Otherwise, ev= en if it is invisible it stays
in the buffer.

> I also cannot = understand why it is necessary, in log files in
> which all lines are= independent

No they are not. Typically Java exceptions are logged l= ike this:

=C2=A0 =C2=A0 2022-09-15 23:11:00.014 ERROR [some.Class] (= some-thread) bla-bla-bla
=C2=A0 =C2=A0 exception.Class: bla-bla-bla
= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 at some.Class

and so on. Exceptio= ns are not the only multiline entries.

I have already complained abo= ut this often-seen-here "I also cannot
understand", which impl= ies "therefore no-one will ever need", but you
said it was bad= attitude from me.

> > Will I be able to lift locked narr= owing restrictions without knowing the
> > tag?
>
> T= his is akin to a security mechanism, there is no reason to make it
> = possible to turn it off "too easily".

Security against wha= t, for fuck's sake? By trying to prevent "making
it too easily&= quot;, you are preventing this at all in general case. And
what are the = gains?

Paul

On Fri, 16 Sept 2022 at 00:16, Gregory Heytin= gs <gregory@heytings.org>= wrote:

>
> I don't know why, this is a hypothetical, but fairly realistic > situation, right?
>

Discussing hypothetical issues leads nowhere, according to my experience. <= br> Let's focus on actual issues.

>
> Now, let's say function `logview-do-bla-bla-bla' cannot work w= ith
> narrowed buffer (half of functions in Logview cannot).
>

You said I'm not allowed to tell you that your code could do things differently, but that doesn't mean it isn't true.=C2=A0 It is for e= xample
possible to parse the buffer outside of fontification-functions and to use =
the result of that parsing inside fontification-functions.=C2=A0 Yet anothe= r
method would be to use a simpler fontification method in buffers with too <= br> long lines.=C2=A0 Yet another method would be to turn font locking off in <= br> buffers with too long lines.=C2=A0 Yet another method would be to truncate = too
long lines.=C2=A0 I also cannot understand why it is necessary, in log file= s in
which all lines are independent, to move beyond the beginning and end of a =
line to decide how it must be fontified.

>
> Will I be able to lift locked narrowing restrictions without knowing t= he
> tag?
>

This is akin to a security mechanism, there is no reason to make it
possible to turn it off "too easily".
--00000000000060672d05e8bf1e89--