[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#52003: Unexpected advising behavior due to recursive implementation
From: |
Mattias Engdegård |
Subject: |
bug#52003: Unexpected advising behavior due to recursive implementation |
Date: |
Sun, 21 Nov 2021 12:08:39 +0100 |
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?