bug#52003: Unexpected advising behavior due to recursive implementation

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

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?