Errors in interactive commands

Errors in interactive commands

[Antoine Levitt]

What's the policy concerning errors in interactive commands when they
are called from an invalid context? Right now emacs is a bit
inconsistent: C-f at the end of a buffer displays a message, while C-M-f
inside an empty parenthesis pair raises an error. We should decide on a
standard and apply it to every such command (I'm willing to do it.)

I'm personally in favour of displaying a message, because it makes
editing with toggle-debug-on-error less painful. What do others think?

Re: Errors in interactive commands

[Andreas Röhler]

Am 02.08.2011 19:46, schrieb Antoine Levitt:
> What's the policy concerning errors in interactive commands when they
> are called from an invalid context? Right now emacs is a bit
> inconsistent: C-f at the end of a buffer displays a message, while C-M-f

Hi,

thats a bug IMHO, like the error with point at closing string:

("foo")
-----^--

-->
forward-sexp: Scan error: "Unbalanced parentheses", 6, 8

> inside an empty parenthesis pair raises an error. We should decide on a
> standard and apply it to every such command (I'm willing to do it.)
>
> I'm personally in favour of displaying a message, because it makes
> editing with toggle-debug-on-error less painful. What do others think?
>
>
>


please permit raising the return-value question again at the occasion:

It's very convenient IMHO, when using a function which move, being able 
to check for example the returned position like

(eq 123 (ar-forward-word-atpt))

;; https://launchpad.net/s-x-emacs-werkstatt/


which would return at the end buffer nil, not an error, so a while will 
stop smoothly.

Messaging should be the respective, ie functions interactively called 
should message it's return values beside returning.

Andreas

Re: Errors in interactive commands

[Lennart Borgman]

On Tue, Aug 2, 2011 at 19:46, Antoine Levitt <antoine.levitt@gmail.com> wrote:
> What's the policy concerning errors in interactive commands when they
> are called from an invalid context? Right now emacs is a bit
> inconsistent: C-f at the end of a buffer displays a message, while C-M-f
> inside an empty parenthesis pair raises an error. We should decide on a
> standard and apply it to every such command (I'm willing to do it.)
>
> I'm personally in favour of displaying a message, because it makes
> editing with toggle-debug-on-error less painful. What do others think?

In my opinion interactive commands should never raise an error.

Unless of course there is an error - not just a "bad" user behaviour.
The user behaviour might instead throw to a catch label that normally
just continues the command loop (but can be catched too).

We have discussed this before and I have suggested the same thing
then. In my opinion it is important. I guess some people might agree,
but so far no one has had time to:

1) Suggest the policy (oh, yes, I did).
2) Get agreement.
3) Implement.

Re: Errors in interactive commands

[Lars Magne Ingebrigtsen]

Lennart Borgman <lennart.borgman@gmail.com> writes:

> In my opinion interactive commands should never raise an error.

I'm kinda of the opposite opinion.  Non-interactive functions should
raise errors less than they do currently.

I think it's fine for, say, `left-char' to raise an error if point is a
the beginning of buffer.

-- 
(domestic pets only, the antidote for overdose, milk.)
  bloggy blog http://lars.ingebrigtsen.no/

Re: Errors in interactive commands

[Stephen J. Turnbull]

Lennart Borgman writes:

 > In my opinion interactive commands should never raise an error.

You mean "commands invoked interactively," (aka
called-interactively-p), right?

Re: Errors in interactive commands

[Lennart Borgman]

On Wed, Aug 3, 2011 at 09:13, Stephen J. Turnbull <stephen@xemacs.org> wrote:
> Lennart Borgman writes:
>
>  > In my opinion interactive commands should never raise an error.
>
> You mean "commands invoked interactively," (aka
> called-interactively-p), right?

Yes, of course.

Re: Errors in interactive commands

[Stefan Monnier]

> I'm personally in favour of displaying a message, because it makes
> editing with toggle-debug-on-error less painful. What do others think?

