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

[Alan Mackenzie]

Hello, Eli.

On Tue, Aug 02, 2022 at 22:15:37 +0300, Eli Zaretskii wrote:
> > Date: Tue, 2 Aug 2022 18:59:07 +0000
> > Cc: gregory@heytings.org, mattiase@acm.org, philipk@posteo.net,
> >   silent2600@gmail.com, emacs-devel@gnu.org
> > From: Alan Mackenzie <acm@muc.de>

> > > This happens only in buffers with very long lines, where we want to
> > > prevent Lisp programs called from low-level facilities, like
> > > redisplay, to scan the entire buffer.

> > So Lisp programs will "only" fail to work in buffers with long lines.  I
> > protest at this.

> 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.  Is that not a failure?

> In fact, we have yet to see a single serious failure due to these
> measures.  In general, the restriction is large enough to satisfy any
> reasonable processing, so it shouldn't matter unless the Lisp program
> misbehaves.

> > There surely could have been a solution to whatever
> > the problem was that respected the integrity of the Lisp machine.

> Theoretically, yes.  But in practice, Emacs had this problem since 22
> years ago, and no solution presented itself.

> > 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.  This is such a horrible
artifact that it won't get done most of the time.

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

> > Ignoring what a programmer programmed cannot be a good strategy.

> It isn't ignored, just restricted:

There are no safety fences of any sort.  The meaning of a program using
w and n-t-r is no longer determinate.

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

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

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.

Anyhow, I wanted to protest and I have done so.  The arguments between
the two of us here about widen and n-t-r are clearly not going anywhere,
so I don't intend to continue them.  I won't feel put out if you don't
want to answer them.

-- 
Alan Mackenzie (Nuremberg, Germany).