bug#52003: Unexpected advising behavior due to recursive implementation

[Mattias Engdegård]

21 nov. 2021 kl. 10.32 skrev Daniel Sausner <daniel.sausner@posteo.de>:

> I see. I somehow assumed that functions at that level would aim to be 
> compliant to the max.

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, I'd say that in that case the non-interactive performance outweighs 
> this particular corner case of advising these core functions, which I came to 
> understand is a hot iron.

The cost of that extra function call is probably going to be lost in the noise. 
I'm not looking for excuses to avoid work here but would like to know what 
problem rearranging the code would actually solve. 

> Therefore I'd say this bug report can be closed from my point of view. I 
> guess I still have to use advising as I currently see no other feasible way 
> out, but I can make it sensitive to `interactive` as well.

What are you trying to do? Can't you define a mode-specific 
forward-sexp-function?