nnir and move

nnir and move

[Andrew Cohen]

I've pushed a change that adds the ability to move articles from the
nnir summary buffer. This just calls the underlying backend to do the
move.

I have successfully moved about a half-dozen messages, and its hard to
see what could go wrong. But since this is the first time that nnir
makes any real changes to underlying messages, I would suggest testing
on messages you don't mind losing (if something goes wrong) might be
prudent.


Andy

Re: nnir and move

[Richard Riley]

Worked like a charm (nnir->nnimap move)! Many thanks. Now I'm not so
concerned about not seemingly having the ability to search a group by
author/body etc without first having to fetch and format thousands of
messages.

Thanks once again - very useful!

regards

r.



Andrew Cohen <cohen@andy.bu.edu> writes:

> I've pushed a change that adds the ability to move articles from the
> nnir summary buffer. This just calls the underlying backend to do the
> move.
>
> I have successfully moved about a half-dozen messages, and its hard to
> see what could go wrong. But since this is the first time that nnir
> makes any real changes to underlying messages, I would suggest testing
> on messages you don't mind losing (if something goes wrong) might be
> prudent.
>
> Andy
>

-- 
☘ http://www.shamrockirishbar.com, http://splash-of-open-sauce.blogspot.com/ http://www.richardriley.net

nnir and move

[Richard Riley]

Can nnir search results from imap please support article move? Frequently
I want to search my INBOX and then mass move all the results to another
label/group.

Also, how does one filter the inbox for an author without needing to
fetch all messages first into that group? .eg "/ a" only filters the
messages you have prefetched.

Re: nnir and move

[Lars Magne Ingebrigtsen]

Richard Riley <rileyrg@googlemail.com> writes:

> Can nnir search results from imap please support article move? Frequently
> I want to search my INBOX and then mass move all the results to another
> label/group.

nnir could implement -request-move and -request-accept, I guess, and
send those on to the "real" backends?

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

Re: nnir and move

[Richard Riley]

Lars Magne Ingebrigtsen <larsi@gnus.org> writes:

> Richard Riley <rileyrg@googlemail.com> writes:
>
>> Can nnir search results from imap please support article move? Frequently
>> I want to search my INBOX and then mass move all the results to another
>> label/group.
>
> nnir could implement -request-move and -request-accept, I guess, and
> send those on to the "real" backends?

What about the filtering of the inbox not using nnir? Do I need to enter
the group and tell it to fetch and format thousands of messages and then
use /a to find all articles by someone? I think I have missed something
as this would seem odd.

Re: nnir and move

[Andrew Cohen]

>>>>> "Lars" == Lars Magne Ingebrigtsen <larsi@gnus.org> writes:

    Lars> Richard Riley <rileyrg@googlemail.com> writes:
    >> Can nnir search results from imap please support article move?
    >> Frequently I want to search my INBOX and then mass move all the
    >> results to another label/group.

    Lars> nnir could implement -request-move and -request-accept, I
    Lars> guess, and send those on to the "real" backends?

Should be easy enough if the summary buffer contains articles from a
single group, but would this work with multiple groups in the summary
buffer?

Re: nnir and move

[Lars Magne Ingebrigtsen]

Andrew Cohen <cohen@andy.bu.edu> writes:

> Should be easy enough if the summary buffer contains articles from a
> single group, but would this work with multiple groups in the summary
> buffer?

Doesn't nnir keep track of what groups the messages come from?

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

Re: nnir and move

[Andrew Cohen]

>>>>> "Lars" == Lars Magne Ingebrigtsen <larsi@gnus.org> writes:

    Lars> Andrew Cohen <cohen@andy.bu.edu> writes:
    >> Should be easy enough if the summary buffer contains articles
    >> from a single group, but would this work with multiple groups in
    >> the summary buffer?

    Lars> Doesn't nnir keep track of what groups the messages come from?

Yes it does. I just wasn't sure that 'request-move-article would do the
right thing.

Re: nnir and move

[Andrew Cohen]

>>>>> "Andy" == Andrew Cohen <cohen@andy.bu.edu> writes:

>>>>> "Lars" == Lars Magne Ingebrigtsen <larsi@gnus.org> writes:
    Lars> Andrew Cohen <cohen@andy.bu.edu> writes:
    >>> Should be easy enough if the summary buffer contains articles
    >>> from a single group, but would this work with multiple groups in
    >>> the summary buffer?

    Lars> Doesn't nnir keep track of what groups the messages come from?

    Andy> Yes it does. I just wasn't sure that 'request-move-article
    Andy> would do the right thing.


