Please test tentative change: annotations in nnml groups

Please test tentative change: annotations in nnml groups

[Kai Großjohann]

I have made a little change which is committed in CVS.  (The new
function nnml-request-post.)  I hope it doesn't break anything for
anyone.  If it does, you know who to blame.

The idea behind this is that you can store annotations to messages in
your nnml groups.  You do this by composing a followup using `S n' or
`S N'.  Then you insert the right group name in the Newsgroups header,
write your stuff, and off you go.

The implementation just consists of the simple function
nnml-request-post which has been copied nearly verbatim from
nnimap-request-post.

A number of questions come to my mind:

* Is this useful for anyone out there?

* The implementation seems to be nearly independent of the backend.
  Some code reuse seems to be in order.

* The code still has some warts: after `S n', the Newsgroups header is
  not filled out.  You get a y/n prompt when attempting to post -- you
  can just answer yes, but it'd be nice if the prompt went away.
  (Gnus is checking the wrong server for the existence of a group.)

* The code does not meaningfully work unless gnus-post-method is set
  to current.

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

Re: Please test tentative change: annotations in nnml groups

[Harry Putnam]

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

> I have made a little change which is committed in CVS.  (The new
> function nnml-request-post.)  I hope it doesn't break anything for
> anyone.  If it does, you know who to blame.

Tested a little here, but until I figure out what is is in cvs gnus
and emacs-21 that broke fontlocking in message-mode buffers, I'm using
an older (03) Oort.  If your new code is available in a patch maybe I
can patch the 03 version and test it better that way.

> The idea behind this is that you can store annotations to messages in
> your nnml groups.  You do this by composing a followup using `S n' or
> `S N'.  Then you insert the right group name in the Newsgroups header,
> write your stuff, and off you go.

I see a few things that might make it more usable.  

1) Somehow allow completion for where to send it.
2) Create a new group if the group given is not already extant.

3) It seems to complicate things to actually send by nntp backend.
   For example.  If running `unplugged' it gets queued until next batch
   fetch/send.

Kai you helped me write something very similar long ago, using a
little different mechanism.  insert-into-group and making use of all
compose or edit modes to annotate then insert, leaving the original
intact.
It will also appear with the original in threaded view but isn't a
true followup necessarily unless you use f/F to compose it.  And can
have some weird looking `fudged out' headers if you don't
message-generate-header-first.  

It does avoid the query you mention, allows completion, and will
create a group for you if needed. But as it stands you have to kill
the edited buffer after the insert.  I never cleaned it up any more
since it did all I wanted as is.

(defun hp-insert-into-group (name)
 "Lars code (modified hp with help form Kai G.) to send messages 
  from editing modes to gnus group directly.  Prompting for group 
  name and method"
  (interactive
   (list
      (gnus-request-accept-article
      (gnus-read-move-group-name " save" nil nil nil)))))

(defun hp-message-mode-hook ()
  "Defines kbd C-x a to execute 'hp-insert-into-group'"
  (define-key message-mode-map (kbd "C-x a") 'hp-insert-into-group))
(add-hook 'message-mode-hook 'hp-message-mode-hook)

(defun hp-gnus-article-edit-mode-hook ()
  "Defines kbd C-x a to execute 'hp-insert-into-group'"
  (define-key gnus-article-edit-mode-map (kbd "C-x a") 'hp-insert-into-group))
(add-hook 'gnus-article-edit-mode-hook 'hp-gnus-article-edit-mode-hook)

Your new technique looks simpler .. Maybe something above is usable?

> A number of questions come to my mind: 
> * Is this useful for anyone out there?

It is to me.  I keep an nnml:Edited directory of several hundred
messages that seemed particularly salient about something.  Annotated
to taste and saved in the nnml:Edited group where I use a special
indexing technique edited into the subject and a Keywords line to
look stuff up.

ls Mail/Edited|wc -l
    491

So definitely would be handy here.  Since your using the Newsgoup
header, does that mean that completion is no available?

Re: Please test tentative change: annotations in nnml groups

[Kai Großjohann]

On Sat, 21 Jul 2001, Harry Putnam wrote:

> I see a few things that might make it more usable.  
> 
> 1) Somehow allow completion for where to send it.

That's definitely a good idea.  I wish message-expand-group would grok
(setq gnus-post-method 'current).  Hm.  But then it wouldn't work for
Gcc, anymore.

So, a new completion function for the Newsgroups header is needed.

Any takers?

(gnus-groups-from-server SERVER) can be used for a list of groups from
the server.  Hm.  What to use for SERVER?  That depends:

(gnus-groups-from-server
 (cond ((equal gnus-post-method 'current)
        gnus-current-select-method)
       (gnus-post-method gnus-post-method)
       (t gnus-select-method)))

So, this should return the right list of groups.  Now, only the actual
completion machinery is needed.

> 2) Create a new group if the group given is not already extant.

Ah, that could be built into nnml-request-post.  Yes, that's a good
idea.  Lessee...  Ah!  It's already built in.  Great work, Simon!

But I haven't tested it; maybe I should.

> 3) It seems to complicate things to actually send by nntp backend.
>    For example.  If running `unplugged' it gets queued until next
>    batch fetch/send.

