Handling of symlinked maildirs?

Handling of symlinked maildirs?

[Andrei POPESCU]

[-- Attachment #1: Type: text/plain, Size: 1519 bytes --]

Hi,

Im sorting my mailing lists with generic maildrop rules like this one:

    if (/^List-Id:.*<debian-(.*)\.lists.debian.org>/)
        to Maildir/.debian.$MATCH1/

However, I'm subscribed to a *lot* of mailing lists and in order to keep 
my folder view sane I use symlinks to conflate some of them, e.g. 

.debian.devel-announce -> .debian.devel

This works well since mutt simply ignores the symlink(s) so I don't even 
need to exclude them in the config, but it seems that notmuch does index 
each of the symlinks as a separate folder[1].

Does it make sense to have this configurable or even completely exclude 
the symlinks?

On a somewhat related note, unless I'm missing something, notmuch is 
currently indexing only a few header fields, not including List-Id, and 
there is no way to add custom fields. Am I correct?

The reason I'm asking is that in theory one could completely drop any 
sorting (just drop all mail in one folder) and use something like 
'list-id: debian-devel' instead.

Yes, I'm aware that one could work around it by using To:/Cc:, but I'd 
like to distinguish between messages received via the mailing list or 
directly to my private address, otherwise I'd be using Gmail for 
everything anyway :)

[1] this also causes mutt-notmuch to generate a lot of errors when it 
tries to symlink the same message twice to the cache maildir.

Kind regards,
Andrei
-- 
If you can't explain it simply, you don't understand it well enough.
(Albert Einstein)

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 490 bytes --]

Re: Handling of symlinked maildirs?

[Svend Sorensen]

On Mon, 2 Apr 2012 14:28:28 +0300, Andrei POPESCU <andreimpopescu@gmail.com> wrote:
> 
> The reason I'm asking is that in theory one could completely drop any 
> sorting (just drop all mail in one folder) and use something like 
> 'list-id: debian-devel' instead.

I've been using afew [1], which can add tags for mailing lists. A mail
with List-Id: "mailinglist.example.org" gets a "mailinglist" tag.

[1] https://github.com/teythoon/afew

Svend

Re: Handling of symlinked maildirs?

[Jameson Graef Rollins]

[-- Attachment #1: Type: text/plain, Size: 2158 bytes --]

On Mon, Apr 02 2012, Andrei POPESCU <andreimpopescu@gmail.com> wrote:
> Im sorting my mailing lists with generic maildrop rules like this one:
>
>     if (/^List-Id:.*<debian-(.*)\.lists.debian.org>/)
>         to Maildir/.debian.$MATCH1/
>
> However, I'm subscribed to a *lot* of mailing lists and in order to keep 
> my folder view sane I use symlinks to conflate some of them, e.g. 
>
> .debian.devel-announce -> .debian.devel
>
> This works well since mutt simply ignores the symlink(s) so I don't even 
> need to exclude them in the config, but it seems that notmuch does index 
> each of the symlinks as a separate folder[1].
>
> Does it make sense to have this configurable or even completely exclude 
> the symlinks?

Hey, Andrei.  I would say that if you have a compelling reason that
notmuch should be able to ignore symlinked directories then it maybe
makes sense to have it configurable.  However, I must say that I have
completely dropped the whole folder concept myself since I find it
totally redundant with notmuch's tagging and searching capabilities.

> On a somewhat related note, unless I'm missing something, notmuch is 
> currently indexing only a few header fields, not including List-Id, and 
> there is no way to add custom fields. Am I correct?
>
> The reason I'm asking is that in theory one could completely drop any 
> sorting (just drop all mail in one folder) and use something like 
> 'list-id: debian-devel' instead.

Unfortunately notmuch does only index a limited subset of headers
(pretty much just the "primary" ones).  There has been a desire to be
able to index arbitrary headers for a long time now (and List-Id: has
been one of the oft-cited missing headers).  It would certainly improve
the search interface if we could.

Unfortunately no one has yet got around to coding it up.  I don't think
there are any fundamental impediments, it will just take a bit of work.

In the mean time, I wonder if it makes sense to just add List-Id to the
list of headers that we do index?  I think that would be a pretty simple
change, and I think a lot of folks would benefit.

jamie.

[-- Attachment #2: Type: application/pgp-signature, Size: 835 bytes --]

Re: Handling of symlinked maildirs?

[Mark Anderson]

On Mon, 2 Apr 2012 10:54:48 -0700, Jameson Graef Rollins <jrollins@finestructure.net> wrote:
> On Mon, Apr 02 2012, Andrei POPESCU <andreimpopescu@gmail.com> wrote:
> > Im sorting my mailing lists with generic maildrop rules like this one:
> >
> >     if (/^List-Id:.*<debian-(.*)\.lists.debian.org>/)
> >         to Maildir/.debian.$MATCH1/
> >
> > However, I'm subscribed to a *lot* of mailing lists and in order to keep 
> > my folder view sane I use symlinks to conflate some of them, e.g. 
> >
> > .debian.devel-announce -> .debian.devel
> >
> > This works well since mutt simply ignores the symlink(s) so I don't even 
> > need to exclude them in the config, but it seems that notmuch does index 
> > each of the symlinks as a separate folder[1].
> >
> > Does it make sense to have this configurable or even completely exclude 
> > the symlinks?
> 
> Hey, Andrei.  I would say that if you have a compelling reason that
> notmuch should be able to ignore symlinked directories then it maybe
> makes sense to have it configurable.  However, I must say that I have
> completely dropped the whole folder concept myself since I find it
> totally redundant with notmuch's tagging and searching capabilities.

Please don't exclude the indexing of symlinks in notmuch.  I have a
fairly restricted IT environment at work, where I have chosen to symlink
all my maildirs to other disks so that they appear in my home directory
but do not fill my home disk quota every day.  Often my different
maildirs are to make my non-notmuch mail viewing slightly tolerable.

There was a configuration option (new.ignore) added to 0.12 that lets
one specify names of things not to index. That may be enough to do what
you want, although not as automatic as just pitching all symlinks while
indexing.

Thanks,

-Mark