>>> Jeff King <peff@xxxxxxxx> schrieb am 24.06.2021 um 17:41 in Nachricht
<YNSnlhbE30xDfVMY@xxxxxxxxxxxxxxxxxxxxxxx>:
[...]
> One thing you may not like, though: both the builtin version and that
> patch only put the funcname context in the _first_ hunk of the split.
> Doing it for subsequent hunks is much trickier, since there can be a
> funcname in the split context itself. E.g.:
>
> @@ ... @@ void foo()
> int x;
> - int y = 1;
> + int y = 2;
>
> - x = 3;
> + x = 4;
> }
>
> could split into two hunks, both annotated with "void foo()". But:
>
> @@ ... @@ void foo()
> int x;
> - x = 3;
> + x = 4;
> }
> void bar()
> {
> - int y = 1;
> + int y = 2;
> }
>
> would be wrong to say "void foo()" for the second hunk. We'd have to
> re-scan the interior context lines for a funcname to find it. That's
> all-but-impossible in the perl version, but might be do-able in the C
> version (since it has easy access to the funcname-matching patterns and
> machinery).
There always was a related bug (IMHO) that showed the context of the previous function even though the actual change was within a new function (that starts within the context lines). So if that bug were fixed, my guess is that the other would be as well.
However I don't know how easy or hard the fix will be.
Maybe the "definition" of function context is just different; I don't really know.
>
> -Peff
>
> [0] I'm not sure what the timetable is for switching to the C version of
> add--interactive. If it's going to be a while, I don't mind moving
> forward the other patch I showed. But maybe the time is here to
> think about switching the default of add.interactive.useBuiltin, and
> ironing out any final bugs?
