> Maybe I misread the previous discussion and/or your cover letter, > but I have been assuming that you are trying to avoid failing the > command in a useless way (e.g. when the file has only ~800 lines but > the user does not know exactly how many, instead of letting -L1,820 > to fail with "the file only has 815 lines", pretend that the -L1,815 > was given) and instead give a reasonable fall-back behaviour. That's correct. In doing so I picked up on a few extra cases where the behaviour wasn't intuitive, so I've attempted to fix all of those with this patch. > And to be consistent with that world view, I would have expected > that the meaning of -L<something>,-20 to be updated from "fail if > <something> is before line #20, or show 20 lines leading to > <something>" to "show lines leading to <something>, up to 20 lines > but it is OK if there aren't enough lines in the file to show that > many". This is the existing behaviour. -L10,-20 for example will blame the first 10 lines of a file, it will not fail. My patch doesn't change this. The case I am discussing is -L,-20 which at the moment blames the first line of the file. Trying to go backwards from the start of a file should be considered invalid, in my opinion, however I don't feel strongly about it - I don't expect this case is common in practice.
