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

[Eli Zaretskii <eliz@gnu.org>]

> Date: Thu, 4 Aug 2022 16:07:48 +0000
> Cc: 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>
> 
> > 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.

And how would you propose to solve that, given that it remains
unsolved for at least two decades?

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

Feel free to work on this.  If the results are better, we will
certainly prefer using it, and will then have to revisit the changes
we are discussing here, and decide whether they are still needed.

But we are not there yet, and it sounds wrong to me to prevent our
users from having a usable Emacs when editing these files just because
our ideal solutions are not yet available, when less ideal solutions
yield satisfactory results.

> > No, the current solution sacrifices some of the font-lock correctness
> > ....
> 
> "Sacrificing correctness" sounds like a euphemism for tolerating bugs.

Minor bugs.  Very minor 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.

Yes, we all love cheap and perfect solutions, don't we?  But there are
no such solutions in this case, so we need to choose among
not-so-cheap and not-so-perfect ones instead.

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

That's unfair, to say the least.  A lot of thought and discussions
went into these changes, even if you didn't notice them.  To say
nothing about the development and testing efforts.

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

That's the same thing.  You just see the empty 1/100th of the glass.

> > When there are long lines, they work slightly less correctly, ....
> 
> Correctness doesn't admit of degrees.  Something is either correct, or
> it's incorrect.

Then CC Mode is incorrect and broken, because it at times produces
wrong fontification and wrong indentation.  Let's throw it out.

> `widen' doesn't work at all in the pertinent circumstances.

Then make your mode avoid widening in those circumstances.

> > .... and the lack of correctness is only visible in the fontifications.
> 
> That hasn't been shown.

Show us any other problems, and then let's talk.

> Arbitrary Lisp can be executed through fontification-functions and
> all the hooks in font-lock.el and jit-lock.el.

Arbitrary Lisp can still be executed, it should just avoid going far
away from the window's display area when the buffer has very long
lines.  In particular, it should not begin from the beginning of a
line, nor insist on examining the entire line from BOL to EOL.

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

The Emacs project decided long ago that fontifications are important
in all modes.  That's why we have font-lock turned on by default; it
wasn't like that once upon a time.  But if you or someone prefers no
fontifications to fontifications that are sometimes, rarely,
incorrect, you can always turn off font-lock; the changes we are
discussing didn't take away that possibility.