And it does, more or less. Several annoyances, the most severe of which
is the registry, which gets the from-group being nnir rather than the
real group. I know nothing about the registry---before I poke around
maybe Ted can see some way to fix this?

Re: nnir and move

[Andrew Cohen]

>>>>> "Andy" == Andrew Cohen <cohen@andy.bu.edu> writes:

>>>>> "Andy" == Andrew Cohen <cohen@andy.bu.edu> writes:
>>>>> "Lars" == Lars Magne Ingebrigtsen <larsi@gnus.org> writes:
    Lars> Andrew Cohen <cohen@andy.bu.edu> writes:
    >>>> Should be easy enough if the summary buffer contains articles
    >>>> from a single group, but would this work with multiple groups
    >>>> in the summary buffer?

    Lars> Doesn't nnir keep track of what groups the messages come from?

    Andy> Yes it does. I just wasn't sure that 'request-move-article
    Andy> would do the right thing.

    Andy> And it does, more or less. Several annoyances, the most severe
    Andy> of which is the registry, which gets the from-group being nnir
    Andy> rather than the real group. I know nothing about the
    Andy> registry---before I poke around maybe Ted can see some way to
    Andy> fix this?


Oops, I think there is nothing to fix. The registry doesn't track where
the message comes from but only where its going? Then there shouldn't be
a problem...

Re: nnir and move

[Ted Zlatanov]

On Mon, 01 Nov 2010 10:51:50 -0400 Andrew Cohen <cohen@andy.bu.edu> wrote: 

>>>>>> "Andy" == Andrew Cohen <cohen@andy.bu.edu> writes:
>>>>>> "Andy" == Andrew Cohen <cohen@andy.bu.edu> writes:
>>>>>> "Lars" == Lars Magne Ingebrigtsen <larsi@gnus.org> writes:
Lars> Andrew Cohen <cohen@andy.bu.edu> writes:
>>>>> Should be easy enough if the summary buffer contains articles
>>>>> from a single group, but would this work with multiple groups
>>>>> in the summary buffer?

Lars> Doesn't nnir keep track of what groups the messages come from?

Andy> Yes it does. I just wasn't sure that 'request-move-article
Andy> would do the right thing.

Andy> And it does, more or less. Several annoyances, the most severe
Andy> of which is the registry, which gets the from-group being nnir
Andy> rather than the real group. I know nothing about the
Andy> registry---before I poke around maybe Ted can see some way to
Andy> fix this?

AC> Oops, I think there is nothing to fix. The registry doesn't track where
AC> the message comes from but only where its going? Then there shouldn't be
AC> a problem...

Yeah.  Although in a move it needs to know the source so it can delete
that from the list of groups for the article.  So you'll end up with
stale knowledge in the registry.  I can special-case nnir in the hooks
or you can wrap the move in

(let ((gnus-original-source-group-for-move "xyz")) ...)

WDYT?
Ted

Re: nnir and move

[Andrew Cohen]

>>>>> "Ted" == Ted Zlatanov <tzz@lifelogs.com> writes:

    AC> Oops, I think there is nothing to fix. The registry doesn't
    AC> track where the message comes from but only where its going?
    AC> Then there shouldn't be a problem...

    Ted> Yeah.  Although in a move it needs to know the source so it can
    Ted> delete that from the list of groups for the article.  So you'll
    Ted> end up with stale knowledge in the registry.  I can
    Ted> special-case nnir in the hooks or you can wrap the move in

    Ted> (let ((gnus-original-source-group-for-move "xyz")) ...)

    Ted> WDYT?  Ted


I've done it with a let. I'll push a patch shortly.

There is a another problem. nnir (intentionally) mangles the subject to
add something like "[10:mail/3390] " at the front of the subject (this
is [retrieval_score:real_group_name/real_article_number] ). Obviously we
would like to remove it from the subject stored in the registry. I think
the simplest solution would be to modify gnus-registry-simplify-subject
to take care of it before it calls gnus-simplify-subject.

Assuming this OK with you, I'll push it.

Cheers,
andy

Re: nnir and move

[Ted Zlatanov]

On Wed, 10 Nov 2010 11:40:37 -0500 Andrew Cohen <cohen@andy.bu.edu> wrote: 

