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

[Eli Zaretskii <eliz@gnu.org>]

> Date: Tue, 2 Aug 2022 20:28:42 +0000
> Cc: gregory@heytings.org, mattiase@acm.org, philipk@posteo.net,
>   silent2600@gmail.com, emacs-devel@gnu.org
> From: Alan Mackenzie <acm@muc.de>
> 
> > Not any Lisp programs, only those invoked from those hooks.
> 
> > And they won't necessarily fail.
> 
> No, they'll continue in a state different from that conceived by their
> creator.

Not necessarily.  Only if previously they forcefully widened the
buffer and looked beyond the restriction.

> Is that not a failure?

See above: not necessarily.

> > > There is not even a return code to say that a byte-code instruction
> > > has failed to work.
> 
> > A program can always test point-min and point-max.
> 
> A rigorous program MUST now test these.

Only if it MUST misbehave.

> > > Surely there should be an error signalled if such happens, since the
> > > program is broken after ignoring an instruction.
> 
> > It isn't broken, though.
> 
> I disagree fundamentally.  CC Mode, for example, uses widen and
> narrow-to-region all over the place, and surely other modes will too.
> When the opcodes break, so will these modes.

CC Mode is extremely unlikely to be in effect in files with such long
lines.  So you, as the CC Mode developer, can relax: these changes are
not relevant to CC Mode.

> > we don't let such programs run amok high and low in these extra-long
> > lines.
> 
> Using widen and narrow-to-region is hardly running amok.

It is, if the Lisp program then goes on to examine all the characters
from BOB to point.  It also is if the Lisp program insists to start
from the beginning of the line, no matter how far back that is.

> > > I protest also that this wasn't discussed openly on emacs-devel.
> 
> > It is being discussed, here and on the bug tracker, for about a month
> > now.
> 
> That's a month in which the discussion was open only to somebody who
> reads every post in the bug list, such as yourself, or who came upon the
> discussion by chance.  Others, such as me, were unaware of it.  It looks
> like the decision to change the byte code interpreter has already been
> taken, and I had no chance to participate in that process.

The byte code interpreter was yesterday changed back, so there's no
change there.

> Is it really right that fundamental changes to Emacs get discussed only
> on the bug list, or in secret[*] on emacs-devel?  [*]I.e. when the
> subject line is not explicit.

The Subject lines are not always explicit enough, that is true, but
there's nothing here specific to the discussion at hand, as it happens
all the time here.

And yes, if you don't want to miss important changes, you need wither
(a) read everything on the lists, or (b) track the committed changes
(e.g., via emacs-diffs@gnu.org), or both.  I see no way around that,
unless someone volunteers to set up some kind of notification service.