debug-ignored-errors should make this concern irrelevant for the
decision of which behavior to choose.


        Stefan

Re: Errors in interactive commands

[Lennart Borgman]

On Tue, Aug 2, 2011 at 21:25, Stefan Monnier <monnier@iro.umontreal.ca> wrote:
>> I'm personally in favour of displaying a message, because it makes
>> editing with toggle-debug-on-error less painful. What do others think?
>
> debug-ignored-errors should make this concern irrelevant for the
> decision of which behavior to choose.

The reason some commands raises an error is that they want to give
control back to the command loop. debug-ignore-errors can't fix that,
or?

Re: Errors in interactive commands

[Andreas Röhler]

Am 02.08.2011 21:36, schrieb Lennart Borgman:
> On Tue, Aug 2, 2011 at 21:25, Stefan Monnier<monnier@iro.umontreal.ca>  wrote:
>>> I'm personally in favour of displaying a message, because it makes
>>> editing with toggle-debug-on-error less painful. What do others think?
>>
>> debug-ignored-errors should make this concern irrelevant for the
>> decision of which behavior to choose.
>
> The reason some commands raises an error is that they want to give
> control back to the command loop. debug-ignore-errors can't fix that,
> or?
>
>

Hi,

think it might pay to invest some more into such a consideration - the 
diff between an error and nil.

An error should be raised if something like a danger exists:
division through zero.

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.