Have I neglected to mention that it won't work meaningfully unless
gnus-post-method equals current?

> Kai you helped me write something very similar long ago, using a
> little different mechanism.  insert-into-group and making use of all
> compose or edit modes to annotate then insert, leaving the original
> intact.

Hm.  Yeah, your method is also a nice idea.  Maybe something like this
could be added to the Gnus proper?  As you mention, it has some
pitfalls, however, so these should be avoided in some way.

For example, I gather that you use `e' to edit a message, but then use
your mechanism for entering it into the nnml:Edited group rather than
back into the group it came from?

Hm.  Yeah, something like this could be accomplished with my method by
composing a followup but posting it to a different server.  I'm not
sure, however, if it works to use `C-u 0 C-c C-c' to post to a
different server.
 
> It will also appear with the original in threaded view but isn't a
> true followup necessarily unless you use f/F to compose it.  And can
> have some weird looking `fudged out' headers if you don't
> message-generate-header-first.  
> 
> It does avoid the query you mention, allows completion, and will
> create a group for you if needed. But as it stands you have to kill
> the edited buffer after the insert.  I never cleaned it up any more
> since it did all I wanted as is.
> 
> (defun hp-insert-into-group (name)
>  "Lars code (modified hp with help form Kai G.) to send messages 
>   from editing modes to gnus group directly.  Prompting for group 
>   name and method"
>   (interactive
>    (list
>       (gnus-request-accept-article
>       (gnus-read-move-group-name " save" nil nil nil)))))
> 
> (defun hp-message-mode-hook ()
>   "Defines kbd C-x a to execute 'hp-insert-into-group'"
>   (define-key message-mode-map (kbd "C-x a") 'hp-insert-into-group))
> (add-hook 'message-mode-hook 'hp-message-mode-hook)
> 
> (defun hp-gnus-article-edit-mode-hook () "Defines kbd C-x a to
>   execute 'hp-insert-into-group'" (define-key
>   gnus-article-edit-mode-map (kbd "C-x a") 'hp-insert-into-group))
>   (add-hook 'gnus-article-edit-mode-hook
>   'hp-gnus-article-edit-mode-hook)
> 
> Your new technique looks simpler .. Maybe something above is usable?
> 
>> A number of questions come to my mind: 
>> * Is this useful for anyone out there?
> 
> It is to me.  I keep an nnml:Edited directory of several hundred
> messages that seemed particularly salient about something.
> Annotated to taste and saved in the nnml:Edited group where I use a
> special indexing technique edited into the subject and a Keywords
> line to look stuff up.
> 
> ls Mail/Edited|wc -l
>     491
> 
> So definitely would be handy here.  Since your using the Newsgoup
> header, does that mean that completion is no available?

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

Re: Please test tentative change: annotations in nnml groups

[Harry Putnam]

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

> > 3) It seems to complicate things to actually send by nntp backend.
> >    For example.  If running `unplugged' it gets queued until next
> >    batch fetch/send.
> 
> Have I neglected to mention that it won't work meaningfully unless
> gnus-post-method equals current?

You mentioned it.  I probably phrased that poorly.  What I ment was
even with gnus-post-method = current, if you actually send the message
it gets queued of you are in unplugged mode..  Not a bad thing
necessarily, I only mention it in counterposition to the
`insert-into-group' method which doesn't involve actual sending.

Are there benefits derived from sending these annotations?  Seems
cleaner to just insert them.  I mean the idea is to just use this on
disk right?

Re: Please test tentative change: annotations in nnml groups

[Kai Großjohann]

On 21 Jul 2001, Harry Putnam wrote:

> You mentioned it.  I probably phrased that poorly.  What I ment was
> even with gnus-post-method = current, if you actually send the
> message it gets queued of you are in unplugged mode..  Not a bad
> thing necessarily, I only mention it in counterposition to the
> `insert-into-group' method which doesn't involve actual sending.

Ah, now I understand.

> Are there benefits derived from sending these annotations?  Seems
> cleaner to just insert them.  I mean the idea is to just use this on
> disk right?

Well, err.  One advantage is that you can use it together with
gnus-delay.el.  Another advantage is that Gnus does some magic when
sending messages, and by using the normal sending mechanism I can
profit from that magic, without really understanding it.  (One example
of the magic is the header frobbing.  Another example is dealing with
the MML tags.)

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

