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

[Alan Mackenzie <acm@muc.de>]

Hello, Eli.

On Thu, Aug 04, 2022 at 12:06:45 +0300, Eli Zaretskii wrote:
> > From: Po Lu <luangruo@yahoo.com>
> > Cc: monnier@iro.umontreal.ca,  acm@muc.de,  gregory@heytings.org,
> >   mattiase@acm.org,  philipk@posteo.net,  silent2600@gmail.com,
> >   emacs-devel@gnu.org
> > Date: Thu, 04 Aug 2022 16:42:33 +0800

> > Eli Zaretskii <eliz@gnu.org> writes:

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

[ .... ]

> > I'm just trying to demonstrate what will happen once the forced
> > narrowing starts to interfere with the operation of various pieces of
> > third party code, which might possibly be discovered some time after
> > Emacs 29 is released.  Long-running fontification was not a
> > significant source of complaints for their developers in the past,
> > and things are likely to remain that way.

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

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.

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.

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

-- 
Alan Mackenzie (Nuremberg, Germany).