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

classic Classic list List threaded Threaded
28 messages Options
12
Reply | Threaded
Open this post in threaded view
|

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

Mattias Engdegård-2
When moving by sexp (C-M-f, C-M-u and so on) and point is already at a boundary preventing further movement, Emacs currently signals an internal error such as

 Scan error: "Containing expression ends prematurely", 5010, 5010

or

 Scan error: "Unbalanced parentheses", 5010, 1

which is unhelpful and rather looks as if something went wrong in the internal machinery.

The attached patch does away with this error when the commands are invoked interactively; programmatic use of the functions will get the scan-error just like before. There didn't seem to be much point in replacing the errors with new messages so the current version of the patch doesn't.





0001-Don-t-signal-scan-error-when-moving-by-sexp-interact.patch (8K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

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

Lars Ingebrigtsen
Mattias Engdegård <[hidden email]> writes:

> When moving by sexp (C-M-f, C-M-u and so on) and point is already at a
> boundary preventing further movement, Emacs currently signals an
> internal error such as
>
>  Scan error: "Containing expression ends prematurely", 5010, 5010
>
> or
>
>  Scan error: "Unbalanced parentheses", 5010, 1
>
> which is unhelpful and rather looks as if something went wrong in the
> internal machinery.

Yes, those error messages are confusing in interactive usage.

> The attached patch does away with this error when the commands are
> invoked interactively; programmatic use of the functions will get the
> scan-error just like before. There didn't seem to be much point in
> replacing the errors with new messages so the current version of the
> patch doesn't.

[...]

> +  (if noerror
> +      (condition-case _
> +          (forward-list arg nil)
> +        (scan-error (ding)))

So you basically just `ding' in interactive usage?

I wonder whether this would have any negative effect when people are
using these commands in keyboard macros.  For instance, if you've
recorded a macro that does `M-C-f M-DEL' or something, previously it
would signal an error and then stop, while now it'll just continue and
delete the wrong thing?

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



Reply | Threaded
Open this post in threaded view
|

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

Dmitry Gutov
On 18.09.2020 16:13, Lars Ingebrigtsen wrote:

>> When moving by sexp (C-M-f, C-M-u and so on) and point is already at a
>> boundary preventing further movement, Emacs currently signals an
>> internal error such as
>>
>>   Scan error: "Containing expression ends prematurely", 5010, 5010
>>
>> or
>>
>>   Scan error: "Unbalanced parentheses", 5010, 1
>>
>> which is unhelpful and rather looks as if something went wrong in the
>> internal machinery.
> Yes, those error messages are confusing in interactive usage.

They might be kinda helpful for interactive debugging, though?



Reply | Threaded
Open this post in threaded view
|

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

Dmitry Gutov
On 18.09.2020 16:42, Lars Ingebrigtsen wrote:
> They don't seem like user-level error messages (as you'd expect from a
> command like `C-M-f'), and if you're debugging, you're probably calling
> `M-: (forward-sexp 1)' or something?  (In which case you get these error
> messages still with the patch in question.)

Some translation to better-looking messages would be an improvement, for
sure.

Up until now, M-x forward-sexp behaved the same as (forward-sexp 1), so
I'd guess there are some Lisp developers used to that.

It's not a very strong objection, though.



Reply | Threaded
Open this post in threaded view
|

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

Mattias Engdegård-2
In reply to this post by Lars Ingebrigtsen
18 sep. 2020 kl. 15.13 skrev Lars Ingebrigtsen <[hidden email]>:

First of all, thanks for looking at the patch!

> So you basically just `ding' in interactive usage?

Right. I probably owe you a deeper explanation! Please bear with me for a moment.

It would be acceptable to replace the dings with (user-error "appropriate message"); it would still be an improvement. However:

I'm a firm believer in positive design. Features should be motivated by their actual value rather than habit or tradition. From the user's point of view, it is not an error when the cursor refuses to move beyond its bounds. No other editor (except one) displays a message in these cases, and many don't even beep. The only exception I've found is ed, which should delight everybody.

These messages don't make the editor easier to use in any way; it is crystal clear what the reason is when the cursor doesn't move at the edge of the {line, buffer, sexp, list, ...}. I'd say the contrary: they are nuisance messages that obscure the echo area, clutter the *Messages* buffer, and needlessly cause distractive movement in the visual periphery (a big no-no for any serious industrial UI designer).

In fact, several of the commands in question don't even beep at the boundaries in some cases: for example, C-M-f after the last sexp of the buffer jumps to end-of-buffer and silently stays there. Should we add noise messages for such cases? Surely not.

In other words: I'm not strongly against messages instead of dings if that is the condition for applying the patch, but would like to hear the benefit of those messages argued positively.

There, I'm better now. And here's a hot cuppa, lovely.

> I wonder whether this would have any negative effect when people are
> using these commands in keyboard macros.  For instance, if you've
> recorded a macro that does `M-C-f M-DEL' or something, previously it
> would signal an error and then stop, while now it'll just continue and
> delete the wrong thing?

Actually, (ding) interrupts keyboard macros, so this does work.




Reply | Threaded
Open this post in threaded view
|

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

Lars Ingebrigtsen
Mattias Engdegård <[hidden email]> writes:

> In fact, several of the commands in question don't even beep at the
> boundaries in some cases: for example, C-M-f after the last sexp of
> the buffer jumps to end-of-buffer and silently stays there. Should we
> add noise messages for such cases? Surely not.

Yeah, that is pretty inconsistent.

> In other words: I'm not strongly against messages instead of dings if
> that is the condition for applying the patch, but would like to hear
> the benefit of those messages argued positively.

Emacs does signal errors a lot more in editing than other editors, it's
true -- for instance, `left' at the beginning of the buffer.

> There, I'm better now. And here's a hot cuppa, lovely.

:-)

>> I wonder whether this would have any negative effect when people are
>> using these commands in keyboard macros.  For instance, if you've
>> recorded a macro that does `M-C-f M-DEL' or something, previously it
>> would signal an error and then stop, while now it'll just continue and
>> delete the wrong thing?
>
> Actually, (ding) interrupts keyboard macros, so this does work.

Ah, I'd forgotten that.

Still, I'm not sure whether a (ding) is more helpful than a non-cryptic
user-error message in these instances.

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



Reply | Threaded
Open this post in threaded view
|

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

Mattias Engdegård-2
18 sep. 2020 kl. 17.23 skrev Lars Ingebrigtsen <[hidden email]>:

> Still, I'm not sure whether a (ding) is more helpful than a non-cryptic
> user-error message in these instances.

That's a fair view, but my point is that we shouldn't put in a message unless we can honestly argue for its usefulness. In this case it seems difficult to do so given the evidence. It's not like every other editor is more difficult to use in this particular aspect.

Or put in another way: the absence of a message isn't necessarily cryptic. When the editor explains itself by the result of the user's action, a verbal message on top of it can make matters worse.

By the way, (ding) and (user-error "") seem more or less equivalent, in case one would be preferable.




Reply | Threaded
Open this post in threaded view
|

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

Lars Ingebrigtsen
Mattias Engdegård <[hidden email]> writes:

> 18 sep. 2020 kl. 17.23 skrev Lars Ingebrigtsen <[hidden email]>:
>
>> Still, I'm not sure whether a (ding) is more helpful than a non-cryptic
>> user-error message in these instances.
>
> That's a fair view, but my point is that we shouldn't put in a message
> unless we can honestly argue for its usefulness. In this case it seems
> difficult to do so given the evidence. It's not like every other
> editor is more difficult to use in this particular aspect.

The movement commands Emacs has here are more complicated than most
editors have, though.  Saying why `C-M-f' can't move seems like useful
information for the user to receive.

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



Reply | Threaded
Open this post in threaded view
|

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

Lars Ingebrigtsen
Mattias Engdegård <[hidden email]> writes:

> Well, but is that true? There is no evidence for it. Emacs currently
> gives no useful information in such situations and never has
> ('scan-error' indeed). The previously posted patch can only improve
> matters.

Even if the error looked like an internal error, the bit in the middle
is informative:

forward-sexp: Scan error: "Containing expression ends prematurely", 2076, 2077

> Of course we can put in messages for the at-bounds cases; it would
> look something like the patch below. While it would still be an
> improvement over what Emacs currently does, it is still a statement
> that we value tradition over usability. Try both!

OK, tried it now.  It's less confusing on the whole, except this bit:

> +  (if noerror
> +      (condition-case _
> +          (forward-sexp arg nil)
> +        (scan-error (user-error (if (> arg 0)
> +                                    "No next sexp"
> +                                  "No previous sexp"))))

Hitting `C-M-f' at the start of this line

)()

