set labels in nnml or nnfolder groups

set labels in nnml or nnfolder groups

[Uwe Brauer]

Hello

A while ago I asked whether it is posible to set labels in nnimap
groups and the answer was, not yet. 

Now I cannot find in the manual anything about labels in (local)
groups such that nnml and nnfolder.

By label I understand things like
IM (important)
NR (need reply)

Etc.

Vm has this and it is very useful

Thanks


Uwe Brauer 

Re: set labels in nnml or nnfolder groups

[Reiner Steib]

On Mon, Feb 06 2006, Uwe Brauer wrote:

> A while ago I asked whether it is posible to set labels in nnimap
> groups and the answer was, not yet. 
>
> Now I cannot find in the manual anything about labels in (local)
> groups such that nnml and nnfolder.
>
> By label I understand things like
> IM (important)
> NR (need reply)

Below is a *draft* version to display the content of an X-Gnus-Label
header by adding "%4u&label;" in `gnus-summary-line-format'.  What is
missing is a command to add labels without manually editing the
article.

--8<---------------cut here---------------start------------->8---
;; Related URLs:
;; http://thread.gmane.org/m2n05mr2iv.fsf%40catbert.dok.org
;; http://www.fas.harvard.edu/computing/kb/kb1059.html
;; http://ilias.ca/blog/2005/09/gmail-labels-in-thunderbird.html

(defcustom rs-gnus-summary-line-label-alist
  '(("Important" "Im")
    ("Work" "Wo")
    ("Personal" "Pe")
    ("To do" "TD")
    ("Later" "La")
    ("Need reply" "NR"))
  "Alist of regular expressions and summary line indicators."
  :group 'gnus-summary-format
  :type '(repeat (list (regexp :tag "Regexp")
		       (string :tag "Indicator"))))

;;;###autoload
(defun rs-gnus-summary-line-label (header)
  "Display label of message in summary line.

This function is intended to be used in `gnus-summary-line-format-alist', with
\(defalias 'gnus-user-format-function-X 'rs-gnus-summary-line-label).
See (info \"(gnus)Group Line Specification\").

You need to add `X-Gnus-Label' to `nnmail-extra-headers' and
`gnus-extra-headers', see Info node `(gnus)To From Newsgroups'."
  (let ((case-fold-search t)
	(label (or (cdr (assq 'X-Gnus-Label (mail-header-extra header)))
		   ""))
	indicator)
    (mapc (lambda (el)
	    (when (string-match (car el) label)
	      (setq indicator (cadr el))))
	  rs-gnus-summary-line-label-alist)
    (if indicator
	indicator
      label)))

;;;###autoload
(defun rs-gnus-summary-limit-to-label (regexp &optional not-matching)
  "Limit the summary buffer to articles that match a label."
  (interactive
   (list (read-string
	  (format "%s label (regexp): "
		  (if current-prefix-arg "Exclude" "Limit to")))
	 current-prefix-arg))
  (gnus-summary-limit-to-extra 'X-Gnus-Label regexp not-matching))

(defalias 'gnus-user-format-function-label 'rs-gnus-summary-line-label)
--8<---------------cut here---------------end--------------->8---

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

Re: set labels in nnml or nnfolder groups

[Uwe Brauer]

>>>>> "Reiner" == Reiner Steib <reinersteib+gmane@imap.cc> writes:

   Reiner> Below is a *draft* version to display the content of an
   Reiner> X-Gnus-Label header by adding "%4u&label;" in
   Reiner> `gnus-summary-line-format'.  What is missing is a command
   Reiner> to add labels without manually editing the article.

Great, thanks, that was what I was looking for 8-). I tested it and it
works nicely, (I don't mind to edit the article since I want to make
sparse use of this feature.) However it seems that this approach can
not be used for nnimap groups, right?


   Reiner> --8<---------------cut here---------------start------------->8---
   Reiner> ;; Related URLs:
   Reiner> ;; http://thread.gmane.org/m2n05mr2iv.fsf%40catbert.dok.org
   Reiner> ;; http://www.fas.harvard.edu/computing/kb/kb1059.html
   Reiner> ;; http://ilias.ca/blog/2005/09/gmail-labels-in-thunderbird.html

I really searched via google, but did not find any of these links :(


Uwe 

mozilla (was: set labels in nnml or nnfolder groups)

[Uwe Brauer]

>>>>> "Reiner" == Reiner Steib <reinersteib+gmane@imap.cc> writes:


   Reiner> Below is a *draft* version to display the content of an
   Reiner> X-Gnus-Label header by adding "%4u&label;" in
   Reiner> `gnus-summary-line-format'.  What is missing is a command
   Reiner> to add labels without manually editing the article.

I just checked mozilla, for messages on a imap server. So mozilla
does not seem to add anything to the header, no new X-whatsoever
field, but instead seems to storage the label in another place. 

Moreover I  used mozilla to set a label which also was understood by
mozilla-thunderbird, although both seem different directories for
their setting and local information. So I am now puzzled where is this
information stored.

If this is a general enough place somewhere on the imap server, may be
gnus could read and display it as well.

Uwe 

Re: mozilla

[Ted Zlatanov]

On  6 Feb 2006, oub@mat.ucm.es wrote:

>>>>>> "Reiner" == Reiner Steib <reinersteib+gmane@imap.cc> writes:
>
> Reiner> Below is a *draft* version to display the content of an
> Reiner> X-Gnus-Label header by adding "%4u&label;" in
> Reiner> `gnus-summary-line-format'.  What is missing is a command
> Reiner> to add labels without manually editing the article.
>
> I just checked mozilla, for messages on a imap server. So mozilla
> does not seem to add anything to the header, no new X-whatsoever
> field, but instead seems to storage the label in another place. 

That's part of the IMAP protocol I believe.  It would be nice,
however, if nnimap.el could transform those labels into header entries
like the ones Reiner showed.  That's the quick-and-dirty solution.

Would it be more appropriate to add basic nn* functions to
get/set/list labels, and implement them in every backend?  That would
be a cleaner solution, but I would imagine a lot of work, especially
with the Agent and with simpler backends.  On the other hand,
implementing empty wrappers for most backends except nnimap may not be
too much work.

Ted

Re: mozilla

[Uwe Brauer]

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

   Ted> On  6 Feb 2006, oub@mat.ucm.es wrote:
   >>>>>>> "Reiner" == Reiner Steib <reinersteib+gmane@imap.cc> writes:

   Ted> That's part of the IMAP protocol I believe.  It would be nice,
I see

   Ted> however, if nnimap.el could transform those labels into header
   Ted> entries like the ones Reiner showed.  That's the
   Ted> quick-and-dirty solution.

Well I wrote a quick and very dirty solution by adding a label to
nnmail or nnfolder articles, using  gnus-summary-edit-article. This
function even allows to edit imap articles (using the second argument)

*If ARG is 2, edit the raw articles even in read-only groups.*

However the saving is not a real saving so this does not help (whether
it is a clever idea to raw edit mime articles is another question).

Do you think it is easy to implement a solution for the nnimap
backend?  

Meanwhile another solution occurred to me, after having read the
discussion in the links Rainer mentioned. I saw that some people have
a solution the other way around.  Instead of putting labels in the
group, they put labels in there corresponding planner entries. I just
remembered I have a similar solution for the todo-mode.el pkg written
by Oliver Seidel. My function adds the subject, message-ID and group
name as an todo entry in the category email. May be I should enhance
that for other categories, like NeedReply, Important etc.


Btw Ted do you recall our discussion about a generalizing
gnus-summary-limit function to include BBDB or NO BBDB entries. Your
solution worked for all net address in a BBDB entry save the first
one, mine vice verse, however you claimed that your function could do
both, but you had to look into it. Did you do that?

Uwe 

Re: mozilla

[Uwe Brauer]

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

   Ted> On  6 Feb 2006, oub@mat.ucm.es wrote:
   >>>>>>> "Reiner" == Reiner Steib <reinersteib+gmane@imap.cc> writes:

   Ted> That's part of the IMAP protocol I believe.  It would be nice,
I see

   Ted> however, if nnimap.el could transform those labels into header
   Ted> entries like the ones Reiner showed.  That's the
   Ted> quick-and-dirty solution.

Well I wrote a quick and very dirty solution by adding a label to
nnmail or nnfolder articles, using  gnus-summary-edit-article. This
function even allows to edit imap articles (using the second argument)

*If ARG is 2, edit the raw articles even in read-only groups.*

However the saving is not a real saving so this does not help (whether
it is a clever idea to raw edit mime articles is another question).

Do you think it is easy to implement a solution for the nnimap
backend?  

Meanwhile another solution occurred to me, after having read the
discussion in the links Rainer mentioned. I saw that some people have
a solution the other way around.  Instead of putting labels in the
group, they put labels in there corresponding planner entries. I just
remembered I have a similar solution for the todo-mode.el pkg written
by Oliver Seidel. My function adds the subject, message-ID and group
name as an todo entry in the category email. May be I should enhance
that for other categories, like NeedReply, Important etc.


Btw Ted do you recall our discussion about a generalizing
gnus-summary-limit function to include BBDB or NO BBDB entries. Your
solution worked for all net address in a BBDB entry save the first
one, mine vice verse, however you claimed that your function could do
both, but you had to look into it. Did you do that?

Uwe 

Re: mozilla

[Ted Zlatanov]

On  7 Feb 2006, oub@mat.ucm.es wrote:

>>>>>> "Ted" == Ted Zlatanov <tzz@lifelogs.com> writes:
>
> Ted> On  6 Feb 2006, oub@mat.ucm.es wrote:
>>>>>>>> "Reiner" == Reiner Steib <reinersteib+gmane@imap.cc> writes:
>
> Ted> That's part of the IMAP protocol I believe.  It would be nice,
> I see
>
> Ted> however, if nnimap.el could transform those labels into header
> Ted> entries like the ones Reiner showed.  That's the
> Ted> quick-and-dirty solution.
>
> Well I wrote a quick and very dirty solution by adding a label to
> nnmail or nnfolder articles, using  gnus-summary-edit-article. This
> function even allows to edit imap articles (using the second argument)
>
> *If ARG is 2, edit the raw articles even in read-only groups.*
>
> However the saving is not a real saving so this does not help (whether
> it is a clever idea to raw edit mime articles is another question).

I think this is not as good as backend support.  With IMAP, for
example, you can set the labels (flags) for a whole range of messages
at once quickly; with any editing solution it's a lot slower, plus
it's only for Gnus.

> Do you think it is easy to implement a solution for the nnimap
> backend?  

I don't know how much is implemented in imap.el already.  If there is
no support for flags yet, it's a lot of work.

> Meanwhile another solution occurred to me, after having read the
> discussion in the links Rainer mentioned. I saw that some people have
> a solution the other way around.  Instead of putting labels in the
> group, they put labels in there corresponding planner entries. I just
> remembered I have a similar solution for the todo-mode.el pkg written
> by Oliver Seidel. My function adds the subject, message-ID and group
> name as an todo entry in the category email. May be I should enhance
> that for other categories, like NeedReply, Important etc.

I remember this.  We could also use the gnus-registry to associate
message-ID with any custom data, including labels.  I just think that
any Gnus-only solution is worse than a generic solution.

> Btw Ted do you recall our discussion about a generalizing
> gnus-summary-limit function to include BBDB or NO BBDB entries. Your
> solution worked for all net address in a BBDB entry save the first
> one, mine vice verse, however you claimed that your function could do
> both, but you had to look into it. Did you do that?

No, sorry.  I must have dropped the ball on that one.  Can you please
send me the latest versions of your and my code?

Thanks
Ted

Re: mozilla

[Uwe Brauer]

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

   Ted> On  7 Feb 2006, oub@mat.ucm.es wrote:
   >> 
   >> However the saving is not a real saving so this does not help (whether
   >> it is a clever idea to raw edit mime articles is another question).

   Ted> I think this is not as good as backend support.  With IMAP, for
   Ted> example, you can set the labels (flags) for a whole range of messages
   Ted> at once quickly; with any editing solution it's a lot slower, plus
   Ted> it's only for Gnus.

Well and it does not work, because when I save, and reenter the buffer
the editing result is not there anymore. How should the editing
solution work?

   >> Do you think it is easy to implement a solution for the nnimap
   >> backend?  



   Ted> No, sorry.  I must have dropped the ball on that one.  Can you
   Ted> please send me the latest versions of your and my code?


I do this in a private mail.

Uwe 

nnimap: editing articles (was: mozilla)

[Reiner Steib]

On Tue, Feb 07 2006, Uwe Brauer wrote:

> Well and it does not work, because when I save, and reenter the buffer
> the editing result is not there anymore. How should the editing
> solution work?

Article editing isn't implemented in the nnimap back end.  I'm not
sure if the protocol (IMAP) allows it.  Simon?

IIRC someone suggested to move the article to a local group, edit it
and move it back to IMAP might be a workaround.  Thunderbird 1.5
supports deleting and detaching (stripping) attachments which works
also on IMAP.  I just tried it and it seems to me, they do something
similar.  At least when looking at the "modified" article with Gnus, I
saw an `N' (`gnus-recent-mark') and the article number is different.

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

Re: nnimap: editing articles

[Ted Zlatanov]

On  7 Feb 2006, reinersteib+gmane@imap.cc wrote:

On Tue, Feb 07 2006, Uwe Brauer wrote:
>
>> Well and it does not work, because when I save, and reenter the buffer
>> the editing result is not there anymore. How should the editing
>> solution work?
>
> Article editing isn't implemented in the nnimap back end.  I'm not
> sure if the protocol (IMAP) allows it.  Simon?

IMAP does not allow editing, you have to delete and store the new
article, AFAIK (from reading the rev4 RFC).

> IIRC someone suggested to move the article to a local group, edit it
> and move it back to IMAP might be a workaround.  Thunderbird 1.5
> supports deleting and detaching (stripping) attachments which works
> also on IMAP.  I just tried it and it seems to me, they do something
> similar.  At least when looking at the "modified" article with Gnus, I
> saw an `N' (`gnus-recent-mark') and the article number is different.

Right.  So basically, implementing labels is easier with flags than
with IMAP editing, and much faster.

IMAP flags can be any atom name, which means it can not contain:

( ) { % * " \ ]
space
control characters
characters with the high bit (8-bit characters)

I would stick to a-zA-Z0-9_.- as the character set...  It's probably
safer to avoid the other characters such as @ or = IMO.

A custom flag "MyFlag" can be set like this:

APPEND "Inbox" (\Seen MyFlag) [etc...]

I used a message by Mark Crispin to get this information:
http://groups.google.com/group/comp.mail.imap/msg/ab2bab9722a80272?dmode=source&hl=en

I propose that for backends that can't support flags, e.g. nntp or
nnrss, we use the gnus-registry (if installed) to track the flags by
message-ID as a fallback.

Ted

Re: nnimap: editing articles

[Reiner Steib]

On Wed, Feb 08 2006, Ted Zlatanov wrote:

> Right.  So basically, implementing labels is easier with flags than
> with IMAP editing, and much faster.
[...]
> I would stick to a-zA-Z0-9_.- as the character set...  It's probably
> safer to avoid the other characters such as @ or = IMO.

ACK

> A custom flag "MyFlag" can be set like this:
> APPEND "Inbox" (\Seen MyFlag) [etc...]
>
> I used a message by Mark Crispin to get this information:
> http://groups.google.com/group/comp.mail.imap/msg/ab2bab9722a80272?dmode=source&hl=en
[ <news:Pine.LNX.4.63.0504270833510.15123@shiva2.cac.washington.edu> ]

> I propose that for backends that can't support flags, e.g. nntp or
> nnrss, we use the gnus-registry (if installed) to track the flags by
> message-ID as a fallback.

Sound good.

There was a discussion about user-defined flags in Gnus some time ago:
<http://thread.gmane.org/gmane.emacs.gnus.general/59998>.
Simon wrote that Gnus already supports user-defined flags, but that
there's no user interface available.

- For IMAP, the label (or "flag" or "mark") should be stored on the
  server.  There should be a mapping to a Gnus flag.

- Labels should not be lost when the article is copied/moved to a
  local (nnml, nnfolder, nnmaildir, ...) group.

Rmail also supports labels, see (info "(emacs)Rmail Labels").  Where
it makes sense, we could provide a similar user interface.

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

Re: nnimap: editing articles

[Simon Josefsson]

Reiner Steib <reinersteib+gmane@imap.cc> writes:

> On Tue, Feb 07 2006, Uwe Brauer wrote:
>
>> Well and it does not work, because when I save, and reenter the buffer
>> the editing result is not there anymore. How should the editing
>> solution work?
>
> Article editing isn't implemented in the nnimap back end.  I'm not
> sure if the protocol (IMAP) allows it.  Simon?

It doesn't support it.  Messages are read-only in IMAP.

> IIRC someone suggested to move the article to a local group, edit it
> and move it back to IMAP might be a workaround.  Thunderbird 1.5
> supports deleting and detaching (stripping) attachments which works
> also on IMAP.  I just tried it and it seems to me, they do something
> similar.  At least when looking at the "modified" article with Gnus, I
> saw an `N' (`gnus-recent-mark') and the article number is different.

Yup, you'll have to create a new message.

Gnus' editing functionality assume that if you edit article X, it will
be called X after the editing too.  I.e., it doesn't refresh group
information, and doesn't understand when the new article is called Y.
Perhaps that can be fixed, so that 'e' works.  OTOH, perhaps using 'e'
will simply give wrong impressions.  With IMAP, you don't actually
edit the article.  Perhaps some command that will download an article,
put you into an editing buffer, and have a command, say, C-c C-c
"save" it by querying for a destination group (which could be any
group) and then save the new article to that group.  This sounds
rather useful, actually.  Perhaps this is already possible...

Re: nnimap: editing articles

[Ted Zlatanov]

On 11 Feb 2006, jas@extundo.com wrote:

> Gnus' editing functionality assume that if you edit article X, it will
> be called X after the editing too.  I.e., it doesn't refresh group
> information, and doesn't understand when the new article is called Y.
> Perhaps that can be fixed, so that 'e' works.  OTOH, perhaps using 'e'
> will simply give wrong impressions.  With IMAP, you don't actually
> edit the article.  Perhaps some command that will download an article,
> put you into an editing buffer, and have a command, say, C-c C-c
> "save" it by querying for a destination group (which could be any
> group) and then save the new article to that group.  This sounds
> rather useful, actually.  Perhaps this is already possible...

I don't see a problem with using `e' for this.  It's very reasonable,
and will affect other IMAP clients a little bit by appearing to create
a new message, but if we set the flags appropriately that won't be
serious.

What do you think about the discussion between me and Reiner about
custom flags for Gnus in general?  Is that something that imap.el and
nnimap.el can support easily?  Are there any performance issues?

Ted

Re: nnimap: editing articles

[Simon Josefsson]

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

> On 11 Feb 2006, jas@extundo.com wrote:
>
>> Gnus' editing functionality assume that if you edit article X, it will
>> be called X after the editing too.  I.e., it doesn't refresh group
>> information, and doesn't understand when the new article is called Y.
>> Perhaps that can be fixed, so that 'e' works.  OTOH, perhaps using 'e'
>> will simply give wrong impressions.  With IMAP, you don't actually
>> edit the article.  Perhaps some command that will download an article,
>> put you into an editing buffer, and have a command, say, C-c C-c
>> "save" it by querying for a destination group (which could be any
>> group) and then save the new article to that group.  This sounds
>> rather useful, actually.  Perhaps this is already possible...
>
> I don't see a problem with using `e' for this.  It's very reasonable,
> and will affect other IMAP clients a little bit by appearing to create
> a new message, but if we set the flags appropriately that won't be
> serious.

Yep, should work fine.  The 'e' command has to be teached about how to
do this though.

> What do you think about the discussion between me and Reiner about
> custom flags for Gnus in general?  Is that something that imap.el and
> nnimap.el can support easily?  Are there any performance issues?

It shouldn't be difficult to add, imap.el can parse them and set them
fine.  It already use client-specific flags for things like gnus-agent
and other Gnus-specific marks.

Since this would be a new user interface, some care could be made so
it would work well with IMAP.  I think it looks like a neat project,
that doesn't require much modifications to existing code (always a
nice property).  I'm not sure what the user interface would look like
though.  Some ideas:

- Summary buffer markup to print user-specific flags.
  - Perhaps it should be optional, i.e., you'll have
    to press some key to make the flags visible.

- Limiting to certain "tags", searching the user flags?
  - Useful to "tag" messages, i.e., project-name or similar.

- Command to add a tag to current or process-marked messages.
  - Could autocomplete on existing names, or allow the user to enter a
    new flag.

- Command to process mark all messages with a certain user-flag?

...

Re: nnimap: editing articles

[Steven E. Harris]

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

> It's very reasonable, and will affect other IMAP clients a little
> bit by appearing to create a new message, but if we set the flags
> appropriately that won't be serious.

MS Outlook already does this. One can set flags and add all kinds of
Outlook-specific options to a message in an IMAP mailbox; Outlook
marks the original message for deletion and adds a new, augmented
message in its place. This duplicate-delete approach confused me at
first, but it's better than forcing the messages to be logically
immutable.
 
-- 
Steven E. Harris