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)