Getting rid of the zombies in dynamically created groups

Getting rid of the zombies in dynamically created groups

[Georg C. F. Greve]

[-- Attachment #1.1: Type: text/plain, Size: 375 bytes --]

Hi all,

in the course of integration of org mode with mairix and gnus, I came
across the need for Gnus to enter a group that is recreated dynamically
by mairix -- so Gnus will need to forget everything about the group when
entering it, and read it afresh.

You can see the resulting code at

  http://article.gmane.org/gmane.emacs.orgmode/3364

the gnus-related part being


[-- Attachment #1.2: Type: application/emacs-lisp, Size: 815 bytes --]

[-- Attachment #1.3: Type: text/plain, Size: 430 bytes --]


If anyone has ideas / suggestions / helpful pointers on how to improve
this, that would be greatly helpful.

Regards,
Georg

-- 
Georg C. F. Greve                                 <greve@fsfeurope.org>
Free Software Foundation Europe	                 (http://fsfeurope.org)
Join the Fellowship and protect your freedom!     (http://www.fsfe.org)
What everyone should know about DRM                   (http://DRM.info)

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

Re: Getting rid of the zombies in dynamically created groups

[Reiner Steib]

On Wed, Sep 26 2007, Georg C. F. Greve wrote:

> in the course of integration of org mode with mairix and gnus, I came
> across the need for Gnus to enter a group that is recreated dynamically
> by mairix -- so Gnus will need to forget everything about the group when
> entering it, and read it afresh.

How about using ephemeral groups?  Here's an example for mbox, I don't
know if something similar can be done with maildir.

--8<---------------cut here---------------start------------->8---
(defvar rs-gnus-debian-bug-mbox-string
  "http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=%s&mbox=yes")

(defun rs-gnus-read-bug-group (number &optional mbox-url)
  "Browse Debian Bug with NUMBER as ephemeral group."
  (interactive (list
		(read-string "Enter Bug number: "
			     (thing-at-point 'word)
			     nil)))
  (when (stringp number)
    (setq number (string-to-number number)))
  (let ((tmpfile (make-temp-file "rs-gnus-temp-group-")))
    (with-temp-file tmpfile
      (url-insert-file-contents
       (format (or mbox-url rs-gnus-debian-bug-mbox-string) number))
      (write-region (point-min) (point-max) tmpfile)
      (gnus-group-read-ephemeral-group
       "rs-gnus-read-bug"
       `(nndoc ,tmpfile
	       (nndoc-article-type mbox))))
    (delete-file tmpfile)))
--8<---------------cut here---------------end--------------->8---

>    Gnus developers couldn't really help, see:
>     http://article.gmane.org/gmane.emacs.gnus.general/65248

Well, you could give them more than one day before stating the
couldn't help.

Bye, Reiner.
-- 
       ,,,
      (o o)
---ooO-(_)-Ooo---  |  PGP key available  |  http://rsteib.home.pages.de/

Re: Getting rid of the zombies in dynamically created groups

[Georg C. F. Greve]

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

On Wed, 26 Sep 2007 20:38:20 +0200
Reiner Steib <reinersteib+gmane@imap.cc> wrote: 

 rs> How about using ephemeral groups?

Thanks for the hint, although it seems a rather circumstantial way to
work around the lack of a "forget what you think to know about this
group" function in gnus. ;)


 >> Gnus developers couldn't really help, see:
 >> http://article.gmane.org/gmane.emacs.gnus.general/65248

 rs> Well, you could give them more than one day before stating the
 rs> couldn't help.

The same issue was discussed before, at least once about a month ago --
see http://article.gmane.org/gmane.emacs.gnus.user/9596 -- but there was
no solution to this, apparently.

How hard would it be to give gnus the capability to ignore what it
thinks to know about a group and force it to reread as if it were a new
group? I lack the knowledge to do so myself, but it doesn't sound like a
terribly impossible thing to do...

Regards,
Georg

-- 
Georg C. F. Greve                                 <greve@fsfeurope.org>
Free Software Foundation Europe	                 (http://fsfeurope.org)
Join the Fellowship and protect your freedom!     (http://www.fsfe.org)
What everyone should know about DRM                   (http://DRM.info)

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

Re: Getting rid of the zombies in dynamically created groups

[Reiner Steib]

On Thu, Sep 27 2007, Georg C. F. Greve wrote:

> How hard would it be to give gnus the capability to ignore what it
> thinks to know about a group and force it to reread as if it were a new
> group? I lack the knowledge to do so myself, but it doesn't sound like a
> terribly impossible thing to do...

Maybe `gnus-group-clear-data', cf. (info "(gnus)Group Data")?

Bye, Reiner.
-- 
       ,,,
      (o o)
---ooO-(_)-Ooo---  |  PGP key available  |  http://rsteib.home.pages.de/

Re: Getting rid of the zombies in dynamically created groups

[Georg C. F. Greve]

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

On Thu, 27 Sep 2007 08:12:24 +0200
Reiner Steib <reinersteib+gmane@imap.cc> wrote: 

 >> How hard would it be to give gnus the capability to ignore what it
 >> thinks to know about a group and force it to reread as if it were a
 >> new group? I lack the knowledge to do so myself, but it doesn't
 >> sound like a terribly impossible thing to do...

 rs> Maybe `gnus-group-clear-data', cf. (info "(gnus)Group Data")?

Trying this apparently screwed up nnmaildir entirely. :-/

When I try to enter the group, I see

 Retrieving newsgroup: nnmaildir:mairix...
 Fetching headers for nnmaildir:mairix...done
 Suppressing duplicates...done
 No articles in the group
 No more unread newsgroups
 No unread news

which is a lie, when doing ls -lR in the folder, I see

 greve@cerebro:~/.nnmaildir/mairix$ ls -lR
 .:
 total 12
 drwx------ 2 greve greve 4096 2007-09-27 23:30 cur
 drwx------ 2 greve greve 4096 2007-09-27 23:30 new
 drwx------ 2 greve greve 4096 2007-09-27 22:55 tmp

 ./cur:
 total 104
 -rw-r--r-- 1 greve greve 100919 2007-09-27 23:30 123456789.89799.mairix:2,

 ./new:
 total 0

 ./tmp:
 total 0

so there is an article in the group, but there seems to be no way to
enter it, or to get Gnus to see that article. Tried deleting and
readding the group, but that also didn't help.

Help appreciated.

Regards,
Georg

-- 
Georg C. F. Greve                                 <greve@fsfeurope.org>
Free Software Foundation Europe	                 (http://fsfeurope.org)
Join the Fellowship and protect your freedom!     (http://www.fsfe.org)
What everyone should know about DRM                   (http://DRM.info)

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

released mairix backend nnmairix.el (was: Getting rid of the zombies in dynamically created groups)

[David]

"Georg C. F. Greve" <greve@fsfeurope.org> writes:
> in the course of integration of org mode with mairix and gnus, I came
> across the need for Gnus to enter a group that is recreated dynamically
> by mairix -- so Gnus will need to forget everything about the group when
> entering it, and read it afresh.

I've written a Gnus backend nnmairix.el for using Gnus together with the
Mairix search engine. It solves the above problem (or so I hope) by
deleting and re-creating the group on the mail backend before entering
it. Additionally, you can create permanent nnmairix groups which are
bound the specific Mairix searches - this way, you can easily create
groups containing all mails from a certain sender or even for certain
threads (based on the message ID). 

Source and documentation is released on the emacswiki:

http://www.emacswiki.org/cgi-bin/emacs/nnmairix.el
http://www.emacswiki.org/cgi-bin/wiki/GnusMairix

Regards,
David

Re: released mairix backend nnmairix.el

[Reiner Steib]

On Thu, Oct 04 2007, David wrote:

> I've written a Gnus backend nnmairix.el for using Gnus together with the
> Mairix search engine. [...]
>
> Source and documentation is released on the emacswiki:
>
> http://www.emacswiki.org/cgi-bin/emacs/nnmairix.el
> http://www.emacswiki.org/cgi-bin/wiki/GnusMairix

Are you the sole author of the code?  Would you like to contribute it
to Gnus?  This would mean that you have to assign the copyright to the
FSF.  Additionally we might need some help from you on proper
integration and documentation of the package.

Bye, Reiner.
-- 
       ,,,
      (o o)
---ooO-(_)-Ooo---  |  PGP key available  |  http://rsteib.home.pages.de/

Re: released mairix backend nnmairix.el

[David]

Reiner Steib <reinersteib+gmane@imap.cc> writes:
> Are you the sole author of the code?  

Yes.

> Would you like to contribute it to Gnus?  This would mean that you
> have to assign the copyright to the FSF.  

Sure. Just tell me what needs to be done. Is it enough to just change
the copyright line in the code?

> Additionally we might need some help from you on proper integration
> and documentation of the package.

Sure, no problem.

Regards,
David

Re: released mairix backend nnmairix.el

[Reiner Steib]

On Fri, Oct 05 2007, David wrote:

> Reiner Steib <reinersteib+gmane@imap.cc> writes:
>> Are you the sole author of the code?  
>
> Yes.

Good.

>> Would you like to contribute it to Gnus?  This would mean that you
>> have to assign the copyright to the FSF.  
>
> Sure. 

Fine.

> Just tell me what needs to be done. Is it enough to just change the
> copyright line in the code?

No.  I've sent you the form and some explanations via private mail.

>> Additionally we might need some help from you on proper integration
>> and documentation of the package.
>
> Sure, no problem.

Thanks for the offer.

Bye, Reiner.
-- 
       ,,,
      (o o)
---ooO-(_)-Ooo---  |  PGP key available  |  http://rsteib.home.pages.de/

Re: released mairix backend nnmairix.el

[Georg C. F. Greve]

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

Hi David,

I just had a look at nnmairix.el to integrate it with org-mairix.el, but
could not yet get it to run here. The problem seems to be in the
handling of paths somewhere, and is probably not too hard to fix.

I currently am using nnmaildir: (for mairix), nnml: (for normal mail)
and nnfolder: (for archival) and tried to create the nnmairix group by
"G b c" as documented.

When trying to use the nnmaildir backend, I can create things, and
launch the search, which claims to have found matches, but nothing is
displayed, Gnus says the group is empty.

When looking on the disk, I see the following nnmaildir directories:

     ~/.nnmaildir/zz_mairix-search-1
     ~/zz_mairix-search-1

with only the one in my home directory actually holding any mail, but
never being found by Gnus, while the one in the .nnmaildir structure
remains empty.

Regards,
Georg

-- 
Georg C. F. Greve                                 <greve@fsfeurope.org>
Free Software Foundation Europe	                 (http://fsfeurope.org)
Join the Fellowship and protect your freedom!     (http://www.fsfe.org)
What everyone should know about DRM                   (http://DRM.info)

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

Re: released mairix backend nnmairix.el

[Bastien]

"Georg C. F. Greve" <greve@fsfeurope.org> writes:

> I just had a look at nnmairix.el to integrate it with org-mairix.el, but
> could not yet get it to run here. The problem seems to be in the
> handling of paths somewhere, and is probably not too hard to fix.

I had exactly the same problems. 

How I found my way thru them is still a mystery, so I cannot help that
much, but here is my setup:

,----[ ~/.mairixrc ]
| base=/home/guerry/Mail
| mh=misc
| mh=mail...
| mbox=archive/????-??-divers-mail:archive/????-??-divers-news
| #mh=expired...
| mformat=mh
| database=/home/guerry/.mairix_database
| mfolder=/home/guerry/.nnmaildir/mfolder
`----

Note that I use mh as a format. For some reason, I couldn't get
something work with maildir or nnml. No idea why.

Then I created a group with no server name, called "default". 
So I have the group "nnmairix:default" in my config.

Following instructions from the doc, I added this:

(add-to-list 'gnus-registry-unfollowed-groups "nnmairix:default")

(setq gnus-auto-subscribed-groups
      "^\\(nnml\\|nnfolder\\|nnmbox\\|nnmh\\|nnbabyl\\|nnmaildir\\).*:\\([^z]\\|z$\\|\\z[^z]\\|zz$\\|zz[^_]\\|zz_$\\).*")

So that the zz* groups that nnmairix.el will create in ~/Mail are not
visible at startup anymore. 

I can browse the group nnmairix:default correctly, but there is still
something weird with the fisrt displayed number of messages: it's sth
like 45345 when it should be 143 (or so.) I guess it's related to the mh
backend.

> When looking on the disk, I see the following nnmaildir directories:
>
>      ~/.nnmaildir/zz_mairix-search-1
>      ~/zz_mairix-search-1

Yeah, same weirdness happened. As you said, there should be something
wrong in the paths handling.

I guess the best config would be to have the nnmairix default group be
the same than the one in mfolder (see ~/.mairixrc) -- how can we achieve
that? How can we have this mfolder being in maildir format?

Any hint welcome!  Thanks,

-- 
Bastien

Re: released mairix backend nnmairix.el

[David]

Bastien <bzg@altern.org> writes:
> I guess the best config would be to have the nnmairix default group be
> the same than the one in mfolder (see ~/.mairixrc) -- how can we achieve
> that? How can we have this mfolder being in maildir format?

The 'mfolder' setting in .mairixrc has no effect on nnmairix since it
always calls the mairix binary with the "-o" option for setting the
output folder manually on the command line (see also my reply to Georg).

Regards,
David

Re: released mairix backend nnmairix.el

[Bastien]

David <de_bb@arcor.de> writes:

> The 'mfolder' setting in .mairixrc has no effect on nnmairix since it
> always calls the mairix binary with the "-o" option for setting the
> output folder manually on the command line (see also my reply to
> Georg).

Yes I know. My suggestion was to take care of this mairix-specific
option in nnmairix.el and tell the nnmairix backend to use this
directory as the default group.  Does that make sense?

-- 
Bastien

Re: released mairix backend nnmairix.el

[David]

Bastien <bzg@altern.org> writes:
> David <de_bb@arcor.de> writes:
>
>> The 'mfolder' setting in .mairixrc has no effect on nnmairix since it
>> always calls the mairix binary with the "-o" option for setting the
>> output folder manually on the command line (see also my reply to
>> Georg).
>
> Yes I know. My suggestion was to take care of this mairix-specific
> option in nnmairix.el and tell the nnmairix backend to use this
> directory as the default group.  Does that make sense?

Oh, I see. The problem is that the mairix installation may be on a
remote IMAP server where mairix is called via ssh (that's what I do), so
Gnus doesn't have access to the .mairixrc-file. But I will use the
directory in the server definition of the mail backend, as suggested by
Georg.

>I can browse the group nnmairix:default correctly, but there is still
>something weird with the fisrt displayed number of messages: it's sth
>like 45345 when it should be 143 (or so.) I guess it's related to the mh
>backend.

The problem is that mairix often doesn't produce consecutive article
numbers in the output folder when using mh. Since Gnus takes the
difference between the highest and lowest article number as the first
value for the numbers of articles, it is often way too high. When Gnus
actually enters the group, it should correct the number. I don't see how
to I could fix this problem in nnmairix.el (at least I'd say it's much
easier to fix this in mairix itself).

Regards,
David

Re: released mairix backend nnmairix.el

[Bastien]

David <de_bb@arcor.de> writes:

> But I will use the directory in the server definition of the mail
> backend, as suggested by Georg.

Yes, good idea.

> When Gnus actually enters the group, it should correct the number.

Yes, it does.

> I don't see how to I could fix this problem in nnmairix.el (at least
> I'd say it's much easier to fix this in mairix itself).

Maybe we should contact mairix developper, claiming there is a huge
crowd of Gnus guys waiting here in hope of some improvement on this?

Oh, well.  

Thanks again, looking forward the next version of nnmairix.el then.

-- 
Bastien

Re: released mairix backend nnmairix.el

[David]

"Georg C. F. Greve" <greve@fsfeurope.org> writes:
>I currently am using nnmaildir: (for mairix), nnml: (for normal mail)
>and nnfolder: (for archival) and tried to create the nnmairix group by
>"G b c" as documented.

You shouldn't have to use a nnmaildir-server in Gnus just for mairix. In
fact, I guess this is the reason for the problems you describe. For
nnmairix to work, your search folders must be on the same backend as
your "real" mail folders (in your case nnml). Maybe I should this make
more flexible, but I thought it makes the setup easier.

Mairix should work directly with nnml. Simply use 

base=...your base folder for your nnml directories...
mh=...folders you want to index...
mformat=mh

in your .mairixrc. 

When you create the nnmairix default server, choose the nnml server as
your mail backend. (Before you do this, delete your old nnmairix server
by killing all nnmairix groups and restarting Gnus).

I'm not sure about your mbox-files you use with nnfolder, though. But I
guess you could simply include them with 

mbox=...your mbox-files (relative to 'base')...

in your .mairixrc and it should also work with nnmairix. There is one
drawback to using nnml with mairix, though: the article count will often
be wrong (but will be corrected as soon as you enter the group). I think
this could be quite easily fixed in mairix itself (it simply has to
output consecutive article numbers).

> When looking on the disk, I see the following nnmaildir directories:
>
>      ~/.nnmaildir/zz_mairix-search-1
>      ~/zz_mairix-search-1
>
> with only the one in my home directory actually holding any mail, but
> never being found by Gnus, while the one in the .nnmaildir structure
> remains empty.

This is because you specified the nnmaildir-server as your mail
backend. However, mairix will put the search results under the path you
specified with the 'base' variable in your .mairixrc. 

Maybe I should better explain how nnmairix.el works: When you create the
default search group with the name "search", it creates the group
"zz_mairix-search-1" on the "real" mail backend which you specified
(e.g. nnmaildir:MYSERVER). When you query mairix with a search term, the
binary is called with "-o zz_mairix-search-1", i.e. mairix will put the
search results into the folder zz_mairix-search-1 under the 'base'
directory. 

This means, the 'base' path in .mairixrc and the base path of your mail
folders have to be the same.

Regards,
David

Re: released mairix backend nnmairix.el

[Bastien]

David <de_bb@arcor.de> writes:

> This means, the 'base' path in .mairixrc and the base path of your
> mail folders have to be the same.

Yes, this is the bit of information that needs to be clearer in the
documentation IMO. 

The problem is that people that have been using mairix + gnus before
nnmairix.el might be used to have a specific backend/folder for mairix
results. For example I had a nnmaildir backend + linked to the folder I
had set up in ~/.mairixrc as my "mfolder"...

-- 
Bastien

Re: released mairix backend nnmairix.el

[Georg C. F. Greve]

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

On Sat, 06 Oct 2007 23:17:24 +0200
David <de_bb@arcor.de> wrote: 

 d> This is because you specified the nnmaildir-server as your mail
 d> backend. However, mairix will put the search results under the path
 d> you specified with the 'base' variable in your .mairixrc.

Ah! This is the reason why it does not work for me.

In my concrete case, the mail archive is in the Archive data structure,
whereas the incoming mail structure is in Mail in my home directory.

Consequently, all search results (falsely) end up in my home directory,
where Gnus does not find them.


 d> This means, the 'base' path in .mairixrc and the base path of your
 d> mail folders have to be the same.

Considering that many people use different backends for archival and
incoming mail, I think that is not a safe assumption to make.

I think nnmairix should use 'nnml-directory' instead, which is where the
path for the mail folders are configured in Gnus, or the appropriate
variable for other backends.

As an added benefit, nnmairix should then also work in situations with
"mixed" backends, because they are not illegal, some people use them for
reasons that may not be entirely obvious, and nnmairix should not choke
on this, imho.

Regards,
Georg

-- 
Georg C. F. Greve                                 <greve@fsfeurope.org>
Free Software Foundation Europe	                 (http://fsfeurope.org)
Join the Fellowship and protect your freedom!     (http://www.fsfe.org)
What everyone should know about DRM                   (http://DRM.info)

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

Re: released mairix backend nnmairix.el

[David]

"Georg C. F. Greve" <greve@fsfeurope.org> writes:
> I think nnmairix should use 'nnml-directory' instead, which is where the
> path for the mail folders are configured in Gnus, or the appropriate
> variable for other backends.

That's a good idea. This could be done for all backends except nnimap,
where the base path in .mairixrc would still have to point to the
Maildir directory the IMAP server uses.

> As an added benefit, nnmairix should then also work in situations with
> "mixed" backends, because they are not illegal, some people use them for
> reasons that may not be entirely obvious, and nnmairix should not choke
> on this, imho.

Well, the nnmairix commands in group mode should already work with mixed
backends, but you have to adapt all paths in your .mairixrc
accordingly. Set your 'base' variable to '~/Mail' and adapt all
following lines relative to this base path. If your archive mbox files
are not under ~/Mail but e.g. under ~/mailarchive, you have to use
something like

mbox=../mailarchive/2005/*:../mailarchive/2006/*

However, the commands in summary mode will not work in these archive
groups, since I originally had the idea that every nnmairix server would
be "responsible" for exactly one backend. I overlooked that people may
use several backends for local mail but which are indexed by one mairix
installation.

Your idea also has the benefit that people which are uncomfortable with
nnmairix creating those zz_mairix-groups alongside their normal mail
folders could still create e.g. a nnmaildir server only for the mairix
search folders.

Regards,
David

Re: released mairix backend nnmairix.el

[Bastien]

David <de_bb@arcor.de> writes:

> Your idea also has the benefit that people which are uncomfortable
> with nnmairix creating those zz_mairix-groups alongside their normal
> mail folders could still create e.g. a nnmaildir server only for the
> mairix search folders.

Yes, that's exactly how I'd like to use nnmairix.el.

Best,

-- 
Bastien

Re: released mairix backend nnmairix.el (was: Getting rid of the zombies in dynamically created groups)

[Bastien]

David <de_bb@arcor.de> writes:

> I've written a Gnus backend nnmairix.el for using Gnus together with
> the Mairix search engine.

Very nice!

I've had some problems trying to set it up... some zz* groups popping up
from nowhere, but I guess it's because of my poor knowledge of Gnus.

One thing: each time I check for new messages with `g', the search is
performed again (even with the group being hidden). So I have to find
the group and assign an empty query "" to it. This is a bit awkward.

Is there something I could do?

Thanks for this add-on.

-- 
Bastien

Re: released mairix backend nnmairix.el

[Bastien]

Bastien <bzg@altern.org> writes:

> I've had some problems trying to set it up... some zz* groups popping up
> from nowhere, but I guess it's because of my poor knowledge of Gnus.

Okay, I think it was related to `gnus-auto-subscribed-groups'.

> One thing: each time I check for new messages with `g', the search is
> performed again (even with the group being hidden). So I have to find
> the group and assign an empty query "" to it. This is a bit awkward.

If I update the query with G b q and try to insert an empty query "" it
will not be updated. I need to perform a new (empty) query for the group
to query nothing (and thus not waiting for the search to happen each
time I try to fetch for new mails...)

Thanks again for the tool, I guess more feedback for other users would
also be helpful.

-- 
Bastien

Re: released mairix backend nnmairix.el

[David]

Bastien <bzg@altern.org> writes:
>> I've had some problems trying to set it up... some zz* groups popping up
>> from nowhere, but I guess it's because of my poor knowledge of Gnus.
>
> Okay, I think it was related to `gnus-auto-subscribed-groups'.

Yes. This happens when you use nnmairix with nnmaildir or nnml backends
(see also the documentation on the emacswiki, it is mentioned
there). You'll have to turn off auto-subscription completely, or you
might use the following (ugly) kludge which still auto-subscribes all
mail groups, except those that begin with 'zz_':

(setq gnus-auto-subscribed-groups
  "^\\(nnml\\|nnfolder\\|nnmbox\\|nnmh\\|nnbabyl\\|nnmaildir\\).*\
:\\([^z]\\|z$\\|\\z[^z]\\|zz$\\|zz[^_]\\|zz_$\\).*")

(Note to the Gnus developers: It would be much easier if I could just put
".*:zz_mairix-.*" into gnus-options-not-subscribe, but
gnus-auto-subscribed-groups precedes it in the function
gnus-matches-options-n, so that doesn't work.)

>One thing: each time I check for new messages with `g', the search is
>performed again (even with the group being hidden). So I have to find
>the group and assign an empty query "" to it. This is a bit awkward.

Just set your nnmairix groups to a lower group level (using 'S l' in the
group buffer), so that it isn't updated when you hit 'g'. A level of '4'
or '5' should do the trick (it depends on your value of
gnus-activate-level). 

>Sorry to continue on my own but a nice feature to have for nnmairix.el
>would be to let the user build the query *interactively*, thus letting
>him use the full potential of mairix.
>
>Something of this flavor:
>
>(defcustom nnmairix-interactive-query-parameters
>  '(from to cc subject body attachment timespan)
>  ...)
>
>What do you think?

Well, you can already create queries interactively based on the current
article using "S g" in summary mode. However, that's only for creating
permanent nnmairix groups but could be easily extended. Your suggestion
would be even more flexible. I definitely will look into that.

Thanks for the feedback, it's really appreciated!
-David

Re: released mairix backend nnmairix.el

[Bastien]

David <de_bb@arcor.de> writes:

> (setq gnus-auto-subscribed-groups
>   "^\\(nnml\\|nnfolder\\|nnmbox\\|nnmh\\|nnbabyl\\|nnmaildir\\).*\
> :\\([^z]\\|z$\\|\\z[^z]\\|zz$\\|zz[^_]\\|zz_$\\).*")

Done that, works smoothly, thanks.

> Just set your nnmairix groups to a lower group level (using 'S l' in
> the group buffer), so that it isn't updated when you hit 'g'. A level
> of '4' or '5' should do the trick (it depends on your value of
> gnus-activate-level).

Okay, will do that as well.

>>What do you think?
>
> Well, you can already create queries interactively based on the current
> article using "S g" in summary mode. 

Tyring to build a query on the body with S g b failed with this
backtrace (other conditions seem okay so far):

Debugger entered--Lisp error: (wrong-type-argument stringp nil)
  string-match("[^-.@& [:alnum:]]" nil)
  (while (string-match "[^-.@& [:alnum:]]" header) (setq header (replace-match "" t t header)))
  (if (> emacs-major-version 20) (while (string-match "[^-.@& [:alnum:]]" header) (setq header ...)) (while (string-match "[[]{}:<>]" header) (setq header ...)))
  (save-excursion (gnus-summary-toggle-header 1) (while (not achar) (message "Query (f=From,t=To,c=Cc,a=To or Cc,s=subject,b=body,m=Msgid): ") (setq achar ...) (when ... ...)) (set-buffer gnus-article-buffer) (setq header nil) (when (setq cq ...) (setq header ...)) (if (> emacs-major-version 20) (while ... ...) (while ... ...)) (while (string-match "[-& ]" header) (setq header ...)) (setq header (read-string ... header)) (push (concat ... ":" header) query) (setq finished (not ...) achar nil))
  (while (not finished) (save-excursion (gnus-summary-toggle-header 1) (while ... ... ... ...) (set-buffer gnus-article-buffer) (setq header nil) (when ... ...) (if ... ... ...) (while ... ...) (setq header ...) (push ... query) (setq finished ... achar nil)))
  (let ((char-header ...) (server ...) query achar header finished group threads cq) (when (or ... ...) (error "No article or summary buffer.")) (when (not server) (error "No nnmairix server found for back end %s:%s" ... ...)) (while (not finished) (save-excursion ... ... ... ... ... ... ... ... ... ...)) (setq threads (y-or-n-p "Include whole threads? ")) (setq group (read-string "Group name: ")) (set-buffer gnus-summary-buffer) (message "Creating group %s on server %s with query %s." group (gnus-method-to-server server) (mapconcat ... query " ")) (nnmairix-create-search-group server group query threads))
  nnmairix-create-search-group-from-message()
  call-interactively(nnmairix-create-search-group-from-message)

> However, that's only for creating permanent nnmairix groups but could
> be easily extended. Your suggestion would be even more flexible. I
> definitely will look into that.

Thanks very much!  I don't know if there are many people using mairix
out there but I switched from swish-e (+nnir) to this and it's really
faster.  Good to have nnmairix.el around.

-- 
Bastien

Re: released mairix backend nnmairix.el

[Bastien]

Hi again,

David <de_bb@arcor.de> writes:

> I've written a Gnus backend nnmairix.el for using Gnus together with
> the Mairix search engine.

Sorry to continue on my own but a nice feature to have for nnmairix.el
would be to let the user build the query *interactively*, thus letting
him use the full potential of mairix.

Something of this flavor:

(defcustom nnmairix-interactive-query-parameters
  '(from to cc subject body attachment timespan)
  ...)

Could be nil if we don't want to query interactively. Or a prefix to the
query functions could negate their default (non-interactive) behavior.

This would make storing queries even more relevant.  

What do you think?

-- 
Bastien