On Mon, Mar 29 2021, Johannes Sixt wrote: > Am 29.03.21 um 12:18 schrieb Phillip Wood: >> It would be nice to include indented define forms but including them >> means that any change to the body of a function is attributed to the >> last internal definition rather than the actual function. For example >> >> (define (f arg) >> (define (g x) >> (+ 1 x)) >> >> (some-func ...) >> ;;any change here will have '(define (g x)' in the hunk header, not >> '(define (f arg)' >> >> I don't think this can be avoided as we rely on regexs rather than >> parsing the source so it is probably best to only match toplevel defines. > > There can be two rules, one that matches '(define-' that is indented, > and another one that matches all non-indented forms of definitions. If > that is what you mean. Yes, but that doesn't help in these sorts of cases because what a rule like that really wants is some version of "don't match this line, but only if you can reasonably match this other rule". We can only do rule precedence on a per-line basis via the inverted matches. So for languages like cl/elisp/scheme and others where it's common to have nested function definitions (then -W would like the top-level) *OR* similarly looking nested function definitions, but the top-level isn't a function but a (setq) or whatever we're basically stuck with picking one or the other. I've pondered how to get around this problem in my userdiff.c hacking without resorting to supporting some general-purpose Turing machine, and have so far come up with nothing. You can see lots of prior art by grepping Emacs's source code for beginning-of-defun, it solves this problem by exposing a Turing machine :)