>>>>>> "Ted" == Ted Zlatanov <tzz@lifelogs.com> writes:
AC> Oops, I think there is nothing to fix. The registry doesn't
AC> track where the message comes from but only where its going?
AC> Then there shouldn't be a problem...

Ted> Yeah.  Although in a move it needs to know the source so it can
Ted> delete that from the list of groups for the article.  So you'll
Ted> end up with stale knowledge in the registry.  I can
Ted> special-case nnir in the hooks or you can wrap the move in

Ted> (let ((gnus-original-source-group-for-move "xyz")) ...)

Ted> WDYT?  Ted


AC> I've done it with a let. I'll push a patch shortly.

AC> There is a another problem. nnir (intentionally) mangles the subject to
AC> add something like "[10:mail/3390] " at the front of the subject (this
AC> is [retrieval_score:real_group_name/real_article_number] ). Obviously we
AC> would like to remove it from the subject stored in the registry. I think
AC> the simplest solution would be to modify gnus-registry-simplify-subject
AC> to take care of it before it calls gnus-simplify-subject.

Could you use nnir-original-group and nnir-original-subject in the let
you said you would do?  I'll make the names more general if anyone else
needs it but I was thinking this way it's clear that it's a nnir
requirement.

That way the registry will not care what nnir does to the subject or
group name, it will just take the originals from the let-bound
variables.

Ted

Re: nnir and move

[Andrew Cohen]

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

>>>>> "Ted" == Ted Zlatanov <tzz@lifelogs.com> writes:


    Ted> Could you use nnir-original-group and nnir-original-subject in
    Ted> the let you said you would do?  I'll make the names more
    Ted> general if anyone else needs it but I was thinking this way
    Ted> it's clear that it's a nnir requirement.

    Ted> That way the registry will not care what nnir does to the
    Ted> subject or group name, it will just take the originals from the
    Ted> let-bound variables.


In fact I'm thinking about a different way (but this might not be best
way):


1. nnir ends up replacing the parsed header with a new one, so the
original subject isn't available anymore, but its easy enough to get
back with a simple string-match. And the only place the original subject
is used is in the registry, which is why I thought that it was best to
just modify gnus-registry-simplify-subject to:

(defun gnus-registry-simplify-subject (subject)
  (if (stringp subject)
      (progn
	(string-match "^\\[[0-9]+:.+/[0-9]+\\] " subject)
	(setq subject (substring subject (match-end 0)))
	(gnus-simplify-subject subject))
    nil))


2. As for the original newsgroup name, I am trying to avoid anything
nnir specific outside the nnir.el file. Its also possible that
other/future virtual backends might want to do something similar so I've
tried an approach that won't require special-casing. The trick is to
pass the original newsgroup name back in to gnus-summary-move-article. I
think this is easy---just introduce a let-bound variable
gnus-original-newsgroup-name initialized to gnus-newsgroup-name and let
the backend-specific 'request-move-article replace it as needed. So only
a few lines of changes and no need for nnir-specific code.


Sorry for being so wordy, and let me know if I'm off-base.  Here is the
proposed patch.


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: possible patch --]
[-- Type: text/x-diff, Size: 2736 bytes --]

