Re: gnus nnmaildir and notmuch

[Andrew Cohen <cohen@bu.edu>]

>>>>> "Eric" == Eric Abrahamsen <eric@ericabrahamsen.net> writes:


[...]


    Eric> So far as I can see, the only remaining pieces would be to
    Eric> give that command a gnus-group-mode keybinding, and have it
    Eric> prompt for a query, rather than taking the query from the
    Eric> current group. If at present it's necessary to prefix the
    Eric> group name with "nnir-", that can simply be done
    Eric> unconditionally in the command.

    Eric> That's it, isn't it? That and documentation, of course. I'd be
    Eric> happy to help with completing this, and/or documenting it.

Already done in my private version (sans documentation). But I don't
want to do it now since I'd rather finish the factoring I mentioned
previously. This factoring would lead to incompatible changes in
people's setups (mostly renaming, but still...)


[...]


    Eric> I dove pretty deeply into nnir a year or two ago when I was
    Eric> writing Gnorb. I needed exactly what you describe here: a
    Eric> simple way to create groups containing arbitrary messages. I
    Eric> ended up having to write a fake "nngnorb" backend, and require
    Eric> users to add it to their server list, because that was the
    Eric> only way nnir could find the correct query function to run. I
    Eric> would love to just be able to specify a function as part of
    Eric> the query parameter!

This is also already done in my personal version. 


    Eric> As for the backends... It seems like there are too many
    Eric> backends already. Why don't we just hijack nnvirtual? nnselect
    Eric> sounds like it would be exactly like nnvirtual, except with
    Eric> the ability to specify articles in addition to groups. It
    Eric> would be more work to merge the two, but I think it would make
    Eric> much more sense all around. Virtual groups would be any kind
    Eric> of virtual group, and then there'd just be a search interface
    Eric> laid on top of it.

Merging with nnvirtual doesn't make any sense: the functionality of
nnvirtual (combining existing groups to act as a single group) can
already be done directly as part of nnselect. And the approach taken in
nnvirtual to doing this is radically different from the one I adopted
for nnir (which makes sense since most of the hard work in nnir doesn't
exist for merging entire groups). So the choice is to either eliminate
nnvirtual entirely and replace it with nnselect (possibly renaming in
the process) or let both co-exist. Since replacing it would break things
for anyone using it I favor leaving it alone (unless it turns out that
no one is using it). Over time we can then consider eliminating
nnvirtual. 

(And a small mea culpa---looks like I DID add expiry but just disabled
it for myself. It was so long ago I've mostly forgotten what I did :))

Andy