bug#52003: Unexpected advising behavior due to recursive implementation

[Daniel Sausner]

> Yes but what would that mean? The best we can do is to promise that a function 
> F, when called in a manner consistent with the documentation, behaves 
> accordingly. We cannot guarantee the absence of calls to F, can we?
>
> But unless I'm mistaken, that's what you are unhappy about: `forward-sexp` may 
> call itself when you call it. A lot of other code calls that function as part 
> of their implementation. Don't they cause trouble, or is it just the recursive 
> call?
Well, my initial concern was the (new) recursive call, which adds 
another layer of complexity for advising. I now see too that an advice 
on such a deep rooted function is kind of madness anyway. In fact I 
would need to make a distinction between the interactive modes both ways.

> What are you trying to do? Can't you define a mode-specific 
> forward-sexp-function?
The problem I'm trying to solve is, that the cursor in evil normal state 
is not between chars but _on_ a char. Moving to the end of a sexp in 
lisp I would expect the cursor to be on the closing paren instead of 
behind it. There was already an advice planted on 
`elisp--precedent-sexp` to achieve this effect for `eval-last-sexp`. It 
basically only moves the point one char forward if in normal mode before 
eval-last-sexp, hence the sexp including the paren on which the cursor 
rests will be evaluated instead of the thing before the cursor/paren.

I wanted to transport this behaviour to the motion-sexp commands and 
initially I was naive enough to think that this is a low hanging fruit, 
because I could take the same advice function and add it to 
backward/forward-sexp.

In essence I would like to move the visible cursor by a single char in 
one or the other direction before and after one or more 
`forward-sexp`-based commands are executed. But I'm not sure anymore if 
this is really worth the effort :-)