People may write (while (forward-my-function

until encountering nil then.

Cheers,

Andreas

Re: Errors in interactive commands

[Stephen J. Turnbull]

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.

Re: Errors in interactive commands

[Andreas Röhler]

Am 03.08.2011 09:28, schrieb Stephen J. Turnbull:
> 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.
>
>

Hi Steve,

thanks verifying.

Nonetheless think arguments are wrong here, mixing up two levels of 
execution.

To get what you want, it's a state-of-affairs variable to introduce 
pointing at the action.

Ie 'Delete-every-second' is the matter at stake, whilst "forward-" below 
resp. inside.

With a little bit pseudo-code introduced:

  (progn
     (goto (point-min))
     (while (and (QUERY Delete-every-second-state)(not (eobp)))
       (forward-object 2)
       (delete-object -1)
       (UPDATE Delete-every-second-state)))

Useful return values of "forward-" is important for a wide range of 
things, not just to serve several specific cases.

Sorting execution levels might be the term at stake.
Would like to read another term from experts. Pretty sure exists some in 
informatics.

Andreas

Re: Errors in interactive commands

[David Kastrup]

Andreas Röhler <andreas.roehler@online.de> writes:

> Am 03.08.2011 09:28, schrieb Stephen J. Turnbull:
>> 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.

[...]

> Nonetheless think arguments are wrong here, mixing up two levels of
> execution.
>
> To get what you want, it's a state-of-affairs variable to introduce
> pointing at the action.
>
> Ie 'Delete-every-second' is the matter at stake, whilst "forward-"
> below resp. inside.
>
> With a little bit pseudo-code introduced:
>
>  (progn
>     (goto (point-min))
>     (while (and (QUERY Delete-every-second-state)(not (eobp)))
>       (forward-object 2)
>       (delete-object -1)
>       (UPDATE Delete-every-second-state)))
>
> Useful return values of "forward-" is important for a wide range of
> things, not just to serve several specific cases.
>
> Sorting execution levels might be the term at stake.
> Would like to read another term from experts. Pretty sure exists some
> in informatics.

I consider it likely that most experts would take the term
"befuddlement" into close consideration.  I consistently fail to
recognize a logical connection between your postings and what they are
supposed to be a reply to.

-- 
David Kastrup

Re: Errors in interactive commands

[Andreas Röhler]

   I consistently fail to
> recognize a logical connection between your postings and what they are
> supposed to be a reply to.
>

can't question your experiences, looking for the very reasons would 
definitly surpass the topics of this list - even if being of some wider 
interest. :)

BTW: the truth, is the truth, is the truth.

No outcome from it.

As it's a light too and finally a consolation, face it.

Re: Errors in interactive commands

[Stephen J. Turnbull]

Andreas Röhler writes:

 > Useful return values of "forward-" is important for a wide range of 
 > things, not just to serve several specific cases.

Unfortunately, when there are "several specific cases", they often
have different requirements.  Your term "useful" is undefined, and you
need to define it and show that there is a unified definition powerful
enough to make it worthwhile to introduce a backward-incompatible
change.

One way to present such definitions is to describe use cases.  Mine is
an important one: "iterating over a presumed-to-be array-structured
buffer, executing a destructive action on each element of the structure."

On the other hand, your pseudo-code is way too "pseudo" to be useful
to me.  Please *define* the functions that check and update
"delete-second-state".  I think you will find it is rather hard to do
as efficiently as my code, without duplicating my code (perhaps
implicitly).

Re: Errors in interactive commands

[Andreas Röhler]

Am 03.08.2011 11:09, schrieb Stephen J. Turnbull:
> Andreas Röhler writes:
>
>   >  Useful return values of "forward-" is important for a wide range of
>   >  things, not just to serve several specific cases.
>
> Unfortunately, when there are "several specific cases", they often
> have different requirements.  Your term "useful" is undefined,

obviously

  and you
> need to define it and show that there is a unified definition powerful
> enough to make it worthwhile to introduce a backward-incompatible
> change.
>
> One way to present such definitions is to describe use cases.  Mine is
> an important one: "iterating over a presumed-to-be array-structured
> buffer, executing a destructive action on each element of the structure."
>
> On the other hand, your pseudo-code is way too "pseudo" to be useful
> to me.  Please *define* the functions that check and update
> "delete-second-state".  I think you will find it is rather hard to do
> as efficiently as my code, without duplicating my code (perhaps
> implicitly).
>
>

for example the implemented form forward-word already sends nil, not 
error, when buffer-end is reached. Remains still to get it messaged.

Thus implemented forward-word would allow a similar writing as below.
However, that is not convention in Emacs Lisp yet.

Also the return of `t' isn't as useful as `point' IMHO

Maybe the following function using `(setq erg'

might provide sense onto the terms missed definition:

(defun my-collects ()
  "Report and return all word boundaries in current buffer, a list. "
   (interactive)
   (goto-char (point-min))
   (let ((positions-reached nil)
         (word-bounderies nil)
         erg bnds)
     (while (setq erg (ar-forward-word-atpt))
       (add-to-list 'positions-reached erg)
       (setq bnds (ar-bounds-of-word-atpt))
       (add-to-list 'word-bounderies bnds))
     (when (interactive-p) (message "positions-reached: %s" 
positions-reached))
     (when (interactive-p) (message "word-bounderies: %s" word-bounderies))
;;    positions-reached
     word-bounderies
     ))

Just try to write that with means commonly available.

To get

(ar-forward-word-atpt)

thing-at-point-utils.el and thingatpt-utils-base.el

from
https://launchpad.net/s-x-emacs-werkstatt/

is needed

Andreas

--
https://launchpad.net/python-mode
https://launchpad.net/s-x-emacs-werkstatt/

Re: Errors in interactive commands

[Stephen J. Turnbull]

Andreas Röhler writes:

 > > and you need to define it and show that there is a unified
 > > definition powerful enough to make it worthwhile to introduce a
 > > backward-incompatible change.

[...]

 > for example the implemented form forward-word already sends nil,
 > not error, when buffer-end is reached. Remains still to get it
 > messaged.
 > 
 > Thus implemented forward-word would allow a similar writing as
 > below.

Sure.  You said that already, you should assume we understand that.
(Especially since XEmacs already specifies `forward-word' to fail with
nil rather than an error at buffer boundaries, you should assume that
I know that.  Even though Emacs rarely worries more than a plugged
nickel about XEmacs compatibility, I think in this case it's actually
the strongest argument you have.  Ie, the backward compatibility
problem is probably hardly important.  Search for `(featurep 'xemacs)'
near `forward-word' to verify.)

Now we have two use cases, one of which needs the error, and one of
which prefers a null return.  That fails the "unified" test (see my
partial quote reproduced above).

If you want to use this idiom, it is easy, though somewhat inefficent,
to get your desired behavior via

(defun my-forward-word (&optional COUNT BUFFER)
  "exercise for the the reader"
  (condition-case nil
      (forward-word)
    ((beginning-of-buffer end-of-buffer) nil)

If you do this a lot, it's trivial to implement a macro.

I really don't think it's worth your while to fight this.

 > (defun my-collects ()
 >   "Report and return all word boundaries in current buffer, a list. "
 >    (interactive)
 >    (goto-char (point-min))
 >    (let ((positions-reached nil)
 >          (word-bounderies nil)
 >          erg bnds)
 >      (while (setq erg (ar-forward-word-atpt))
 >        (add-to-list 'positions-reached erg)
 >        (setq bnds (ar-bounds-of-word-atpt))
 >        (add-to-list 'word-bounderies bnds))
 >      (when (interactive-p) (message "positions-reached: %s" 
 > positions-reached))
 >      (when (interactive-p) (message "word-bounderies: %s" word-bounderies))
 > ;;    positions-reached
 >      word-bounderies
 >      ))
 > 
 > Just try to write that with means commonly available.

It's trivial, of course.  For the single line containing "while",
substitute

(while (and (save-excursion (skip-syntax-forward "^w") (not (eobp)))
            (setq erg (ar-forward-word-atpt)))

Of course it's prettier with `forward-word' specified your way, but
similarly the case I have in mind where partial failure of multiple
unit movement is an invalid state, not a termination condition, is
prettier with the current definition.

Re: Errors in interactive commands

[Lennart Borgman]

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?

Re: Errors in interactive commands

[Andreas Schwab]

Lennart Borgman <lennart.borgman@gmail.com> writes:

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

How would that change anything, apart from breaking code that tries to
catch the error?  Raising an error throws to top-level by default
anyway.

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: Errors in interactive commands

[Stefan Monnier]

>> Examples such like this one is why I propose using something like
>> (throw 'command-level) instead of raising an error.
> How would that change anything, apart from breaking code that tries to
> catch the error?  Raising an error throws to top-level by default
> anyway.

Exactly.  I think signalling errors is not a bad approach, tho it should
be improved to use `user-error' rather than just `error' for cases which
are normally associated with user errors (which are usually listed in
debug-ignored-errors).  This way we won't need as many regexps in
debug-ignored-errors.

As for the difference between signalling errors and returning nil, they
are fundamentally equivalent, so it's really a question of which is more
convenient "in typical cases".
More consistency would be good, but since any changes in this area risk
introducing backward compatibility problems, I'm strongly in favor of
leaving things as they are.


        Stefan

Re: Errors in interactive commands

[Lennart Borgman]

On Wed, Aug 3, 2011 at 16:41, Stefan Monnier <monnier@iro.umontreal.ca> wrote:
>>> Examples such like this one is why I propose using something like
>>> (throw 'command-level) instead of raising an error.
>> How would that change anything, apart from breaking code that tries to
>> catch the error?  Raising an error throws to top-level by default
>> anyway.
>
> Exactly.  I think signalling errors is not a bad approach, tho it should
> be improved to use `user-error' rather than just `error' for cases which
> are normally associated with user errors (which are usually listed in
> debug-ignored-errors).  This way we won't need as many regexps in
> debug-ignored-errors.

My bad, I misremembered. Yes, changing the errors in commands called
interactively to user-error is what we discussed.

Is user-error implemented now?

Should user-error be raised even when the commands are not called
interactively? (Otherwise a macro handling this could perhaps be
good.)