Packing nnml folders...

Packing nnml folders...

[Jon Allen Boone]

Folks,

    I often end up in a situation where I manually delete a message that
  has been put in a nnml folder by my nnmail-split-fancy setup.  After a
  while, these folders end up with large article #s - but somewhat
  sparsely populated.

     Similarly, my inbox - misc.misc - numbers articles with high
  numbers (in excess of 2800 at this point) - despite the fact that it
  is empty.  :-)

    Is there an already existing function that will "pack" the folder -
  renumbering articles so that they start with 1 and are densely
  numbered?  This is akin to what the nmh "folder -pack" functionality.

-jon
-- 
------------------
Jon Allen Boone
tex@delamancha.org

Re: Packing nnml folders...

[Kai Großjohann]

On Fri, 27 Jul 2001, Jon Allen Boone wrote:

>     Is there an already existing function that will "pack" the
>     folder - renumbering articles so that they start with 1 and are
>     densely numbered?  This is akin to what the nmh "folder -pack"
>     functionality.

Not as such.  For nnml groups, you can rename them twice (second time
to get back the old name).  For all groups, you can enter it with `C-u
RET' (be sure to view all articles), then `M P a' to mark all
articles, then `B m' to move them into the same group.

kai
-- 
~/.signature: No such file or directory

Re: Packing nnml folders...

[Lloyd Zusman]

Kai.Grossjohann@CS.Uni-Dortmund.DE (Kai Großjohann) writes:

> On Fri, 27 Jul 2001, Jon Allen Boone wrote:
> 
>>     Is there an already existing function that will "pack" the
>>     folder - renumbering articles so that they start with 1 and are
>>     densely numbered?  This is akin to what the nmh "folder -pack"
>>     functionality.
> 
> Not as such.  For nnml groups, you can rename them twice (second time
> to get back the old name).  [ ... ]

I tried this on an nnml group, and none of the messages got
renumbered.  I did this:

   G r new-name RET
   G r original-name RET

No change to article numbers.  This is a fairly recent CVS version of
Gnus.

Are you sure that this double-renaming of nnml groups is really
supposed to renumber/repack the articles?

> [ ... ] For all groups, you can enter it with `C-u RET' (be sure to
> view all articles), then `M P a' to mark all articles, then `B m' to
> move them into the same group.

This didn't work in my nnml group, either.

  Original article-number range:  6174 - 8093 (sparse)

  C-u RET
  M P a
  B m group-name RET (where "group-name" is the name of this group)

  New article-number range:   8094 - 9547 (packed)

As you can see, the renumbering didn't start at 1, but rather, at one
number higher than the old highest article number.

Here's what *does* work for me, at least for nnml groups:

Start in the Group buffer ...

  [ position to the group that you want to renumber from 1 ]

  C-u RET

  M P a

  B m new-group-name  (where "new-group-name" is unique)

  q  (to re-enter Group buffer)

  [ position to the entry for the original group name in the Group buffer ]

  G DEL (to delete this original group)

  [ position to the entry for "new-group-name" in the Group buffer ]

  G r orig-group-name RET (where this is the original group name)

In other words, copy all the articles from your original group to a brand
new, uniquely named group.  This guarantees that their numbering
starts at 1.  Then, delete the original group, and rename the brand
new group to the name of your original group.

After doing this, you'll have to reset customization variables, group
levels, etc. of the new instantiation of your group, so be sure to
note what these values are from the original group before you delete
it.

There's gotta be a better way to do this, however ... ???


> kai
> -- 
> ~/.signature: No such file or directory


-- 
 Lloyd Zusman
 ljz@asfast.com

Re: Packing nnml folders...

[Jon Allen Boone]

Kai, thanks for your help. :-)

Lloyd, I'm glad you tried this first!  :-)

