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

["Mattias Engdegård" <mattiase@acm.org>]

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.