[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Eli Zaretskii
Subject: Re: emacs master + org Wrong type argument: number-or-marker-p
Date: Tue, 02 Aug 2022 22:15:37 +0300

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

> Surely there should be an error signalled if such happens, since the
> program is broken after ignoring an instruction.

It isn't broken, though.

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

It isn't ignored, just restricted: we don't let such programs run amok
high and low in these extra-long lines.

> 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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]