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

From: Junio C Hamano <gitster@pobox.com>
Date: Jul 9, 2013, 20:25 UTC
Message-ID: <7vli5fv5ud.fsf@alter.siamese.dyndns.org>
In-Reply-To: <51DC6B37.9030108@alum.mit.edu>

Michael Haggerty <mhagger@alum.mit.edu> writes:

Show 10 quoted lines

> 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.

> /A/+20,/B/
>
>     Start 20 lines after the first match of /A/ until the subsequent
> match of /B/

Yes, I think -L "/^{/-4,/^}/" would be a nice thing to have, but I think it is orthogonal to the issue of "where the search for /^{/