On Tue, Jul 9, 2013 at 4:25 PM, Junio C Hamano <gitster@xxxxxxxxx> wrote: > Michael Haggerty <mhagger@xxxxxxxxxxxx> 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. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html