emulating mozilla's Label command

emulating mozilla's Label command

[Chris Green]

Mozilla mail and probably other mail clients have a feature where you
can mark messages with an integer identifier that maps to some user
defined classification system

 Important,Work,Personal,Todo,Later,etc..

Is there an easy way to emulate this with marks?  I use tick right now
to mean some set of all of those and often things get lost between
important and todo. I've tried working by copying todo's to a special
folder but I'm not trainable enough in that mode.

Something like bookmarks might solve this where you can bookmark
articles in the group.  Is this feature useful for anything currently?

There don't appear to be commands to visit bookmarked articles.  If a
classification system could be imposed on a bookmark-like system with
support for Summary fontification.  Does anyone do anything like this
currently?
-- 
Chris Green <cmg@dok.org>
 "Not everyone holds these truths to be self-evident, so we've worked
                  up a proof of them as Appendix A." --  Paul Prescod

Re: emulating mozilla's Label command

[Wes Hardaker]

>>>>> On Thu, 08 Apr 2004 10:02:32 -0400, Chris Green <cmg@dok.org> said:

Chris> Important,Work,Personal,Todo,Later,etc..

Chris> Is there an easy way to emulate this with marks?  I use tick right now
Chris> to mean some set of all of those and often things get lost between
Chris> important and todo. I've tried working by copying todo's to a special
Chris> folder but I'm not trainable enough in that mode.

You know, I was thinking about something like that just yesterday.

Background: I currently use "unread" as need-to-handle-at-some-point,
and ticked as "critical".  Thus, most of my zillions of folders have
zillions of unread messages in them since I never manage to get
anything done.

What I need, though, is a sorted and combined list of all my
outstanding mail messages (preferably prioritized).  The problem is
that they're spread over a lot of groups, and it would be really slow
opening a whole ton of nnimap groups to generate one large summary
buffer full of todo items from all the groups.  The way around this,
probably, is through the use of the cache or the agent.

What I'd like would be a thread summary something like (badly drawn, sorry):

imap
 \- inbox
  \- family
    - Go to Mom's at 9
    - Help sister with her computer
  \- work
    - Write boss
    \- project1
     - submit report

But the cool thing would be if each of the topics actually came from a
group name (imap.inbox, imap.inbox.family, imap.work,
imap.work.project1), ...  And if all the data was auto-gathered from a
specified list of folders to work on.

I don't think putting something like this together would be terribly
difficult, since the support for much of it already exists (virtual
groups, todos, cache, agent, ...).  It's just a matter of a high-level
wrapper.

-- 
"In the bathtub of history the truth is harder to hold than the soap,
 and much more difficult to find."  -- Terry Pratchett

Re: emulating mozilla's Label command

[Simon Josefsson]

Chris Green <cmg@dok.org> writes:

> Mozilla mail and probably other mail clients have a feature where you
> can mark messages with an integer identifier that maps to some user
> defined classification system
>
>  Important,Work,Personal,Todo,Later,etc..
>
> Is there an easy way to emulate this with marks?

Perhaps there are simpler solution, but your report started a
different process in my mind: It should be easier to introduce new
flags in Gnus.  It should be possible to add user-defined flags.  We
add flags from time to time to Gnus, and the process of doing this is
technically simple, if only you recall to update all places in the
code.  It can probably be generalized and made available as a user
command.  FWIW, I believe several back ends handle non-standard flags
just fine, like at least nnml, nnfolder, and nnimap.

Re: emulating mozilla's Label command

[Sacha Chua]

Wes Hardaker <wes@hardakers.net> writes:

> Background: I currently use "unread" as need-to-handle-at-some-point,
> and ticked as "critical".  Thus, most of my zillions of folders have
> zillions of unread messages in them since I never manage to get
> anything done.

Been there, done that, lost mail! <laugh>

I've since then moved to creating tasks based on e-mail messages using
planner.el . (Disclaimer: I maintain planner.el, so I'm a bit biased.
=) ) I hit a key sequence, type in a short reminder, and schedule the
task for today or some other day (optionally associating it with an
ongoing project). It automatically picks up a link to the current
message. For example, creating one from the parent article would give
me something that looks like

#A0 _ Describe planner from [[gnus://list.emacs.gnus/<sd65catq92.fsf@wes.hardakers.net>][E-Mail from Wes Hardaker]] (PlannerMode)

and it gets marked up as

