Re: emacs master + org Wrong type argument: number-or-marker-p

[Eli Zaretskii <eliz@gnu.org>]

> Date: Thu, 4 Aug 2022 10:18:21 +0000
> Cc: Po Lu <luangruo@yahoo.com>, monnier@iro.umontreal.ca,
>   gregory@heytings.org, mattiase@acm.org, philipk@posteo.net,
>   silent2600@gmail.com, emacs-devel@gnu.org
> From: Alan Mackenzie <acm@muc.de>
> 
> > > And what if someone wants to write a fontification function whose
> > > results depend, for example, on a single character at a known position
> > > outside of the accessible region? That cannot result in a freeze
> 
> > I cannot reason about something as abstract and theoretical.
> 
> CC Mode is such a mode, though it depends on more than just a single
> character outside the accessible region.

And what catastrophic results does the current master produce with CC
Mode, when you edit files with very long lines, due to this narrowing?

> > Users did and do complain about locked-up Emacs when they try to edit
> > files with long lines.  They just didn't realize one of the reasons
> > was font-lock (or syntax-ppss), so they didn't complain specifically
> > about that.  But every complaint you see about these situations is
> > basically a complaint about font-lock and its syntax-parsing parts.
> 
> Has anybody asked the question why is font-lock so slow on these long
> lines?  The answer is surely not the use of widen and narrow-to-region.
> A piece of text takes exactly as long to fontify when its buffer is
> narrowed as when it is not.

Of course.  But the problem is that font-lock was found to examine
much larger portions of the buffer than the ones to which we now
restrict it in those cases.  And the speedup is evident.  What does
that tell you?

> I think (though I have not analysed it any further) the cause of this
> slowness is font-lock fontifying from BOL to EOL.  That's an awful lot of
> fontification if we have long lines.  If this is the case, a better
> solution to the problem would be to restrict the font-locked region to,
> say, the visible line.  Or to the window.  Or something like that.

That's what we do: we restrict it to somewhat more than fits in the
window.  But the files in questions have lines that are much longer
than that.

> The current "solution" breaks things, because it doesn't fix what is
> broken and fixes what isn't broken.  In particular, it breaks CC Mode
> when there are long lines in a buffer.

No, the current solution sacrifices some of the font-lock correctness
to give us a usable Emacs.  I say it's a justified tradeoff.

> > Anyway, this discussion doesn't lead anywhere.  We have decided to try
> > this way of solving a long-standing problem in Emacs, and no amount of
> > talking will cause us to change that decision.  Only code that makes
> > font-lock and syntax.c significantly faster, and/or reports about
> > specific issues (as opposed to general semi-philosophical concerns)
> > caused by these changes, can affect both the implementation of these
> > changes and our future decisions about its defaults.
> 
> I don't want to be provocative, but having opcodes that only work most of
> the time rather than all of the time isn't a mere semi-philosophical
> concern.

They work all the time when there are no long lines.  When there are
long lines, they work slightly less correctly, and the lack of
correctness is only visible in the fontifications.  Hardly a disaster,
if you keep in mind that one of the previously recommended solutions
was to turn on so-long-mode, which turns off font-lock (to tell
nothing of the not-so-distant past, when Emacs didn't have font-lock
at all).

IOW, it's a tradeoff: we give up some of the font-lock correctness,
and in return gain a usable Emacs.