diff --git a/lisp/gnus-registry.el b/lisp/gnus-registry.el
index 79080f2..629d804 100644
--- a/lisp/gnus-registry.el
+++ b/lisp/gnus-registry.el
@@ -728,7 +728,10 @@ Consults `gnus-registry-unfollowed-groups' and
 
 (defun gnus-registry-simplify-subject (subject)
   (if (stringp subject)
-      (gnus-simplify-subject subject)
+      (progn
+	(string-match "^\\[[0-9]+:.+/[0-9]+\\] " subject)
+	(setq subject (substring subject (match-end 0)))
+	(gnus-simplify-subject subject))
     nil))
 
 (defun gnus-registry-fetch-simplified-message-subject-fast (article)
diff --git a/lisp/gnus-sum.el b/lisp/gnus-sum.el
index 9715510..dd97b23 100644
--- a/lisp/gnus-sum.el
+++ b/lisp/gnus-sum.el
@@ -9703,6 +9703,7 @@ ACTION can be either `move' (the default), `crosspost' or `copy'."
 		  articles)
     (while articles
       (setq article (pop articles))
+      (let ((gnus-original-newsgroup-name gnus-newsgroup-name))
       (setq
        art-group
        (cond
@@ -9781,7 +9782,7 @@ ACTION can be either `move' (the default), `crosspost' or `copy'."
 			      action
 			      (gnus-data-header
 			       (assoc article (gnus-data-list nil)))
-			      gnus-newsgroup-name nil
+			      gnus-original-newsgroup-name nil
 			      select-method)))
        (t
 	(let* ((pto-group (gnus-group-prefixed-name
@@ -9881,7 +9882,7 @@ ACTION can be either `move' (the default), `crosspost' or `copy'."
 			      action
 			      (gnus-data-header
 			       (assoc article (gnus-data-list nil)))
-			      gnus-newsgroup-name
+			      gnus-original-newsgroup-name
 			      to-newsgroup
 			      select-method))
 
@@ -9903,7 +9904,7 @@ ACTION can be either `move' (the default), `crosspost' or `copy'."
 
     (gnus-kill-buffer copy-buf)
     (gnus-summary-position-point)
-    (gnus-set-mode-line 'summary)))
+    (gnus-set-mode-line 'summary))))
 
 (defun gnus-summary-copy-article (&optional n to-newsgroup select-method)
   "Copy the current article to some other group.
diff --git a/lisp/nnir.el b/lisp/nnir.el
index ae6b903..a71f1f3 100644
--- a/lisp/nnir.el
+++ b/lisp/nnir.el
@@ -453,6 +453,9 @@ result, `gnus-retrieve-headers' will be called instead.")
 (defvar nnir-extra-parms nil
   "Internal: stores request for extra search parms")
 
+(defvar gnus-original-newsgroup-name nil
+  "Internal: stores the real newsgroup name")
+
 ;;; Code:
 
 ;; Gnus glue.
@@ -596,6 +600,7 @@ result, `gnus-retrieve-headers' will be called instead.")
 	 (to-method (gnus-find-method-for-group to-newsgroup))
 	 (from-method (gnus-find-method-for-group artfullgroup))
 	 (move-is-internal (gnus-server-equal from-method to-method)))
+    (setq gnus-original-newsgroup-name artfullgroup)
     (gnus-request-move-article
      artno
      artfullgroup

Re: nnir and move

[Ted Zlatanov]

On Wed, 10 Nov 2010 13:42:28 -0500 Andrew Cohen <cohen@andy.bu.edu> wrote: 

>>>>>> "Ted" == Ted Zlatanov <tzz@lifelogs.com> writes:
Ted> Could you use nnir-original-group and nnir-original-subject in
Ted> the let you said you would do?  I'll make the names more
Ted> general if anyone else needs it but I was thinking this way
Ted> it's clear that it's a nnir requirement.

Ted> That way the registry will not care what nnir does to the
Ted> subject or group name, it will just take the originals from the
Ted> let-bound variables.

AC> In fact I'm thinking about a different way (but this might not be best
AC> way):


AC> 1. nnir ends up replacing the parsed header with a new one, so the
AC> original subject isn't available anymore, but its easy enough to get
AC> back with a simple string-match. And the only place the original subject
AC> is used is in the registry, which is why I thought that it was best to
AC> just modify gnus-registry-simplify-subject to:

AC> (defun gnus-registry-simplify-subject (subject)
AC>   (if (stringp subject)
AC>       (progn
AC> 	(string-match "^\\[[0-9]+:.+/[0-9]+\\] " subject)
AC> 	(setq subject (substring subject (match-end 0)))
AC> 	(gnus-simplify-subject subject))
AC>     nil))

I don't like this: it will fail if a user has that subject accidentally.
Better to get the original unambigously as we get the group.

AC> 2. As for the original newsgroup name, I am trying to avoid anything
AC> nnir specific outside the nnir.el file.

OK.

AC> Its also possible that other/future virtual backends might want to
AC> do something similar so I've tried an approach that won't require
AC> special-casing. The trick is to pass the original newsgroup name
AC> back in to gnus-summary-move-article. I think this is easy---just
AC> introduce a let-bound variable gnus-original-newsgroup-name
AC> initialized to gnus-newsgroup-name and let the backend-specific
AC> 'request-move-article replace it as needed. So only a few lines of
AC> changes and no need for nnir-specific code.

OK, but the variable should not be defined in nnir.el.  I would define
`gnus-original-article-group' and `gnus-original-article-subject' in
gnus.el.

Ted

Re: nnir and move

[Andrew Cohen]