Lloyd Zusman <ljz@asfast.com> writes:
> 
>    There's gotta be a better way to do this, however ... ??? 

    I propose that we write a function to handle this.  I think it is
  fairly straight-forward.  In fact, I imagine we could probably re-use
  existing code.  Here's the algorithm that the function would use:

  Step 1:  Mark all articles in group.

    This is to work on the entire group.

  Step 2:  Re-spool marked articles, using normal methods with the
    exception that we will ignore split variables.

    This will result in everything being densely packed but numbered
    starting with the first available article number.

    Note: we want to ignore any split variables to prevent articles from
              mysteriously vanishing from the group.

  Step 3:  Mark all articles in the group.

  Step 4:  Re-spool marked articles, ignoring split variables, starting
    with article #1.


    The one other thing I am worried about is making sure that no new
  articles appear while we are in the packing process.

    I believe that this is different from the algorithm that nmh uses in
  that if the first article in the group is already #1, nmh will leave
  it alone and my algorithm will renumber it twice.  :-)


-jon
-- 
------------------
Jon Allen Boone
tex@delamancha.org

Re: Packing nnml folders...

[Paul Jarc]

Jon Allen Boone <tex@delamancha.org> writes:
>   Step 4:  Re-spool marked articles, ignoring split variables, starting
>     with article #1.

The backend itself decides how to number articles; you can't tell it
what numbers to use.  Numbers have to be monotonically increasing, so
backends will never assign a lower number to a new article when a
higher number is already in use.  To make it start from 1, you'd have
to convince the backend that the group contains no articles.  That
leaves us with Lloyd's way.

ObPlug: nnmaildir automatically renumbers articles from 1.  See
<URL:http://multivac.cwru.edu./nnmaildir/using/#cruft>.  But nnmaildir
won't support mail splitting until the next version, so it might not
be useful for you yet.


paul

Re: Packing nnml folders...

[Jon Allen Boone]

prj@po.cwru.edu (Paul Jarc) writes:

> Jon Allen Boone <tex@delamancha.org> writes:
>>   Step 4:  Re-spool marked articles, ignoring split variables, starting
>>     with article #1.
> 
>    The backend itself decides how to number articles; you can't tell
>  it what numbers to use.

    I expected this to be part of the nnml back-end code.  :-)  

>    Numbers have to be monotonically increasing, so backends will never
>  assign a lower number to a new article when a higher number is
>  already in use.  To make it start from 1, you'd have to convince the
>  backend that the group contains no articles.  That leaves us with
>  Lloyd's way. 

    While I can see from the structure of the data in .newsrc and
  ~/Mail/active that this is important, I don't think that this is
  actually relevant in the case I'm dealing with.  I don't expect to
  have new messages delivered interleaved with old ones.

    This has forced me to look into the details slightly more than I
  intended to tonight :-) - but it appears that the .overview file
  already contains an adequate amount of information to use the same
  algorithm that nmh uses.

    But, I can see that my specification is incomplete:


