bug#43489: [PATCH] Don't signal scan-error when moving by sexp interactively

[João Távora]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>> I disagree Mattias.  I think swallowing errors is bad, generally.
>
> Agreed, BUT the reason Matthias did it this way is that the error we get
> currently from `scan-sexp` can't be turned into a good error message
> without knowing that it was triggered during `forward-sexp`.

I don't understand.  The point about not swallowing errors is that we
don't want to turn them into anything else.  We don't want to change the
nature of the thing, merely dress it up so it looks less crude in
certain contexts, the reponse to an interactive request by the user
being one of them.

In fact, I think this falls right into the use-case for
(called-interactively-p 'interactive)

   The only known proper use of `interactive' for KIND is in deciding
   whether to display a helpful message, or how to display it.  

So my idea is would be to find out where errors are printed, use
cl-prin1 in that spot and then if write a cl-print-object method
specificallly for scan-error that consults called-interactively-p in the
advised manner.

Or something equivalent if cl-print-object is loaded too late or
something

> I think the right way to fix it is indeed not to catch&reraise the
> error, but instead to:
> A) improve the way errors are printed.
> B) change scan-sexp so its errors can be used to generate a good error
>    message without having to know whether it occurred while running
>    forward-sexp or up-list.
>
> I hoped this case would be a good opportunity to do (A), but sadly this
> needs (B) to happen first and this one seemed less straightforward.
> Help very welcome on this one.

I don't see why scan-sexp needs to be changed.  I think we just need to
know where errors are printed to messages when debug-on-error is nil and
dispatch on the error type there.

João