unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
* bug#57009: Obscure doc string of new variable syntax-wholeline-max
@ 2022-08-05 21:35 Alan Mackenzie
  2022-08-06 12:56 ` Lars Ingebrigtsen
  0 siblings, 1 reply; 4+ messages in thread
From: Alan Mackenzie @ 2022-08-05 21:35 UTC (permalink / raw)
  To: 57009

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).





^ permalink raw reply	[flat|nested] 4+ messages in thread

* bug#57009: Obscure doc string of new variable syntax-wholeline-max
  2022-08-05 21:35 bug#57009: Obscure doc string of new variable syntax-wholeline-max Alan Mackenzie
@ 2022-08-06 12:56 ` Lars Ingebrigtsen
  2022-08-06 14:32   ` Alan Mackenzie
  0 siblings, 1 reply; 4+ messages in thread
From: Lars Ingebrigtsen @ 2022-08-06 12:56 UTC (permalink / raw)
  To: Alan Mackenzie; +Cc: Stefan Monnier, 57009

Alan Mackenzie <acm@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.






^ permalink raw reply	[flat|nested] 4+ messages in thread

* bug#57009: Obscure doc string of new variable syntax-wholeline-max
  2022-08-06 12:56 ` Lars Ingebrigtsen
@ 2022-08-06 14:32   ` Alan Mackenzie
  2022-08-07 12:46     ` Lars Ingebrigtsen
  0 siblings, 1 reply; 4+ messages in thread
From: Alan Mackenzie @ 2022-08-06 14:32 UTC (permalink / raw)
  To: Lars Ingebrigtsen; +Cc: Stefan Monnier, 57009

Hello, Lars.

On Sat, Aug 06, 2022 at 14:56:24 +0200, Lars Ingebrigtsen wrote:
> Alan Mackenzie <acm@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).





^ permalink raw reply	[flat|nested] 4+ messages in thread

* bug#57009: Obscure doc string of new variable syntax-wholeline-max
  2022-08-06 14:32   ` Alan Mackenzie
@ 2022-08-07 12:46     ` Lars Ingebrigtsen
  0 siblings, 0 replies; 4+ messages in thread
From: Lars Ingebrigtsen @ 2022-08-07 12:46 UTC (permalink / raw)
  To: Alan Mackenzie; +Cc: Stefan Monnier, 57009

Alan Mackenzie <acm@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.





^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, other threads:[~2022-08-07 12:46 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2022-08-05 21:35 bug#57009: Obscure doc string of new variable syntax-wholeline-max Alan Mackenzie
2022-08-06 12:56 ` Lars Ingebrigtsen
2022-08-06 14:32   ` Alan Mackenzie
2022-08-07 12:46     ` Lars Ingebrigtsen

Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).