From: Eric Abrahamsen <eric@ericabrahamsen.net>
To: ding@gnus.org
Subject: Re: gnus nnmaildir and notmuch
Date: Sun, 26 Mar 2017 21:33:36 -0700 [thread overview]
Message-ID: <87efxjpcdb.fsf@ericabrahamsen.net> (raw)
In-Reply-To: <87fuhzsexs.fsf@hanan.ust.hk>
Andrew Cohen <cohen@bu.edu> writes:
> 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...)
[...]
> This is also already done in my personal version.
Okay, looking forward to it!
> 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.
Sure, by "merging" I just meant that we don't need both of them -- I was
also assuming that the code from nnir/nnselect would mostly replace
nnvirtual. Co-existence is fine, though it will be confusing for people
exploring Gnus. Perhaps if the docs emphasize nnselect, and only mention
nnvirtual in terms of backwards compatibility, it wouldn't be a big
deal.
Eric
prev parent reply other threads:[~2017-03-27 4:33 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-03-23 9:51 Erik Colson
2017-03-23 15:25 ` Eric Abrahamsen
2017-03-23 15:31 ` Eric Abrahamsen
2017-03-23 15:47 ` Eric Abrahamsen
[not found] ` <afcec017ee42495d979cc97a6f638276@HE1PR01MB1898.eurprd01.prod.exchangelabs.com>
[not found] ` <87shm3ex6p.fsf@t3610>
2017-03-23 18:58 ` Eric Abrahamsen
2017-03-24 0:38 ` Andrew Cohen
2017-03-24 1:17 ` Eric Abrahamsen
2017-03-24 8:00 ` Erik Colson
2017-03-24 8:23 ` Erik Colson
2017-03-24 8:29 ` Erik Colson
2017-03-24 15:48 ` Eric Abrahamsen
2017-03-24 18:47 ` Eric Abrahamsen
2017-03-26 4:51 ` Andrew Cohen
2017-03-26 6:05 ` Andrew Cohen
2017-03-26 16:32 ` Eric Abrahamsen
2017-03-27 1:09 ` Andrew Cohen
2017-03-27 4:33 ` Eric Abrahamsen [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87efxjpcdb.fsf@ericabrahamsen.net \
--to=eric@ericabrahamsen.net \
--cc=ding@gnus.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).