Quantcast

"search --path=directory/" is lame(-ish)

classic Classic list List threaded Threaded
6 messages Options
David Edmondson David Edmondson
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

"search --path=directory/" is lame(-ish)

Adding a terminal slash to a directory name when using --path causes the
search to fail. Removing the terminal slash produces results.

Given that many shells will add the terminal slash during completion,
this is lame(-ish).
_______________________________________________
notmuch mailing list
[hidden email]
http://notmuchmail.org/mailman/listinfo/notmuch
Tomi Ollila-2 Tomi Ollila-2
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: "search --path=directory/" is lame(-ish)

On Wed, Oct 29 2014, David Edmondson <[hidden email]> wrote:

> Adding a terminal slash to a directory name when using --path causes the
> search to fail. Removing the terminal slash produces results.
>
> Given that many shells will add the terminal slash during completion,
> this is lame(-ish).

Except zsh(1) which adds it, but when pressing enter to complete command
execution, the trailing slash is removed -- at least in my configuration...

... Nevertheless, I agree that the "feature" we have is at least a bit lame ;D

Tomi
_______________________________________________
notmuch mailing list
[hidden email]
http://notmuchmail.org/mailman/listinfo/notmuch
Jani Nikula Jani Nikula
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: "search --path=directory/" is lame(-ish)

In reply to this post by David Edmondson
On Wed, 29 Oct 2014, David Edmondson <[hidden email]> wrote:
> Adding a terminal slash to a directory name when using --path causes the
> search to fail. Removing the terminal slash produces results.

I think you mean path:, not --path. Anyway, the reason for this
behaviour is that the path components are indexed as boolean terms, not
unlike tags, just with a different namespace. It's all parsed in Xapian,
not in Notmuch. Adding the / variants would mean indexing twice the
amount of terms.

This could be fixed with our own query parser (somewhere at the other
end of the rainbow), but for the time being I don't see a reasonable
fix.

> Given that many shells will add the terminal slash during completion,
> this is lame(-ish).

Given that path: expects a relative path from the maildir root, not just
any path, and the notmuch bash completion script (if you happen to use
bash) does exactly this, without adding the slash, I'm not too worried.

None of this should be taken as disagreeing with you, though! ;)


BR,
Jani.
_______________________________________________
notmuch mailing list
[hidden email]
http://notmuchmail.org/mailman/listinfo/notmuch
David Edmondson David Edmondson
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: "search --path=directory/" is lame(-ish)

On Wed, Oct 29 2014, Jani Nikula wrote:
> On Wed, 29 Oct 2014, David Edmondson <[hidden email]> wrote:
>> Adding a terminal slash to a directory name when using --path causes the
>> search to fail. Removing the terminal slash produces results.
>
> I think you mean path:, not --path.

Yes, sorry.

> Anyway, the reason for this behaviour is that the path components are
> indexed as boolean terms, not unlike tags, just with a different
> namespace. It's all parsed in Xapian, not in Notmuch. Adding the /
> variants would mean indexing twice the amount of terms.

Could we always prune a trailing slash from the path: component of a
query before using it?

>> Given that many shells will add the terminal slash during completion,
>> this is lame(-ish).
>
> Given that path: expects a relative path from the maildir root, not just
> any path, and the notmuch bash completion script (if you happen to use
> bash) does exactly this, without adding the slash, I'm not too worried.

I'm almost always doing this in Emacs shell-mode, manipulating the
pathnames on the fly. This means that I can adapt, of course.
_______________________________________________
notmuch mailing list
[hidden email]
http://notmuchmail.org/mailman/listinfo/notmuch
David Bremner-2 David Bremner-2
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: "search --path=directory/" is lame(-ish)

David Edmondson <[hidden email]> writes:

>
> Could we always prune a trailing slash from the path: component of a
> query before using it?
>

As I understand it, this is complicated by the fact that we pass the
whole string to Xapian to be parsed as a query, so we don't really know
where the path: terms are. We could in principle preprocess the string
(more) but that seems to be pretty fragile, and we'd have to minimally
deal with quoting of e.g. paths with spaces in them.

d
_______________________________________________
notmuch mailing list
[hidden email]
http://notmuchmail.org/mailman/listinfo/notmuch
David Bremner-2 David Bremner-2
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: "search --path=directory/" is lame(-ish)

In reply to this post by David Edmondson
David Edmondson <[hidden email]> writes:

> Adding a terminal slash to a directory name when using --path causes the
> search to fail. Removing the terminal slash produces results.
>
> Given that many shells will add the terminal slash during completion,
> this is lame(-ish).

This would be relatively straightforward to impliment on top of

     id:[hidden email]

In particular add a filter to strip trailing / in the non-regex case.

d
_______________________________________________
notmuch mailing list
[hidden email]
https://notmuchmail.org/mailman/listinfo/notmuch
Loading...