gives you that error, but there is indeed more sexps in the buffer.  The
error is that the we can't progress because we reached the ")" without
having a "(".

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



Reply | Threaded
Open this post in threaded view
|

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

Dmitry Gutov
In reply to this post by Lars Ingebrigtsen
On 20.09.2020 20:33, Mattias Engdegård wrote:
> While it would still be an improvement over what Emacs currently does, it is still a statement that we value tradition over usability. Try both!

I think that is certainly the case, as a multitude of discussions on
emacs-devel has shown.

It's kinda weird that you chose this particular bit of functionality as
an example, though. There are no counterparts to this in other editors,
so there's no real usability research, and we don't really know which
approach is the most usable.

I'd really prefer we examine both and make a considered choice, rather
than add a user option.



Reply | Threaded
Open this post in threaded view
|

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

Mattias Engdegård-2
20 sep. 2020 kl. 23.39 skrev Dmitry Gutov <[hidden email]>:

> I think that is certainly the case, as a multitude of discussions on emacs-devel has shown.

Unfortunately yes, but what else can we do than trying to improve matters little by little? We will probably fail, but at least we have tried.

> There are no counterparts to this in other editors, so there's no real usability research, and we don't really know which approach is the most usable.

Other editors have structural movement commands although they may or may not behave identically. However, it is a common pattern almost everywhere else that verbal messages aren't displayed unless needed to convey useful information; Emacs is the clear outlier here. There is no reason to believe why one special kind of movement commands in Emacs would warrant error messages (but only sometimes).

