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)
