Jakub Narebski <jnareb@xxxxxxxxx> writes: > Because --near needs an expression it check context for (context is for > found match of lhs expression). So > > -e foo --near \( -e A --or -e B \) > > means lines containing foo and either A or B in the context _for "foo"_. The syntax and semantics of --near I suggested (and you are following) and what Matthias discusses are different and I think that is why you two are talking past each other. What I originally suggested is that you can (syntactically) replace --near with --and. That is, the LHS is the match and RHS is "the LHS must match, but in addition RHS must match but unlike --and RHS does not have to be exactly on the same line but it is OK if it is a line somewhere nearby". The --near Matthias talk about is syntactically not like --and but more like --not. It takes a condition for a line after that, and loosens it to cover nearby lines. So "-e A" means "the line must have A on it" but "--near -e A" means "the line must be nearby a line that satisfies `-e A'". Matthias's "--near EXP" is spelled as "-e '' --near EXP" (the first one is always true) with our syntax, in other words. I do not think either of these semantics is invalid; they are just different. The version by Matthias is more general and more expressive. - : 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