Mark Walters <markwalters1...@gmail.com> writes: > I would just like to second what Jani said. There was a lot of > discussion
I do appreciate that. > and, at the time, the outcome covered all use cases that > anyone showed any sign of wanting. The trick here is that it's easy to miss people who are happy with current functionality. Adding functionality to address newly-identified use cases makes a lot of sense. But removing functionality runs the risk of only discovering that people were relying on it after the fact, (Which seems to have happened here). >> The idea of path: is that it's the exact filesystem directory, relative >> from the maildir root, with an rsync like ** syntax for recursive >> matching. This definition of "path:" seems good. It covers a lot of cases that the original "folder:" did not and allows precise, predictable control. >> Turns out people want folder: to hide maildir implementation >> details like cur and new. Which is something that "folder:" always did. >> These are not compatible, or you need to add a syntax that's not easy >> or discoverable. OK. So I won't argue that we don't need two different syntaxes here. But I will continue to discuss a use case that was addressed before and is no longer. > I think many of us would agree, but there were users who wanted to > distinguish new and cur, and in at least one case, the toplevel as > well. So now, "path:" allows for that, right? My concern is not so much that "path:" was added to address new things, but more than "folder:" was modified in a way that dropped useful functionality, (beyond just fixing bugs in "folder:" such as the accidental support of stemming). > I think it is unfortunate that we need two variants, but I think they do > do different things. I'll accept that. But, while I have heard a good definition of "path:", (see above), I haven't heard a good one for "folder:" yet. Can you provide that? > Also, I think any single user will find one matches their setup and > use that one essentially exclusively: The current discussion is evidence against that. We have a user of folder: that can no longer get at the desired functionality, (that used to exist). > Indeed, it may be that a third option of roughly a maildir++: search term > might solve David's use case. Or just making "folder:" index each term of a filesytem path like it used to do. And if that doesn't give sufficient control to some users, then "path:" is available. I've already lost what I would have preferred, (a single syntax for all use cases---which was lost not to a design problem, but simply the implementation difficulty of requiring a custom query parser). I really would not like to see things continue down to have a *third* syntax. -Carl -- carl.d.wo...@intel.com
pgpmrr_9v22l_.pgp
Description: PGP signature
_______________________________________________ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
