I changed the subject line. And... Branko Čibej wrote:
> On 21.09.2012 11:28, Stefan Sperling wrote: >> It is much more convenient to have this built in, especially on >> platforms that don't have nice post-processing tools installed >> by default (e.g. Windows). > > OK. > >> I've been using it several times already to find commit messages >> for things that I only vaguely remembered -- e.g. "when did stefan2 >> fix this bug where we worked around APR file flush being broken?". >> >> The command "svn log --search stefan2 --search-and flush" returns >> just two log messages (r1325899 and r1240752) to pick from. >> For me, as a human who is bad at scanning large amounts of pages >> in a pager even with assistance from the pager's built-in search, >> that speeds things up. It works well for that kind of thing. > > Cool. So we're back to UI design. :) > > Caveat lector: I'm not volunteering to implement what I'm about to > propose. > > How about having just the --search option and creating a simple query > language parser using parenthesis, AND, NOT and OR operators? I'd even > consider making such searching always case-insensitive, at least for log > messages; One idea stands out as an immediate improvement: have the basic, simple, generic search commands be case-insensitive. Instead of the present --search --isearch (or was it --i-search? no, just playing mind games), --search-and --isearch-and reduce the current implementation to just --search --search-and and make those case-insensitive. Always. The point is, if the aim is to provide a simple-to-use search that "just works" for typical human needs, I think just being case-insensitive will achieve this better. [...] > My point is that, if we want to add regular expression support at a > later time, we can invent a "regex" production that'll fit into > the > query syntax, instead of doubling the number of options for each command > that supports searching. Yes, that argument is a good one, as long as we don't make the expression syntax too arcane. - Julian
