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

[Alan Mackenzie <acm@muc.de>]

Hello, Eli.

On Thu, Aug 04, 2022 at 16:18:40 +0300, Eli Zaretskii wrote:
> > 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?

This isn't yet known.  There is no evidence, no argument even, that such
"catastrophic results" won't occur.  Wrong fontification is already
evident.

[ .... ]

> > 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?

That you can speed things up by omitting part of the work.  Possibly that
font-lock is insufficiently flexible in what it offers major modes.

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

I meant doing this in a way which doesn't introduce bugs.  Something like
amending/replacing font-lock-extend-region-wholelines, for example.

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

"Sacrificing correctness" sounds like a euphemism for tolerating bugs.

> .... to give us a usable Emacs.  I say it's a justified tradeoff.

Better would be to get a usable Emacs without introducing bugs.  CC Mode
(amongst other packages) is a victim of this tradeoff, yet I wasn't
alerted to the decision being taken, I just found out about it by chance.
I CARE about the correctness of CC Mode, and have spent a lot of time and
energy over the last 20 years tending to it.  Now it's being sacrificed,
even if only in an edge case, with barely a second thought - along with
an unknown number of other packages.

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

They don't work all the time, since sometimes there are long lines.

> When there are long lines, they work slightly less correctly, ....

Correctness doesn't admit of degrees.  Something is either correct, or
it's incorrect.

`widen' doesn't work at all in the pertinent circumstances.  It is as
though somebody unconnected with a project steals into the source code
and secretly removes `(widen)' and `(narrow-to-region ...)' without
telling the maintainer, who'll likely have to debug things later.
 
> .... and the lack of correctness is only visible in the fontifications.

That hasn't been shown.  Arbitrary Lisp can be executed through
fontification-functions and all the hooks in font-lock.el and
jit-lock.el.

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

Do these long lines occur in modes where fontification is important?  I
don't know as I haven't seen any test files.

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

-- 
Alan Mackenzie (Nuremberg, Germany).