>>>>> "Ted" == Ted Zlatanov <tzz@lifelogs.com> writes:

    Ted> On Wed, 10 Nov 2010 13:42:28 -0500 Andrew Cohen <cohen@andy.bu.edu> wrote:
    >>>>>>> "Ted" == Ted Zlatanov <tzz@lifelogs.com> writes:

    AC> (defun gnus-registry-simplify-subject (subject) (if (stringp
    AC> subject) (progn (string-match "^\\[[0-9]+:.+/[0-9]+\\] "
    AC> subject) (setq subject (substring subject (match-end 0)))
    AC> (gnus-simplify-subject subject)) nil))

    Ted> I don't like this: it will fail if a user has that subject
    Ted> accidentally.  Better to get the original unambigously as we
    Ted> get the group.

OK, that's probably best.


    AC> 2. As for the original newsgroup name, I am trying to avoid
    AC> anything nnir specific outside the nnir.el file.


    Ted> OK, but the variable should not be defined in nnir.el.  I would
    Ted> define `gnus-original-article-group' and
    Ted> `gnus-original-article-subject' in gnus.el.

OK. Since these only get changed in the summary buffer I'd like to make
them `gnus-summary-original-whatever' and put them in gnus-sum.el.

Patch shortly.

Thanks for the help,
Andy

Re: nnir and move

[Katsumi Yamaoka]

Hi,

2010-11-11  Andrew Cohen  <cohen@andy.bu.edu>
[...]
 * gnus-sum.el (gnus-summary-move-article): Use original group and
 subject for virtual articles such as those in an nnir summary buffer.

This change broke the function of copying or moving two or more
articles.  When typing `B c' for marked articles in a group, I got:

Debugger entered--Lisp error: (error "Selecting deleted buffer")
  gnus-summary-move-article(nil nil nil copy)
  gnus-summary-copy-article(nil)
  call-interactively(gnus-summary-copy-article nil nil)

It is because of the present structure of `while' loop:

  (let ((copy-buf (save-excursion
                    (nnheader-set-temp-buffer " *copy article*"))))
    ...
    (while articles
      ....
      (gnus-kill-buffer copy-buf)))

It was:

  (let ((copy-buf (save-excursion
                    (nnheader-set-temp-buffer " *copy article*"))))
    ...
    (while articles
      ....)
    (gnus-kill-buffer copy-buf))

I've fixed it in the git repo.  Could you check whether my change
didn't break what you intended?

Regards,

Re: nnir and move

[Andrew Cohen]

>>>>> "Katsumi" == Katsumi Yamaoka <yamaoka@jpl.org> writes:

    Katsumi> Hi, 2010-11-11 Andrew Cohen <cohen@andy.bu.edu> [...]  *
    Katsumi> gnus-sum.el (gnus-summary-move-article): Use original group
    Katsumi> and subject for virtual articles such as those in an nnir
    Katsumi> summary buffer.

    Katsumi> This change broke the function of copying or moving two or
    Katsumi> more articles.  When typing `B c' for marked articles in a
    Katsumi> group, I got:

[...]

    Katsumi> I've fixed it in the git repo.  Could you check whether my
    Katsumi> change didn't break what you intended?

