On Thu, Dec 2, 2010 at 9:59 PM, Daniel Shahaf <d.s_at_daniel.shahaf.name> wrote:
> Johan Corveleyn wrote on Thu, Dec 02, 2010 at 21:21:20 +0100:
>> On Thu, Dec 2, 2010 at 6:18 PM, Bill Tutt <bill_at_tutts.org> wrote:
>> > If tokens include keyword expansion operations then stop once you
>> > hit one. The possible source of bugs outways the perf gain in my mind
>> > here.
>>
>> Haven't thought about keyword expansion yet. But as you suggest: I'm
>> not going to bother doing special stuff for (expanded) keywords. If we
>> find a mismatch, we'll stop with the optimized scanning, and fall back
>> to the default algorithm.
>
> Only for the suffix scanning? Or also for the prefix scanning?
>
> (I think you meant the former.) For prefix scanning, I think it's
> common to have $Id$ or similar near the top of the file, so being able
> to collect matching lines past it too would be beneficial.
I left this mail flagged for a long time, because I wanted to get back
to it (but didn't have the time back then to think about it further).
On the topic of diff and keyword expansion: as I said, I don't do
anything special with keywords during prefix/suffix scanning. I just
work with the same data as the normal diff algorithm. But, luckily,
diff works with the "unexpanded-keywords" (de-translated?) version of
the file. I.e. diff doesn't notice any difference caused by expanded
keywords (so neither does the prefix/suffix scanning).
You can nicely see this if you perform an "svn diff" of a file with
keywords, with a line edited just above or below the expanded keyword
(or even on the same line). The diff output shows the unexpanded
keywords, though the keywords in the actual file are expanded.
Cheers,
--
Johan
Received on 2011-02-12 21:25:01 CET