#A0 _ Describe planner from E-Mail from Wes Hardaker (PlannerMode)

where "E-Mail from Wes Hardaker" and "PlannerMode" are clickable
links. So using an external-to-gnus module like PlannerMode makes my
mail bearable, but it would still be nice to flag things.

I really, really want to be able to color-code my mail so that I can
see which messages are asking for bugfixes, which are asking for
features, and which are just general thoughts. Right now I have a
_lot_ of folders, but this gets hard to manage! <laugh>

PlannerMode is described on
http://emacswiki.org/cgi-bin/wiki/PlannerMode and
http://sacha.free.net.ph/PlannerMode.php

-- 
Sacha Chua <sacha@free.net.ph> - Ateneo CS faculty geekette
interests: emacs, gnu/linux, making computer science education fun
http://sacha.free.net.ph/ - PGP Key ID: 0xE7FDF77C

Re: emulating mozilla's Label command

[Wes Hardaker]

>>>>> On Sat, 10 Apr 2004 18:40:46 +0800, Sacha Chua <sacha@free.net.ph> said:

Sacha> I've since then moved to creating tasks based on e-mail messages using
Sacha> planner.el .

Ok, I'll take a look at it.  It sounds close to what I want, which is
better than where I am now.  It's not, however, ideal (nothing ever is
of course.  No one could use my computer the way it's set up but me) I
don't think, but it certainly is worth looking at.

Sacha> I really, really want to be able to color-code my mail so that I can
Sacha> see which messages are asking for bugfixes, which are asking for
Sacha> features, and which are just general thoughts. Right now I have a
Sacha> _lot_ of folders, but this gets hard to manage! <laugh>

Well, let me return volley with my "gnus-highlight.el" which will let
you do exactly what you want!

Though the color coding is based on reg expression, so you'll either
have to edit the message to change the resulting color or ...

http://www.hardakers.net/elisp/

-- 
"In the bathtub of history the truth is harder to hold than the soap,
 and much more difficult to find."  -- Terry Pratchett

Re: emulating mozilla's Label command

[Ted Zlatanov]

On Thu, 08 Apr 2004, jas@extundo.com wrote:

> Perhaps there are simpler solution, but your report started a
> different process in my mind: It should be easier to introduce new
> flags in Gnus.  It should be possible to add user-defined flags.  We
> add flags from time to time to Gnus, and the process of doing this
> is technically simple, if only you recall to update all places in
> the code.  It can probably be generalized and made available as a
> user command.  

I recall that when I added the spam-mark it was not a simple process,
so any sort of automation would be nice.  

The gnus-registry may also help here.  The registry file can be stored
anywhere (think tramp/scp to a remote server from several clients),
and is backend-neutral.  Most users, I would guess, want to associate
a flag with a message ID, not with an article number.  Since
arbitrary data can be stored in the registry, and lookup is very
fast, this may be a convenient solution that will allow just about any
flag to be added with a minimum amount of effort, and no backend
support is needed.  Just an idea...

Ted

Re: emulating mozilla's Label command

[Kai Grossjohann]

Ted Zlatanov <tzz@lifelogs.com> writes:

> The gnus-registry may also help here.  The registry file can be stored
> anywhere (think tramp/scp to a remote server from several clients),
> and is backend-neutral.

Cool.  But what about people who wish to truncate their registry at a
certain length?  I guess people who use the registry for splitting
with the parent might like to do that.

Kai

Re: emulating mozilla's Label command

[Ted Zlatanov]

On Mon, 12 Apr 2004, kai@emptyhost.emptydomain.de wrote:

> Ted Zlatanov <tzz@lifelogs.com> writes:
> 
>> The gnus-registry may also help here.  The registry file can be
>> stored anywhere (think tramp/scp to a remote server from several
>> clients), and is backend-neutral.
> 
> Cool.  But what about people who wish to truncate their registry at
> a certain length?  I guess people who use the registry for splitting
> with the parent might like to do that.

We can make it so message IDs with extra data, e.g. spam
registration/unregistration or labels, are always preserved.  It could
even be a multiple checkbox choice, so you can keep labels but not
spam reg/unreg info if you wanted.

Adding this is pretty easy, and I just did it for extra data named
'label.  If such extra data exists, the information is not deleted.

On the other hand, if people want to trim the registry by age, that's
a different function, but it's still doable.  Let's see first if
there's interest in storing labels in the registry :)

Ted

Re: emulating mozilla's Label command

