GNU bug report logs -
#52003
Unexpected advising behavior due to recursive implementation
Previous Next
Full log
Message #11 received at 52003 <at> debbugs.gnu.org (full text, mbox):
21 nov. 2021 kl. 10.32 skrev Daniel Sausner <daniel.sausner <at> 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?
This bug report was last modified 3 years and 178 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.