emacs-bug-tracker
[Top][All Lists]
Advanced

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

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


From: GNU bug Tracking System
Subject: bug#43489: closed ([PATCH] Don't signal scan-error when moving by sexp interactively)
Date: Wed, 23 Sep 2020 16:25:01 +0000

Your message dated Wed, 23 Sep 2020 18:24:14 +0200
with message-id <23809679-C345-4780-94FF-3CDF8AEC0787@acm.org>
and subject line Re: bug#43489: [PATCH] Don't signal scan-error when moving by 
sexp interactively
has caused the debbugs.gnu.org bug report #43489,
regarding [PATCH] Don't signal scan-error when moving by sexp interactively
to be marked as done.

(If you believe you have received this mail in error, please contact
help-debbugs@gnu.org.)


-- 
43489: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=43489
GNU Bug Tracking System
Contact help-debbugs@gnu.org with problems
--- Begin Message --- Subject: [PATCH] Don't signal scan-error when moving by sexp interactively Date: Fri, 18 Sep 2020 13:31:16 +0200
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.

Attachment: 0001-Don-t-signal-scan-error-when-moving-by-sexp-interact.patch
Description: Binary data



--- End Message ---
--- Begin Message --- Subject: Re: bug#43489: [PATCH] Don't signal scan-error when moving by sexp interactively Date: Wed, 23 Sep 2020 18:24:14 +0200
23 sep. 2020 kl. 16.45 skrev João Távora <joaotavora@gmail.com>:

> If it has not, and we do decide to go this route, I'd just nitpick
> that the parameter name should be INTERACTIVE or 
> RESIGNAL-ERROR.

Thank you! INTERACTIVE is indeed a better parameter name; now renamed.

I'm not very interested in the exact mechanism used for actually displaying the 
messages to the user. As you have no doubt grown weary hearing by now, I would 
have preferred there not being any to show! The employed method (user-error) 
seemed to be simple and workable.  That it uses the error-signalling mechanism 
is coincidental.

This bug can probably be closed now. Further improvements will of course still 
be possible.



--- End Message ---

reply via email to

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