[Chris Green]

Ted Zlatanov <tzz@lifelogs.com> writes:

>
> On the other hand, if people want to trim the registry by age, that's
> a different function, but it's still doable.  Let's see first if
> there's interest in storing labels in the registry :)

I'm interested. I composed a reply then machine crashed. <sigh>

I glanced at the registry and it seems separating out the parent
threading functions from what directories the registry actually
watches might be desirable.  

My thinking there is I'd want to watch every single folder for
labeling.It doesn't matter much to me since I don't split much within
gnus.

Rough outline of what needs to be done:
   insert label(s) in registry
   allow display of labels outside of *Summary*
   label commands for *Summary*/*Article*
   allow display of labels outside of *Summary*
   allow display of labels in *Summary*


It looks like the registry cache's enough to make the display of
labels straight from the registry easy.  Would the searching of the
registry for all things having a "label" data be prohibitive?

Doing all that seems to be easier than shoving marks into the backend
and seems to have the benfit of not having to make sure labels get
reassociated with articles across folders.  Certainly better than my
bookmark style ideas ;)
-- 
Chris Green <cmg@dok.org>
Laugh and the world laughs with you, snore and you sleep alone.

Re: emulating mozilla's Label command

[Ted Zlatanov]

On Tue, 13 Apr 2004, cmg@dok.org wrote:
> I glanced at the registry and it seems separating out the parent
> threading functions from what directories the registry actually
> watches might be desirable.  

I don't understand, sorry.

> My thinking there is I'd want to watch every single folder for
> labeling.It doesn't matter much to me since I don't split much
> within gnus.
> 
> Rough outline of what needs to be done:
>    insert label(s) in registry

store label list:
(gnus-registry-store-extra-entry id 'label label-value-list)

fetch label list:
(gnus-registry-fetch-extra id 'label)

>    allow display of labels outside of *Summary*

See above.

>    label commands for *Summary*/*Article*

I don't think there's any letters left :)  Any suggestions are
welcome.  Maybe M-l?

>    allow display of labels in *Summary*

Probably doable with a user display function.  I don't know much about
that side of Gnus.

> It looks like the registry cache's enough to make the display of
> labels straight from the registry easy.  Would the searching of the
> registry for all things having a "label" data be prohibitive?

Yes, but why would you?  You just need to look up the article of
interest by message ID.

Ted

Re: emulating mozilla's Label command

[Chris Green]

Ted Zlatanov <tzz@lifelogs.com> writes:

> On Tue, 13 Apr 2004, cmg@dok.org wrote:
>> I glanced at the registry and it seems separating out the parent
>> threading functions from what directories the registry actually
>> watches might be desirable.  
>
> I don't understand, sorry.

(defcustom gnus-registry-unfollowed-groups '("delayed" "drafts" "queue")
  "List of groups that gnus-registry-split-fancy-with-parent won't follow.
  The group names are matched, they don't have to be fully qualified."
  :group 'gnus-registry
  :type '(repeat string))

I could see not wanting splitting to follow those directories but
being able to label an article an article in drafts as a TODO task and
then pull that task out for as below.

>> It looks like the registry cache's enough to make the display of
>> labels straight from the registry easy.  Would the searching of the
>> registry for all things having a "label" data be prohibitive?
>
> Yes, but why would you?  You just need to look up the article of
> interest by message ID.

Wes Hardaker's thread about:
Wes> What I'd like would be a thread summary something like (badly
Wes> drawn, sorry):
Wes> 
Wes> imap
Wes>  \- inbox
Wes>   \- family
Wes>     - Go to Mom's at 9
Wes>     - Help sister with her computer
Wes>   \- work
Wes>     - Write boss
Wes>     \- project1
Wes>      - submit report
Wes> 
Wes> But the cool thing would be if each of the topics actually came
Wes> from a group name (imap.inbox, imap.inbox.family, imap.work,
Wes> imap.work.project1), ...  And if all the data was auto-gathered
Wes> from a specified list of folders to work on.

I'm convinced that the right hooks could create that later by just
storing the msgids that have labels.

Thanks Ted for the info on the registry, I'll update to CVS gnus and
try it out and see if I can get some summary commands working.
-- 
Chris Green <cmg@dok.org>
To err is human, to moo bovine.

Re: emulating mozilla's Label command

[Ted Zlatanov]