> I'd really prefer we examine both and make a considered choice, rather than add a user option.

Very much agreed!




Reply | Threaded
Open this post in threaded view
|

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

Dmitry Gutov
On 21.09.2020 14:21, Mattias Engdegård wrote:
> Other editors have structural movement commands although they may or may not behave identically.

Do they try to preserve the pairing of parentheses (or similar
structures)? What do they say if the user tries to delete a closing
delimiter without deleting the opening one?

> However, it is a common pattern almost everywhere else that verbal messages aren't displayed unless needed to convey useful information;

"We don't move point because of XXX" might be useful info, might it not?



Reply | Threaded
Open this post in threaded view
|

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

Lars Ingebrigtsen
In reply to this post by Lars Ingebrigtsen
João Távora <[hidden email]> writes:

>  >  Scan error: "Containing expression ends prematurely", 5010, 5010
>  >
>  > or
>  >
>  >  Scan error: "Unbalanced parentheses", 5010, 1
>  >
>  > which is unhelpful and rather looks as if something went wrong in the
>  > internal machinery.
>
>  Yes, those error messages are confusing in interactive usage.
>
> I disagree strongly.  Maybe the integers following them and
> containing character positions are confusing, but the messages
> themselves are fine.  

Yes, those are the confusing bits.  :-)  "Scan error" and ", 5010, 1"
sounds like something went wrong deep inside Emacs.

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



Reply | Threaded
Open this post in threaded view
|

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

Mattias Engdegård-2
In reply to this post by Lars Ingebrigtsen
21 sep. 2020 kl. 10.49 skrev João Távora <[hidden email]>:

> If, however,
> the message is "Unbalanced parenthesis", I know something's up
> and have to fix it.

Thanks for mentioning mark-sexp; it was accidentally omitted in my patch. I agree that this particular condition in mark-sexp merits special treatment; the reason for not being able to extend the mark may be far from the cursor and even off-screen.
It is probably worthwhile to communicate the "unbalanced parenthesis" case differently.