;;; Proposed:  Add a new function nnml-pack-directory to nnml.el 
;;;
;;; Purpose:  This function will renumber articles within a directory so
;;;                   that they are densely numbered starting from
;;;                   number 1. 
;;;
;;; Algorithm:
;;;
;;;  Step 0:  flock() the directory - if possible - to prevent new
;;;               articles from being delivered while we are
;;;               renumbering.
;;;
;;;  Step 1:  Read group info from ~/Mail/active, taking special note of:
;;;                current max article number
;;;
;;;  Step 2:  Create a list of directory info 'ldinfo from .overview
;;;                and note the number of entries read 'n
;;;
;;;                Each article has an entry like this:
;;;                (article_num Subject: From: Date: Message-ID:
;;;                                                   Size_in_bytes Lines: Xref:)
;;;
;;;                 We will form a list of these entries.
;;;
;;;                 Note: the .overview file is in numeric article
;;;                           number order.
;;;
;;;  Step 3:   Modify the entry for this directory in ~/Mail/active to
;;;                 reflect that the new last article # is the current
;;;                 last + n, where n is the number of entries read in
;;;                 Step 2.
;;;
;;;                 Note:  This is protection in case we crash while
;;;                 we're renumbering.  All new articles delivered on
;;;                 restart will not end up in the way.
;;;
;;;  Step 4:    Set two variables: 'current_article_num and
;;;                 'next_new_article_num to 1.
;;;
;;;  Step 5:   Set 'current_article_num = (car (car ldinfo))
;;;
;;;  Step 6:   If (not (eq current_article_num next_new_article_num)),
;;;                 then we want to renumber the current article to
;;;                next_new_article_num
;;;
;;;                Note:  this means changing the following items:
;;;                              article file name
;;;                              Xref: header in the article
;;;                              values in the directory info entry (for
;;;                                 writing back to .overview
;;;
;;;  Step 7:  Add 1 to next_new_article_num and recurse (step 5) on the 
;;;                (cdr ldinfo)
;;;
;;;  Step 8:   Modify the entry for this directory in ~/Mail/active to
;;;                reflect that the new last article # is n, where n is
;;;                the number of entries read in Step 2.
;;;
;;;  Step 9:  unflock() the directory

Comments?

-jon
-- 
------------------
Jon Allen Boone
tex@delamancha.org

Re: Packing nnml folders...

[Paul Jarc]

Jon Allen Boone <tex@delamancha.org> writes:
>   it appears that the .overview file already contains an adequate
>   amount of information to use the same algorithm that nmh uses.

.overview doesn't store marks.  If the backend doesn't store marks,
then you lose marks if you renumber messages other than by respooling.

> ;;;  Step 0:  flock() the directory - if possible - to prevent new
> ;;;               articles from being delivered while we are
> ;;;               renumbering.

I don't think you can do that from Elisp.  I also don't think it's
possible to get a lock even from C without a *writable* file
descriptor, and you can't get a writable descriptor to a directory.  I
also don't know whether that lock would be respected by asynchronous
delivery processes.


paul

Re: Packing nnml folders...

[Kai Großjohann]

On 27 Jul 2001, Lloyd Zusman wrote:

> Are you sure that this double-renaming of nnml groups is really
> supposed to renumber/repack the articles?

No.

> As you can see, the renumbering didn't start at 1, but rather, at
> one number higher than the old highest article number.

Isn't this enough?  I know that it behaves this way, but it's not
necessary for the numbers to start at 1.  It's only important that
there are no holes in the middle.

kai
-- 
~/.signature: No such file or directory

Re: Packing nnml folders...

[Kai Großjohann]

On Fri, 27 Jul 2001, Jon Allen Boone wrote:

> ;;; Proposed:  Add a new function nnml-pack-directory to nnml.el 
> ;;;
> ;;; Purpose:  This function will renumber articles within a directory so
> ;;;                   that they are densely numbered starting from
> ;;;                   number 1. 

This is not easily done from the backend, since Gnus stores article
numbers in ~/.newsrc.eld.

Doing the following is fairly simple and could be written into a
function; why bother with the hard stuff?

M-x set-variable RET gnus-large-newsgroup RET nil RET
C-u RET
M P a
B m <insert-group-name-here> RET
q
M-x set-variable RET gnus-large-newsgroup RET <old-value> RET

kai
-- 
~/.signature: No such file or directory

Re: Packing nnml folders...

[Lloyd Zusman]

Kai.Grossjohann@CS.Uni-Dortmund.DE (Kai Großjohann) writes:

> On Fri, 27 Jul 2001, Jon Allen Boone wrote:
> 
>> ;;; Proposed:  Add a new function nnml-pack-directory to nnml.el 
>> ;;;
>> ;;; Purpose:  This function will renumber articles within a directory so
>> ;;;                   that they are densely numbered starting from
>> ;;;                   number 1. 
> 
> This is not easily done from the backend, since Gnus stores article
> numbers in ~/.newsrc.eld.
> 
> Doing the following is fairly simple and could be written into a
> function; why bother with the hard stuff?
> 
> M-x set-variable RET gnus-large-newsgroup RET nil RET
> C-u RET
> M P a
> B m <insert-group-name-here> RET
> q
> M-x set-variable RET gnus-large-newsgroup RET <old-value> RET

I tried this, and it doesn't renumber the articles from 1.  It just
repacks them to a range starting one higher than the highest article
number of the previous range (as expected).  And besides,
`gnus-large-newsgroup' is already set to nil for me.


Is there a function that will automatically copy all of the newsgroup
customization settings (i.e., the "G c" information) from one group to
another?  If so, then this proposed "repacking from 1" function could
follow the steps I outlined in my previous message, but before
deleting the original group, it could copy its customization settings
to the new group.

As soon as I figure out how to mass-copy the customization settings,
I'll write the function that does this "repacking from 1" operation
for nnml groups.

Any ideas?


> kai
> -- 
> ~/.signature: No such file or directory


-- 
 Lloyd Zusman
 ljz@asfast.com

Re: Packing nnml folders...

[Kai Großjohann]

On 28 Jul 2001, Lloyd Zusman wrote:

> I tried this, and it doesn't renumber the articles from 1.

It is not necessary for the numbers to start at 1.

kai
-- 
~/.signature: No such file or directory

Re: Packing nnml folders...

[Lloyd Zusman]

Kai.Grossjohann@CS.Uni-Dortmund.DE (Kai Großjohann) writes:

> On 28 Jul 2001, Lloyd Zusman wrote:
> 
>> I tried this, and it doesn't renumber the articles from 1.
> 
> It is not necessary for the numbers to start at 1.

The original poster asked for the numbers to start at 1.  I also have
a desire for the numbers to start at 1.  I understad that for you, it
isn't necessary for the numbers to start at 1, and so therefore, much
of this discussion probably doesn't pertain to you.


> kai
> -- 
> ~/.signature: No such file or directory


-- 
 Lloyd Zusman
 ljz@asfast.com

Re: Packing nnml folders...

[Paul Jarc]

Lloyd Zusman <ljz@asfast.com> writes:
> As soon as I figure out how to mass-copy the customization settings,
> I'll write the function that does this "repacking from 1" operation
> for nnml groups.

I don't think it would have to be specific to nnml.  If you were going
to involve a particular backend, then you might as well make the
backend store marks.  Then the renumbering could be done
automatically, without requiring user intervention.


paul

Re: Packing nnml folders...

[Kai Großjohann]

On 28 Jul 2001, Lloyd Zusman wrote:

> The original poster asked for the numbers to start at 1.  I also
> have a desire for the numbers to start at 1.  I understad that for
> you, it isn't necessary for the numbers to start at 1, and so
> therefore, much of this discussion probably doesn't pertain to you.

Hm.  Hmmmm...

*innocent look*

Why is it useful to have the numbers start at one?

kai
-- 
~/.signature: No such file or directory

Re: Packing nnml folders...

[Lloyd Zusman]

Kai.Grossjohann@CS.Uni-Dortmund.DE (Kai Großjohann) writes:

> On 28 Jul 2001, Lloyd Zusman wrote:
> 
>> The original poster asked for the numbers to start at 1.  I also
>> have a desire for the numbers to start at 1.  I understad that for
>> you, it isn't necessary for the numbers to start at 1, and so
>> therefore, much of this discussion probably doesn't pertain to you.
> 
> Hm.  Hmmmm...
> 
> *innocent look*
> 
> Why is it useful to have the numbers start at one?

I can't speak for the original poster, but for me, the reason is this:
I have utilities that operate outside of Gnus that do various things
to certain lists of pre-received messages that I keep.  I find Gnus
and nnml to be particularly useful for managing this list of messages,
because then each one of them resides in a nice, uniquely named file
in a known directory.  I find it quite desirable and convenient for
these utilities of mine to always operate on a set of messages whose
file names consist of a monotonically increasing sequence of numbers
that begin with 1.

I don't want this for all my nnml groups, but for a select subset that
has importance to me.

For me, this is more than enough reason to want a more convenient way
to maintain this list of messages whose numbers are packed and start
at 1.  Up until now, I didn't discuss this in this group, however,
because it seemed to be of idiosyncratic interest to only myself.  But
now that others have started talking about wanting, each for his or
her own reasons, to number certain lists of messages in the same way,
it seems to me that it has become appropriate for me to contribute my
ideas to this thread.

And by the way ... even as we speak (er, write), I'm in the process of
writing a function that will renumber nnml groups in this exact
manner.  I will post it here for discussion once I'm finished.
Perhaps some people besides me will find it to be useful.


> kai
> -- 
> ~/.signature: No such file or directory
> 

-- 
 Lloyd Zusman
 ljz@asfast.com

Re: Packing nnml folders...

[Lloyd Zusman]

prj@po.cwru.edu (Paul Jarc) writes:

> Lloyd Zusman <ljz@asfast.com> writes:
>> As soon as I figure out how to mass-copy the customization settings,
>> I'll write the function that does this "repacking from 1" operation
>> for nnml groups.
> 
> I don't think it would have to be specific to nnml.  If you were going
> to involve a particular backend, then you might as well make the
> backend store marks.  Then the renumbering could be done
> automatically, without requiring user intervention.

I agree that this would be the ideal way to handle group renumbering.

However, I'm not too familiar with backend processing, and so for the
moment, I don't feel confident enough to tackle that task.  Maybe one
of these days ... <sigh>

But for the time being, I've hacked out a function that will renumber
and repack an nnml group.  You can see it below.

WARNING!!! ... this is experimental.  I've tested it within my own
environment and it seems to work, but I wouldn't rely on it without a
lot more testing.  Be sure to BACK UP EVERYTHING before playing with
it.

And even if it seems to work, I strongly recommend to not yet make it
part of Gnus until a lot more error checking is inserted into the
code.  Also, I think that it can be rewritten to be more efficient.
Please remember that THIS IS STILL EXPERIMENTAL.

Nevertheless, it works for me, and if nothing else, it's a proof of
concept.  What do you folks think of it?

;; Helper function: return a unique, temporary group name
;; that's based on a specified nnml group name.
(defun create-temp-nnml-group-name (group)
  (let ((temp-name-pattern (concat group "-temp-%d"))
	(n 0)
	temp-name)
    ;; Uniqueness test:  1. make sure that no group exists
    ;;                      with the same name
    ;;                   2. make sure that there's no
    ;;                      nnml directory for a group
    ;;                      of this name (such a directory
    ;;                      might still exist if a group
    ;;                      with the specified name was
    ;;                      previously deleted)
    (while (or (gnus-gethash
		(setq temp-name (format temp-name-pattern n))
		gnus-newsrc-hashtb)
	       (file-directory-p
		(nnmail-group-pathname
		 (gnus-group-real-name temp-name) nnml-directory)))
      (setq n (1+ n)))
    temp-name))

;; Repack and renumber an nnml group.  I only allow this to work
;; if it's invoked from within the Group buffer.
(defun repack-and-renumber-nnml-group (group)
  (interactive (list
		(gnus-completing-read
		 (gnus-group-group-name)
		 "Group:" gnus-active-hashtb
		 nil 'require-match)))
  (unless (eq (current-buffer) (get-buffer gnus-group-buffer))
    (error "Must be invoked from within the %s buffer"
	   gnus-group-buffer))
  ;; Get the first temporary group name.
  (let ((temp-group-1 (create-temp-nnml-group-name group))
	temp-group-2)
    ;; Enter the group, with all articles visible.
    (gnus-group-read-group t t group)
    ;; Mark every article
    (gnus-uu-mark-all)
    ;; Copy the articles to the temporary group.
    ;; NOTE: if you're confident that all of this will
    ;;       work, you can change the following
    ;;       function to `gnus-summary-move-article'.
    (gnus-summary-copy-article nil temp-group-1)
    ;; Make sure we're back in the Group buffer
    (gnus-summary-exit)
    ;; Make sure that tne newly created temporary
    ;; group is of the same level as the original;
    ;; also positions the new group right before
    ;; the original.
    (gnus-group-change-level temp-group-1
			     (gnus-group-level group)
			     (gnus-group-level temp-group-1)
			     group)
    ;; Make sure that the new group has the same
    ;; customization parameters as the original.
    (gnus-group-set-info 
     (gnus-info-params (gnus-get-info group))
     temp-group-1
     'params)
    ;; We need to get the next temporary group name
    ;; now, *after* the first temporary group has
    ;; been created.
    (setq temp-group-2 (create-temp-nnml-group-name group))
    ;; Rename everything.  For some reason, it's
    ;; necessary to list all the groups before
    ;; renaming and deleting.
    (gnus-group-list-groups gnus-level-unsubscribed t)
    (gnus-group-rename-group group temp-group-2)
    (gnus-group-list-groups gnus-level-unsubscribed t)
    (gnus-group-rename-group temp-group-1 group)
    ;; Delete the original group, which has now been
    ;; renamed.  You'll be prompted for this.  If
    ;; you're really brave, add a fourth parameter
    ;; `t' to the following function invocation
    ;; to avoid the prompt.
    (gnus-group-list-groups gnus-level-unsubscribed t)
    (gnus-group-delete-group temp-group-2 t)))



-- 
 Lloyd Zusman
 ljz@asfast.com

Re: Packing nnml folders...

[Lloyd Zusman]

Lloyd Zusman <ljz@asfast.com> writes:

> [ ... ]
> 
> But for the time being, I've hacked out a function that will renumber
> and repack an nnml group.  You can see it below.

Here's a new-and-improved version.  It's more efficient, and there are
a couple of subtle bugs that were fixed.

However, it's still expermental, and it's very light on error
checking.  Therefore, don't forget to back up everything before you
play with this.

;; Helper function: return a unique, temporary group name
;; that's based on a specified nnml group name.
(defun create-temp-nnml-group-name (group)
  (let ((method (gnus-find-method-for-group group))
	(temp-name-pattern (concat group "-temp-%d"))
	(n 0)
	temp-name group-dir)
    (unless (eq (car method) 'nnml)
      (error "Not an nnml group: %s" group))
    (setq group-dir (expand-file-name (nth 1 (nth 2 method))))
    ;; Uniqueness test:  1. make sure that no group exists
    ;;                      with the same name
    ;;                   2. make sure that there's no
    ;;                      nnml directory for a group
    ;;                      of this name (such a directory
    ;;                      might still exist if a group
    ;;                      with the specified name was
    ;;                      previously deleted)
    (while (or (gnus-gethash
		(setq temp-name (format temp-name-pattern n))
		gnus-newsrc-hashtb)
	       (file-directory-p
		(nnmail-group-pathname
		 (gnus-group-real-name temp-name) group-dir)))
      (setq n (1+ n)))
    temp-name))

;; Repack and renumber an nnml group.  I only allow this to work
;; if it's invoked from within the Group buffer.
(defun repack-and-renumber-nnml-group (group)
  (interactive
   (progn
     (unless (eq (current-buffer) (get-buffer gnus-group-buffer))
       (error "This function should only be invoked from within the %s buffer."
	      gnus-group-buffer))
     (list (gnus-completing-read (gnus-group-group-name)
				 "Group:" gnus-active-hashtb
				 nil 'require-match))))
  ;; Make sure that `gnus-large-newsgroup' is nil;
  ;; also, get a unique temporary group name.  We
  ;; have to be inside of an nnml group in order
  ;; for us to get a proper temporary name.
  (let* ((gnus-large-newsgroup nil)
	 (temp-group (create-temp-nnml-group-name group)))
    ;; First, rename the group.  For some reason, it's
    ;; necessary to list all the groups before either
    ;; renaming or deleting.
    (gnus-group-list-groups gnus-level-unsubscribed t)
    (gnus-group-rename-group group temp-group)
    ;; Enter this new group, with all articles visible.
    (gnus-group-read-group t t temp-group)
    ;; Mark every article
    (gnus-uu-mark-all)
    ;; Move the articles to the new group.  If
    ;; you aren't confident about moving them,
    ;; un-comment out the first line and comment
    ;; out the second.
    ;;;(gnus-summary-copy-article nil group)
    (gnus-summary-move-article nil group)
    ;; Get back to the Group buffer
    (gnus-summary-exit)
    ;; Make sure that the newly created group is
    ;; at the same level as the original; also,
    ;; position the new group right next to the
    ;; original.
    (gnus-group-change-level group (gnus-group-level temp-group)
			     (gnus-group-level group) temp-group)
    ;; Make sure that the new group has the same
    ;; customization parameters as the original.
    (gnus-group-set-info (gnus-info-params (gnus-get-info temp-group))
			 group 'params)
    ;; Delete the original group, which has already
    ;; been renamed.  You'll be prompted for this.
    (gnus-group-list-groups gnus-level-unsubscribed t)
    (when (yes-or-no-p (format "Delete empty group %s? " temp-group))
      (gnus-group-delete-group temp-group t t))))


-- 
 Lloyd Zusman
 ljz@asfast.com

Re: Packing nnml folders...

[Kai Großjohann]

On 28 Jul 2001, Lloyd Zusman wrote:

> prj@po.cwru.edu (Paul Jarc) writes:
> 
>> Lloyd Zusman <ljz@asfast.com> writes:
>>> As soon as I figure out how to mass-copy the customization
>>> settings, I'll write the function that does this "repacking from
>>> 1" operation for nnml groups.
>> 
>> I don't think it would have to be specific to nnml.  If you were
>> going to involve a particular backend, then you might as well make
>> the backend store marks.  Then the renumbering could be done
>> automatically, without requiring user intervention.
> 
> I agree that this would be the ideal way to handle group
> renumbering.
> 
> However, I'm not too familiar with backend processing, and so for
> the moment, I don't feel confident enough to tackle that task.
> Maybe one of these days ... <sigh>

I don't think it's too complicated.  I don't have the time, though.  I
guess that both Simon and Paul can help you out of a bind if you can't
complete the job, since they have written backends which store marks.

Basically, I think it just amounts to implementing two functions.
Their purpose is explained in the Gnus info file.  Lessee...  Ah.
Node `Optional Backend Functions', functions
nnchoke-request-update-info, nnchoke-request-set-mark,
nnchoke-request-update-mark.  Seems simple enough.

I think it would be a good idea if someone would implement server-side
marks for nnmail-derived backends.

kai
-- 
~/.signature: No such file or directory

Re: Packing nnml folders...

[Lloyd Zusman]

Kai.Grossjohann@CS.Uni-Dortmund.DE (Kai Großjohann) writes:

> I don't think it's too complicated.  I don't have the time, though.  I
> guess that both Simon and Paul can help you out of a bind if you can't
> complete the job, since they have written backends which store marks.

Thanks ... well, first it has to be established that I would be doing
this in the first place ... :)   Right now I haven't time, either.  But
at least I hacked out that other function.

But if I do decide to do any back-end work, I will approach Simon and
Paul if I need help.


> [ ... ]
> 
> I think it would be a good idea if someone would implement server-side
> marks for nnmail-derived backends.

I agree.

Someone ... ???  :)


> kai
> -- 
> ~/.signature: No such file or directory

-- 
 Lloyd Zusman
 ljz@asfast.com