On Thu, 15 Apr 2004, cmg@dok.org wrote:
> Ted Zlatanov <tzz@lifelogs.com> writes:
> 
>> On Tue, 13 Apr 2004, cmg@dok.org wrote:
>>> I glanced at the registry and it seems separating out the parent
>>> threading functions from what directories the registry actually
>>> watches might be desirable.  
>>
>> I don't understand, sorry.
> 
> (defcustom gnus-registry-unfollowed-groups '("delayed" "drafts"
>   "queue") "List of groups that
>   gnus-registry-split-fancy-with-parent won't follow.  The group
>   names are matched, they don't have to be fully qualified."  :group
>   'gnus-registry :type '(repeat string))
> 
> I could see not wanting splitting to follow those directories but
> being able to label an article an article in drafts as a TODO task
> and then pull that task out for as below.

Oh, I see.  That variable only applies to the output of
gnus-registry-split-fancy-with-parent, not to gnus-registry itself.
The gnus-registry tracks articles everywhere.

>>> It looks like the registry cache's enough to make the display of
>>> labels straight from the registry easy.  Would the searching of
>>> the registry for all things having a "label" data be prohibitive?
>>
>> Yes, but why would you?  You just need to look up the article of
>> interest by message ID.
> 
> Wes Hardaker's thread about:
> Wes> What I'd like would be a thread summary something like (badly
> Wes> drawn, sorry):
> Wes> 
> Wes> imap
> Wes>  \- inbox
> Wes>   \- family
> Wes>     - Go to Mom's at 9
> Wes>     - Help sister with her computer
> Wes>   \- work
> Wes>     - Write boss
> Wes>     \- project1
> Wes>      - submit report
> Wes> 
> Wes> But the cool thing would be if each of the topics actually came
> Wes> from a group name (imap.inbox, imap.inbox.family, imap.work,
> Wes> imap.work.project1), ...  And if all the data was auto-gathered
> Wes> from a specified list of folders to work on.
> 
> I'm convinced that the right hooks could create that later by just
> storing the msgids that have labels.

OK, I understand.  The registry will need reverse mappings to do this,
which will use memory and CPU.  So it should be optional, and if it's
off then it will cost the user more CPU to retrieve the reverse
mapping (but the CPU and memory costs will be localized instead of
distributed).  There should be four settings for caching:

t (build cache ASAP and keep it)
nil (never, only build cache when needed and release it afterwards)
'opportunistic (cache is built when needed and reused later)
'(...) (list of types of extra data that should be cached, all others
are built when needed)

This can be a significant concern for people with many thousands of
messages in the registry, so I want to be careful about memory and
CPU use.

What do you think?

Ted

Re: emulating mozilla's Label command

[Chris Green]

Ted Zlatanov <tzz@lifelogs.com> writes:

> The registry will need reverse mappings to do this, which will use
> memory and CPU.  So it should be optional, and if it's off then it
> will cost the user more CPU to retrieve the reverse mapping (but the
> CPU and memory costs will be localized instead of distributed).
> There should be four settings for caching:
>
> t (build cache ASAP and keep it)
> nil (never, only build cache when needed and release it afterwards)
> 'opportunistic (cache is built when needed and reused later)
> '(...) (list of types of extra data that should be cached, all others
> are built when needed)

Ahh that would be a nice generic feature. I was sitting here thinking
of "oh it wouldn't be hard to copy the hash table stuff to make a
reverse map for labels"..

I'm not sure what nil means here.  The purpose of that variable is to
keep memory down at the potential expense of CPU.  In that mode, a
each cache-reverse lookup would have to do an O(N) search.

Put another way:

Is the difference between 'opportunistic and nil:

  1) saving to disk or
  2) creation of an in-memory cache at all

> What do you think?

Seems like a great solution to me.  
-- 
Chris Green <cmg@dok.org>
To err is human, to moo bovine.

Re: emulating mozilla's Label command

[Ted Zlatanov]

On Fri, 16 Apr 2004, cmg@dok.org wrote:

> I'm not sure what nil means here.  The purpose of that variable is
> to keep memory down at the potential expense of CPU.  In that mode,
> a each cache-reverse lookup would have to do an O(N) search.

Right, so nil wouldn't be the default, but people with very low
memory could use it.

I think more granularity than those four levels would be overkill.

> Put another way:
> 
> Is the difference between 'opportunistic and nil:
> 
>   1) saving to disk or
>   2) creation of an in-memory cache at all

Memory.

Ted