For those wondering what this is about: the condition arises when C-M-SPC is pressed with point before an unbalanced left bracket.




Reply | Threaded
Open this post in threaded view
|

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

Mattias Engdegård-2
In reply to this post by Dmitry Gutov
21 sep. 2020 kl. 14.36 skrev Dmitry Gutov <[hidden email]>:

>> Other editors have structural movement commands although they may or may not behave identically.
>
> Do they try to preserve the pairing of parentheses (or similar structures)? What do they say if the user tries to delete a closing delimiter without deleting the opening one?

Structural editing has long history and there is great variety, all from rigid syntax-enforcing editors to plain text editors with some assisting electricity on top; it's impossible to generalise.

> "We don't move point because of XXX" might be useful info, might it not?

So one might think, but there's an opportunity cost. If the user understands what's going on (from context, behaviour etc) without a textual message, then that message is of negative value. In other words, the user would be better off without it.




Reply | Threaded
Open this post in threaded view
|

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

João Távora
In reply to this post by Mattias Engdegård-2
Hi Mattias,

I haven't looked at your patch, but I hope you are taking care with
the C-M- family of commands.  It is not only mark-sexp that has
that property that it warns about something potentially off screen.
Many other C-M- commands also have that.  Think  M-7 C-M-k for
example.  I hope you understand you are touching a cornerstone
of Lisp-related (actually, not only Lisp) editing here.

So I think I can get used to differently worded messages, but the
errors themselves are pretty useful.

João



On Mon, Sep 21, 2020 at 6:12 PM Mattias Engdegård <[hidden email]> wrote:
21 sep. 2020 kl. 10.49 skrev João Távora <[hidden email]>:

> If, however,
> the message is "Unbalanced parenthesis", I know something's up
> and have to fix it.

Thanks for mentioning mark-sexp; it was accidentally omitted in my patch. I agree that this particular condition in mark-sexp merits special treatment; the reason for not being able to extend the mark may be far from the cursor and even off-screen.
It is probably worthwhile to communicate the "unbalanced parenthesis" case differently.

For those wondering what this is about: the condition arises when C-M-SPC is pressed with point before an unbalanced left bracket.



--
João Távora
Reply | Threaded
Open this post in threaded view
|

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

Dmitry Gutov
In reply to this post by Mattias Engdegård-2
On 21.09.2020 20:12, Mattias Engdegård wrote:
>> "We don't move point because of XXX" might be useful info, might it not?
> So one might think, but there's an opportunity cost. If the user understands what's going on (from context, behaviour etc) without a textual message, then that message is of negative value. In other words, the user would be better off without it.

Could be.

Although if we managed to come up with more reasonable messages, and
keep the buffer position numbers in them, the result might be both
friendlier and more helpful.

Though admittedly most of the benefit will come in, again, debugging
situations.



Reply | Threaded
Open this post in threaded view
|

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

Lars Ingebrigtsen
In reply to this post by Lars Ingebrigtsen
Mattias Engdegård <[hidden email]> writes:

> Here is a long shot. If we think that "End of buffer" is a good
> message (I don't really) then what about
>
>  "End of expression"
>  "End of subexpressions"

Yeah, that makes sense to me.

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



Reply | Threaded
Open this post in threaded view
|

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

Mattias Engdegård-2
22 sep. 2020 kl. 16.32 skrev Lars Ingebrigtsen <[hidden email]>:

> Yeah, that makes sense to me.

Apologies for my indecision, but I'm not sure if they make sense to me.

But my personal flaws should not impede progress. How about I push what I've got (latest patch attached for reference) since we seem to agree that it's an improvement over what's in master, and if then you or anyone else want to further adjust the messages then I have no objections.


0001-Don-t-signal-scan-error-when-moving-by-sexp-interact.patch (13K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

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

Mattias Engdegård-2
23 sep. 2020 kl. 15.40 skrev Lars Ingebrigtsen <[hidden email]>:

> The parameter is NOERROR, but now it does signal an error.  :-)
>
> So perhaps the parameter should be USER-ERROR/TERSE-ERROR or something
> and the doc strings adjusted?

Good catch, thank you! The pushed change uses USER-ERROR.




12