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

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

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


From: Mattias Engdegård
Subject: bug#43489: [PATCH] Don't signal scan-error when moving by sexp interactively
Date: Mon, 21 Sep 2020 12:55:19 +0200

20 sep. 2020 kl. 21.54 skrev Lars Ingebrigtsen <larsi@gnus.org>:

> 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

That message reads either as an error in Emacs itself or in the user's code. 
There is typically no expression that ends prematurely when the command is 
invoked (there may be, but Emacs cannot know that). It seems that the message 
is not so much informative as outright misinforming.
The message from C-M-u, "Unbalanced parentheses", is an equally blatant lie.

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

Thank you for testing the patch. (Less confusing than Emacs master, I presume? 
Or if you mean compared with the no-message patch, what was confusing about it?)

> )()
> 
> 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 "(".

If I understand you properly, you say that "No next sexp" is an inappropriate 
message for C-M-f at

 ((A B_) C D)

where the underscore indicates point, since the expressions C and D follow? 
Editors differ in how they handle this case: some just continue up one level 
(in this case, past C) instead of stopping. There are merits to either 
behaviour and I'm not suggesting a change to Emacs in this respect.

What would a good message be then, if we insist on one? "No next sexp" is 
correct within the semantics of forward-sexp and to the point; a more detailed 
message might be something like

 "Past last element in expression"
 "No next subexpression"
 "Past last subexpression"

which may or may not be better. 'Sexp' is an Emacs-specific term which may 
still be appropriate in these messages since it figures prominently in the 
manual and the commands are defined around it. Suggestions are welcome!

Let's not forget that the empty string is also an alternative and should be 
compared with the verbal messages. Assuming that the user understands what 
C-M-f does, it seems clear enough.






reply via email to

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