Log search UI options [was: svn commit: r1383480 ...]

[Julian Foad <ju...@btopenworld.com>]

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

Re: Log search UI options [was: svn commit: r1383480 ...]

[Stefan Sperling <st...@elego.de>]

On Fri, Sep 21, 2012 at 04:18:47PM +0200, Stefan Sperling wrote:
> On Fri, Sep 21, 2012 at 01:07:24PM +0100, Julian Foad wrote:
> > 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.
> 
> That's a great suggestion, actually, and very easy to do.
> I will do this if nobody objects.

Since I doubt that anyone objects to uncluttering the interface,
I just went ahead with this in r1388530.

Re: Log search UI options [was: svn commit: r1383480 ...]

[Stefan Sperling <st...@elego.de>]

On Fri, Sep 21, 2012 at 01:07:24PM +0100, Julian Foad wrote:
> 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.

That's a great suggestion, actually, and very easy to do.
I will do this if nobody objects.