folder and path completely broken in HEAD?

[Mark Walters]

> 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).

Yes indeed. I think one thing that I, at least, hadn't realised is that
people have lots of strange mail layouts often to work around problems
in mail agents (notmuch or others) or filesystem limitations etc.

>>> 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).

One possibly perverse remark: it wouldn't surprise me if someone
actually used the stemming. I have used folders called old older and
oldest and that probably can be excluded by stemming.....

All I am really saying is that any change we made was going to break
some people's setups.

>> 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?

I think folder:foo/bar means "In the maildir exactly foo/bar"

>> 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).

Sorry I wasn't trying to suggest that the current setup does everything
people want (clearly not!): just answering your question about the
differences being confusing. since each user will probably only use one
of them they probably become accustomed to its use.

Indeed, I think of the choice as being analogous to allowing the user to
choose which path scheme they like (so sort of like a customisation):
maildir folder based or filesystem path based.

>> 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.

We could do this. It might break things for user who are using the new
syntax....  Maybe we could make an initial / match the root of the
maildir store. But I think some people will dislike any of the options.

>
> 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.

So this third syntax would fit with my view of it being a customisation
like thing.

Best wishes

Mark