Re: Please test tentative change: annotations in nnml groups

[Karl Kleinpaste]

Kai.Grossjohann@CS.Uni-Dortmund.DE (Kai Großjohann) writes:
> * The code does not meaningfully work unless gnus-post-method is set
>   to current.

If 'current is a requirement, is there any reason not to set it to
'current aggressively with a "let" in -followup-to-mail?

For me, gnus-post-method is usually '(nntp "dnntp"), but I'd really
like to use this facility.  I'd rather not deploy yet another funny
hook variable to do the "let" myself, since that's all that seems to
be needed.

Re: Please test tentative change: annotations in nnml groups

[Kai Großjohann]

On Sat, 21 Jul 2001, Karl Kleinpaste wrote:

> Kai.Grossjohann@CS.Uni-Dortmund.DE (Kai Großjohann) writes:
>> * The code does not meaningfully work unless gnus-post-method is
>>   set to current.
> 
> If 'current is a requirement, is there any reason not to set it to
> 'current aggressively with a "let" in -followup-to-mail?

Hm.  Hmmmm.  I think that might not be a good idea.  For example,
users might use a different post method on purpose.  For example, you
can use the mechanism to store an annotation in an nnml group even if
the original does not come from the nnml server.

> For me, gnus-post-method is usually '(nntp "dnntp"), but I'd really
> like to use this facility.  I'd rather not deploy yet another funny
> hook variable to do the "let" myself, since that's all that seems to
> be needed.

Hm.  Is it sufficient for you to type `C-u C-c C-c' in those cases
where you need it?  (I mean when you want to store an annotation in an
nnml group.)  I take it that your gnus-post-method is different than
the method you are reading news from?  For if it is the same, you can
probably just set gnus-post-method to current.


It's not at all clear for me what to do.  Basically, the change just
teaches nnml about the Newsgroups header.  It's not clear to me that
it is a good idea to do funky post method stuff just because nnml
groks the Newsgroups header.  What do you think?

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

Re: Please test tentative change: annotations in nnml groups

[Kai Großjohann]

On Sat, 21 Jul 2001, Kai Großjohann wrote:

> The idea behind this is that you can store annotations to messages
> in your nnml groups.  You do this by composing a followup using `S
> n' or `S N'.  Then you insert the right group name in the Newsgroups
> header, write your stuff, and off you go.

It turns out that hitting `C-u 0 C-c C-c' does not allow you to choose
nnml as the posting method.  To achieve this, one would have to change
the nnml backend capabilities from `mail' to `post-mail' (or was it
`mail-post'?).

I'm not sure if we want this, though.

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

Re: Please test tentative change: annotations in nnml groups

[Kai Großjohann]

On Sun, 22 Jul 2001, Kai Großjohann wrote:

> It turns out that hitting `C-u 0 C-c C-c' does not allow you to
> choose nnml as the posting method.  To achieve this, one would have
> to change the nnml backend capabilities from `mail' to `post-mail'
> (or was it `mail-post'?).

I have now done this.

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

Re: Please test tentative change: annotations in nnml groups

[Paul Jarc]

Kai.Grossjohann@CS.Uni-Dortmund.DE (Kai Großjohann) writes:
> * The implementation seems to be nearly independent of the backend.
>   Some code reuse seems to be in order.

I see it's been moved to nnmail-do-request-post.  But it doesn't seem
to be dependent on nnmail; maybe nnheader would be a better place for
it?  nnmaildir, for example, is not derived from nnmail, but could
still use this, I think.


paul

Re: Please test tentative change: annotations in nnml groups

[Kai Großjohann]

On Mon, 30 Jul 2001, Paul Jarc wrote:

> Kai.Grossjohann@CS.Uni-Dortmund.DE (Kai Großjohann) writes:
>> * The implementation seems to be nearly independent of the backend.
>>   Some code reuse seems to be in order.
> 
> I see it's been moved to nnmail-do-request-post.  But it doesn't
> seem to be dependent on nnmail; maybe nnheader would be a better
> place for it?  nnmaildir, for example, is not derived from nnmail,
> but could still use this, I think.

Hm.  Hmmm.  It seems that the functions in nnheader.el are all of a
lower level.  Hm.

And then there is nnoo.el, but that also seems to be the wrong file.

Do we want to create a new file with functions to be used by the
backends?  But then, nnheader.el already has functions that are used
by the backends.  But none of the nnheader functions call any gnus
functions.  Since nnmail-do-request-post calls gnus functions, maybe
it should be put in a gnus*.el file?  Lessee.  [time passes]  No, I
couldn't find a better file.

Other opinions?

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