Re: [PATCH/RFC] blame: accept multiple -L ranges

[Eric Sunshine <sunshine@sunshineco.com>]

On Tue, Jul 9, 2013 at 4:25 PM, Junio C Hamano <gitster@pobox.com> wrote:
> Michael Haggerty <mhagger@alum.mit.edu> writes:
>
>> It would be more general to support "follow the second match to /A/"
>> *independent* of whether the first match is also followed.  I think your
>> proposal only allows the second to be followed if the first is also
>> followed.  Therefore it seems to me that your wish is to add a
>> side-effect to one feature so that you can use it to obtain a simulacrum
>> of a second feature, instead of building the second feature directly.
>>
>> Perhaps allow <start> and <end> to be a sequence of forms like
>>
>> /A//A/,+20
>
> Remember "A" is just a placeholder and in real life it would be more
> than one character.  It is just as annoying as hell you have to type
> it again.
>
> I am not saying that a mode that resets the "start searching from
> here" pointer to the beginning of the file is useless.  For example,
> I would not mind typing a special character, e.g.
>
>     -L <begin1>,<end1> -L !<begin2>,<end2>
>
> that resets the search pointer to the beginning, for a rare case
> where I want the search for <begin2> to restart at the top.
>
> But the thing is, the default matters.  And it is far more common,
> at least to me, when I want to say "from here to there, and then
> from here to there", to expect the second "from here" would be below
> the first one I already specified, while I am looking at the current
> state of a single file from top to bottom and notice two places I am
> interested in.

The proposal currently is only for "-L /RE/,whatever" to behave in a
relative fashion, beginning the search at the end of the last range
specified via -L (or line 1 if there is no previous -L).

Would it also make sense to support "-L +N,whatever" as relative to
the end of the last range specified via -L (or 1 if none).

I ask because the implementation changes needed to also support "-L
+N,whatever" appear to be less invasive than those only allowing "-L
/RE/,whatever/" to be relative. On the other hand, supporting "-L
+N,whatever" requires more documentation. I don't necessarily consider
less invasive changes as a good reason to support "-L +N,whatever" but
it got me thinking about it.