Re: Errors in interactive commands

[Lennart Borgman <lennart.borgman@gmail.com>]

On Wed, Aug 3, 2011 at 09:28, Stephen J. Turnbull <stephen@xemacs.org> wrote:
> Andreas Röhler writes:
>
>  > A move-forward at the end of the buffer isn't a wrong command as such,
>  > just will not be successful.
>  >
>  > Therefor it should not be raised an error, just nil returned.
>
> This is problematic, IMO.  Suppose you have a buffer which is supposed
> to have an even number of objects in it, and you want to delete every
> second then.  Then
>
> (progn
>  (goto (point-min))
>  (while (not (eobp))
>    (forward-object 2)
>    (delete-object -1)))
>
> DTRTs, including detecting the "incorrect state" of an odd number of
> objects, and not deleting the first object on an incomplete last line.
>
> If you're going to change the behavior of the movement commands here,
> I think it would be better to have them return the number of objects
> left to move over.  Then 0 would mean (complete) success (how Un*x-y!)
>
> But this would be a major change.

Examples such like this one is why I propose using something like
(throw 'command-level) instead of raising an error.

Of course the catch tag 'command-level does not exist and I propose
adding it in the C code command loops in so that (throw
'command-level) gives an execution path similar to (error 'something).
In this way I think we will get rather few compatibility problems.

Maybe this can be introduced in debug-ignored-errors?