GNU bug report logs - #57009
Obscure doc string of new variable syntax-wholeline-max

Previous Next

Package: emacs;

Reported by: Alan Mackenzie <acm <at> muc.de>

Date: Fri, 5 Aug 2022 21:37:02 UTC

Severity: minor

To reply to this bug, email your comments to 57009 AT debbugs.gnu.org.

Toggle the display of automated, internal messages from the tracker.

View this report as an mbox folder, status mbox, maintainer mbox


Report forwarded to bug-gnu-emacs <at> gnu.org:
bug#57009; Package emacs. (Fri, 05 Aug 2022 21:37:02 GMT) Full text and rfc822 format available.

Acknowledgement sent to Alan Mackenzie <acm <at> muc.de>:
New bug report received and forwarded. Copy sent to bug-gnu-emacs <at> gnu.org. (Fri, 05 Aug 2022 21:37:02 GMT) Full text and rfc822 format available.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Alan Mackenzie <acm <at> muc.de>
To: bug-gnu-emacs <at> gnu.org
Subject: Obscure doc string of new variable syntax-wholeline-max
Date: Fri, 5 Aug 2022 21:35:59 +0000
Hello, Emacs.

I came across the variable syntax-wholeline-max in reading a new bug
archive.  Its doc string, in full, is:

    syntax-wholeline-max is a variable defined in `syntax.el'.

    Its value is 10000

    Maximum line length for syntax operations.
    If lines are longer than that, syntax operations will treat them as chunks
    of this size.  Misfontification may then occur.
    This is a tradeoff between correctly applying the syntax rules,
    and avoiding major slowdown on pathologically long lines.

      Probably introduced at or before Emacs version 29.1.

..  There are several bugs here:
(i) It is not clear what is meant by "syntax operations".  These should
  be listed and if necessary, explained.
(ii) It is not clear what it means for a "syntax operation" to treat a
  line "as a chunk".  This should be explained.
(iii) "Misfontification" may well occur, but what about other bad effects
  of ignoring correct syntax?  Don't they deserve a mention?
(iv) There is no mention of a mechanism to disable this "chunking"
  effect, whatever it might be.  If there is one, it should be
  documented, if there's not, this should be stated.

I'm not asking for an explanation of these things.  I can look up the
source code and work it out.  I'm asking them to be fixed so that other
people don't also have to read the source code.

-- 
Alan Mackenzie (Nuremberg, Germany).




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#57009; Package emacs. (Sat, 06 Aug 2022 12:57:02 GMT) Full text and rfc822 format available.

Message #8 received at 57009 <at> debbugs.gnu.org (full text, mbox):

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Alan Mackenzie <acm <at> muc.de>
Cc: Stefan Monnier <monnier <at> iro.umontreal.ca>, 57009 <at> debbugs.gnu.org
Subject: Re: bug#57009: Obscure doc string of new variable syntax-wholeline-max
Date: Sat, 06 Aug 2022 14:56:24 +0200
Alan Mackenzie <acm <at> muc.de> writes:

>     Maximum line length for syntax operations.
>     If lines are longer than that, syntax operations will treat them as chunks
>     of this size.  Misfontification may then occur.
>     This is a tradeoff between correctly applying the syntax rules,
>     and avoiding major slowdown on pathologically long lines.
>
>       Probably introduced at or before Emacs version 29.1.
>
> ..  There are several bugs here:
> (i) It is not clear what is meant by "syntax operations".  These should
>   be listed and if necessary, explained.

You mean mention syntax-ppss?

> (ii) It is not clear what it means for a "syntax operation" to treat a
>   line "as a chunk".  This should be explained.

It's saying that it's processing the line chunk-wise.  I think that's
pretty clear?

> (iii) "Misfontification" may well occur, but what about other bad effects
>   of ignoring correct syntax?  Don't they deserve a mention?

Do they?

> (iv) There is no mention of a mechanism to disable this "chunking"
>   effect, whatever it might be.  If there is one, it should be
>   documented, if there's not, this should be stated.

That seems self-evident -- you increase the size?

There doesn't really seem to be much to alter here to me, but perhaps
others have other opinions; adding Stefan to the CCs.





Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#57009; Package emacs. (Sat, 06 Aug 2022 14:33:01 GMT) Full text and rfc822 format available.

Message #11 received at 57009 <at> debbugs.gnu.org (full text, mbox):

From: Alan Mackenzie <acm <at> muc.de>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: Stefan Monnier <monnier <at> iro.umontreal.ca>, 57009 <at> debbugs.gnu.org
Subject: Re: bug#57009: Obscure doc string of new variable syntax-wholeline-max
Date: Sat, 6 Aug 2022 14:32:11 +0000
Hello, Lars.

On Sat, Aug 06, 2022 at 14:56:24 +0200, Lars Ingebrigtsen wrote:
> Alan Mackenzie <acm <at> muc.de> writes:

> >     Maximum line length for syntax operations.
> >     If lines are longer than that, syntax operations will treat them as chunks
> >     of this size.  Misfontification may then occur.
> >     This is a tradeoff between correctly applying the syntax rules,
> >     and avoiding major slowdown on pathologically long lines.

> >       Probably introduced at or before Emacs version 29.1.

> > ..  There are several bugs here:
> > (i) It is not clear what is meant by "syntax operations".  These should
> >   be listed and if necessary, explained.

> You mean mention syntax-ppss?

Yes, if that is one of the operations involved.  Also, if pertinent,
parse-partial-sexp, forward-list and friends, syntax-propertize, ....

> > (ii) It is not clear what it means for a "syntax operation" to treat a
> >   line "as a chunk".  This should be explained.

> It's saying that it's processing the line chunk-wise.  I think that's
> pretty clear?

If it's clear to you, please explain in a way that's clear to me.  :-)

Say the chunk is 64 characters long.  Doesn't parse-partial-sexp process
that "as a chunk" anyway?  How does one determine where a "chunk" starts
and where it ends?  What does "treating a line as a chunk" do that is new
that we didn't do before?

> > (iii) "Misfontification" may well occur, but what about other bad effects
> >   of ignoring correct syntax?  Don't they deserve a mention?

> Do they?

They might, it depends how clear the rest of an amended text makes
things.  For example, will C-M-n still work?

> > (iv) There is no mention of a mechanism to disable this "chunking"
> >   effect, whatever it might be.  If there is one, it should be
> >   documented, if there's not, this should be stated.

> That seems self-evident -- you increase the size?

It is anything but self-evident.  It might be by setting the variable to
0, it might be by setting it to nil, it might be, as you suggest by
setting it to a larger size than you think will occur in practice (i.e.
there's no way to disable it).  All these ways are in use in Emacs.

> There doesn't really seem to be much to alter here to me, but perhaps
> others have other opinions; adding Stefan to the CCs.

As matters stand, I'd have to read the source code to work out what this
variable is for.  I don't think I should have to.

-- 
Alan Mackenzie (Nuremberg, Germany).




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#57009; Package emacs. (Sun, 07 Aug 2022 12:47:03 GMT) Full text and rfc822 format available.

Message #14 received at 57009 <at> debbugs.gnu.org (full text, mbox):

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Alan Mackenzie <acm <at> muc.de>
Cc: Stefan Monnier <monnier <at> iro.umontreal.ca>, 57009 <at> debbugs.gnu.org
Subject: Re: bug#57009: Obscure doc string of new variable syntax-wholeline-max
Date: Sun, 07 Aug 2022 14:46:25 +0200
Alan Mackenzie <acm <at> muc.de> writes:

> Say the chunk is 64 characters long.  Doesn't parse-partial-sexp process
> that "as a chunk" anyway?  How does one determine where a "chunk" starts
> and where it ends?  What does "treating a line as a chunk" do that is new
> that we didn't do before?

I interpret that as saying that the line is split into chunks (of the
length the variable says) and processed one after the other.

> It is anything but self-evident.  It might be by setting the variable to
> 0, it might be by setting it to nil, it might be, as you suggest by
> setting it to a larger size than you think will occur in practice (i.e.
> there's no way to disable it).  All these ways are in use in Emacs.

Yes, that's true.




This bug report was last modified 2 years and 311 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.