[darcs-users] matchers (Was: Re: 'submitted' branch)

Petr Rockai me at mornfall.net
Tue Sep 14 12:42:17 UTC 2010


"Sittampalam, Ganesh" <ganesh.sittampalam at credit-suisse.com> writes:
>> Florent had a more general mechanism, but one which sounds harder to
>> implement.  What do you think, Florent? From a UI Skeptic point of
>> view, should we, just implement pull --bundle for expediency now, and
>> worry about the 'in' matcher later?   
>
> IMO from a UI skeptic point of view, we should favour the more general
> idea (i.e. Florent's) over the more specific one.
>
> The only reservation I have there is that a matcher that involves
> looking at remote stuff is a bit weird.

I agree that matchers are more general and probably the right thing to
do. Nevertheless, I am a bit sceptical about the current implementation
and also the user interface. Basically, everything-matcher besides -p
needs to be wrapped with --match and somewhat disturbing quotes.

I think the UI is the main reason why I keep avoiding heavier matcher
use, even though they are very useful in theory. I might have mentioned
this somewhere, but just adding the option to say

-m author=mornfall

instead of --match "author mornfall" would make me happier. I know that
-m is currently taken by --name. The fact that there's no short for
--match is nevertheless fairly annoying. Also, I would probably expect
mentioning -m multiple times to get you an intersection of the matchers,
so I can get further without quoting.

There's of course an option of using : instead of = (that's what
notmuch(1) does: notmuch search from:kowey) which may be nicer.

At that point, we could also add aliases for various -m foo:bar options,
which would be especially useful with the "in" matcher, since neither of
--match "in ../bun<TAB>" nor -m in:../bun<TAB> actually works, which is
another UI bother (same for the touch matcher).

I know it looks minor, but it can have a major experience impact, IMHO.

Yours,
   Petr.


More information about the darcs-users mailing list