Oops, my mistake. I closed the (let in the wrong place, and your fix is
the right thing.

Best,
Andy

Re: nnir and move

[Andrew Cohen]

>>>>> "Ted" == Ted Zlatanov <tzz@lifelogs.com> writes:

    Ted> Yeah.  Although in a move it needs to know the source so it can
    Ted> delete that from the list of groups for the article.  So you'll
    Ted> end up with stale knowledge in the registry.  I can
    Ted> special-case nnir in the hooks or you can wrap the move in

    Ted> (let ((gnus-original-source-group-for-move "xyz")) ...)

    Ted> WDYT?  Ted


Sorry to revive this old thread. The last time we discussed this I
thought that the let wrapping was the way to go, but in retrospect I'm
pretty sure I was wrong. Special-casing nnir in the hooks seems better.

I changed my mind when trying to incorporate article deletion in
nnir. The problem arises when deleting more than one article at a
time. Ordinarily all the articles in a summary buffer come from a single
group, but this isn't necessarily true in an nnir
buffer. gnus-summary-delete-article deletes all the articles in a batch
(no problem here since it just calls nnir-request-delete-article) but
then goes through the deleted articles one by one to update the
registry. So it's not easy to pass the original article group through
the let mechanism when different articles come from different groups.


WDYT?

Re: nnir and move

[Lars Magne Ingebrigtsen]

Andrew Cohen <cohen@andy.bu.edu> writes:

> gnus-summary-delete-article deletes all the articles in a batch
> (no problem here since it just calls nnir-request-delete-article) but
> then goes through the deleted articles one by one to update the
> registry. So it's not easy to pass the original article group through
> the let mechanism when different articles come from different groups.
>
> WDYT?

Hm.  That's a sticky problem, yes.  It does sound like special-casing is
needed.  I don't think the other "virtual" servers allow deletion or
anything else, so the Gnus methods in this area probably do the wrong
thing.

On the other hand, perhaps nnir itself should just do the stuff that
Gnus does wrt. the registry.

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

Re: nnir and move

[Andrew Cohen]

>>>>> "Lars" == Lars Magne Ingebrigtsen <larsi@gnus.org> writes:

    Lars> Andrew Cohen <cohen@andy.bu.edu> writes:
    >> gnus-summary-delete-article deletes all the articles in a batch
    >> (no problem here since it just calls nnir-request-delete-article)
    >> but then goes through the deleted articles one by one to update
    >> the registry. So it's not easy to pass the original article group
    >> through the let mechanism when different articles come from
    >> different groups.
    >> 
    >> WDYT?

    Lars> Hm.  That's a sticky problem, yes.  It does sound like
    Lars> special-casing is needed.  I don't think the other "virtual"
    Lars> servers allow deletion or anything else, so the Gnus methods
    Lars> in this area probably do the wrong thing.

    Lars> On the other hand, perhaps nnir itself should just do the
    Lars> stuff that Gnus does wrt. the registry.

Right. How about the following:

Add gnus-summary-article-delete-hook (and -move-hook) to
gnus-summary-local-variables (these are the hooks the registry uses to
do its thing). Then nnir can override them in nnir groups and deal with
the registry stuff itself. This should be really easy and means all the
nnir-specific stuff is confined to nnir.el.

Andy

Re: nnir and move

[Lars Magne Ingebrigtsen]

Andrew Cohen <cohen@andy.bu.edu> writes:

> Add gnus-summary-article-delete-hook (and -move-hook) to
> gnus-summary-local-variables (these are the hooks the registry uses to
> do its thing). Then nnir can override them in nnir groups and deal with
> the registry stuff itself. This should be really easy and means all the
> nnir-specific stuff is confined to nnir.el.

Sounds good to me, I think.

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

Re: nnir and move

[Andrew Cohen]

>>>>> "Lars" == Lars Magne Ingebrigtsen <larsi@gnus.org> writes:

    Lars> Andrew Cohen <cohen@andy.bu.edu> writes:
    >> Add gnus-summary-article-delete-hook (and -move-hook) to
    >> gnus-summary-local-variables (these are the hooks the registry
    >> uses to do its thing). Then nnir can override them in nnir groups
    >> and deal with the registry stuff itself. This should be really
    >> easy and means all the nnir-specific stuff is confined to
    >> nnir.el.

    Lars> Sounds good to me, I think.

OK, I just pushed it. And, I just noticed that I foolishly pushed
hundreds of lines or reindented code since I removed a let. The
substantive changes are a couple dozen lines or so.

Sorry about that.

Andy

Re: nnir and move

[Ted Zlatanov]

On Wed, 01 Dec 2010 17:01:22 -0500 Andrew Cohen <cohen@andy.bu.edu> wrote: 

>>>>>> "Lars" == Lars Magne Ingebrigtsen <larsi@gnus.org> writes:
Lars> Andrew Cohen <cohen@andy.bu.edu> writes:
>>> Add gnus-summary-article-delete-hook (and -move-hook) to
>>> gnus-summary-local-variables (these are the hooks the registry
>>> uses to do its thing). Then nnir can override them in nnir groups
>>> and deal with the registry stuff itself. This should be really
>>> easy and means all the nnir-specific stuff is confined to
>>> nnir.el.

Lars> Sounds good to me, I think.

AC> OK, I just pushed it. And, I just noticed that I foolishly pushed
AC> hundreds of lines or reindented code since I removed a let. The
AC> substantive changes are a couple dozen lines or so.

Haha, I'm not the only one to do it :)

Thanks for working on this and all the other nnir.el code.  It has
improved Gnus search immensely.

Ted