Doug Robinson wrote on Mon, Dec 16, 2019 at 11:13:25 -0500:
> So the two file names, differing only by a TAB in the "right place" will
> currently have completely different behaviors:
> 
>   My File NameSPACE(Revision 12)
>   My File NameTAB(Revision 12)
> 
> I see no point in maintaining that the "TAB" is critically significant and
> different from the "SPACE".  The difference is easier parsing vs. 1 visually
> indistinguishable use case (depending on what tool you are using to view the
> diff file).
> 
> And the "sequence of SPACE" instead of just a single "SPACE" falls into the
> same visually indistinguishable category.  So keep the parsing simple and
> just declare file names with "SP/TAB(Revision #)" at the end to not be
> supported.

You can't assume the string after the tab will be "(revision %ld)".

First of all, as I already pointed out, that string is translatable.  Second of
all, we also have to support patches generated by third-party tools, which may
contain arbitrary text after the tab character.  And of course, both the
filename and the label (= the part after the tab character) may contain an
arbitrary number of spaces.

Please propose an algorithm for parsing a filename out of a diff header line
(a '---' line or a '+++' line) that doesn't contain tabs, under these 
conditions.
(We don't have to fix _all_ cases, but fixing the bug just for English speakers
isn't going to fly.)

---

I suppose that simply trying to repeatedly s/\s+\S+$// might work well enough?  
That is:

    data = line[len('--- '):].rstrip('\n')
    need_confirmation = False
    while len(data) > 0:
        if exists(data):
            break
        else:
            data =~ s/\s+\S+$//;
        need_confirmation = True
    else:
        raise Exception("{!r} does not exist".format(line[4:]))
    if need_confirmation:
        prompt_for_confirmation(data)

Reply via email to