bug#2222: 23.0.90; Labels in RMAIL

bug#2222: 23.0.90; Labels in RMAIL

[Xavier Maillard]

       Could one not add a "fake" message at the start of the RMAIL file to
       carry a list of all tags like in babyl?

   It is possible, but we have a decision to make: whether to make
   that message visible in Rmail or hide it.  To hide it would
   require changing perhaps a dozen places.  If we show it, what
   if someone deletes it because it looks like junk?

If it is correctly documented and the message is well identified,
that would not hurt to have it visible. A message with a subject
like "Special rmail message, do not delete" could be enough.

There is also the other possibility to have this message stored
in a `rmail-inbox-list' file member and thus having it out of the
user way quite easily.

	Xavier
-- 
http://www.gnu.org
http://www.april.org
http://www.lolica.org

bug#2222: 23.0.90; Labels in RMAIL

[Richard M Stallman]

    If it is correctly documented and the message is well identified,
    that would not hurt to have it visible. A message with a subject
    like "Special rmail message, do not delete" could be enough.

If Rmail adds this special message
only when the file has messages with labels,
and if the subject says it exists to record the labels,
I think it will be ok to show these messages.
This way, most users won't have these messages, and those who do
will recognize them as serving a specific useful purpose.

The subject could be "Rmail label list for completion".

To hide these messages poses a number of problems that each need
to be solved.  It is less reliable.

For instance, what happens if you concatenate two mbox files to make a
longer one, and the second one has one of these magic messages at the
front?  It will end up in the middle of the combined file.  If these
messages are normally visible, the user will understand how it got
there.  If they are normally hidden, this one will appear out of the
blue.  Or should Rmail be prepared to hide any number of such
messages?  Should it automatically delete any that appear other than
at the start of the file?

Another advantage of showing them is that you can delete them if you
wish.  There might be occasions when you don't want any magic added
message in your file.  If you delete it, it will stay deleted until
you read the file into Rmail once again, or use commands to manage
labels.

bug#2222: 23.0.90; Labels in RMAIL

[Stefan Monnier]

> Another advantage of showing them is that you can delete them if you
> wish.  There might be occasions when you don't want any magic added
> message in your file.  If you delete it, it will stay deleted until
> you read the file into Rmail once again, or use commands to manage
> labels.

In your scenario, I can see why it would make sense to show
the message.  But if such a message is always added (e.g. to store the
"-*-rmail-*-" cookie), then it should be made invisible.

All in all, it'd be better to avoid having to add such a magic message.


        Stefan

bug#2222: 23.0.90; Labels in RMAIL

[Richard M Stallman]

    In your scenario, I can see why it would make sense to show
    the message.  But if such a message is always added (e.g. to store the
    "-*-rmail-*-" cookie), then it should be made invisible.

There is no need for that.  Just to check that it is an Rmail file,
searching for the X-RMAIL-ATTRIBUTES header is sufficient.

bug#2222: 23.0.90; Labels in RMAIL

[Glenn Morris]

Richard M Stallman wrote:

> If Rmail adds this special message
> only when the file has messages with labels,

I think adding a "special message" just so you can offer completion of
labels (in the case where you don't want to generate a summary) is
overly complex and generally not a good idea.

bug#2222: 23.0.90; Labels in RMAIL

[Richard M Stallman]

    I think adding a "special message" just so you can offer completion of
    labels (in the case where you don't want to generate a summary) is
    overly complex and generally not a good idea.

I have no opinion about whether label completion justifies this
complexity.

bug#2222: 23.0.90; Labels in RMAIL

[Xavier Maillard]

   Admittedly, adding a separate file would allow major performance
   improvements, but it would need to be able to react correctly to
   external changes (after all, that's one of the motivation for switching
   to mbox).

Correct.

	Xavier
-- 
http://www.gnu.org
http://www.april.org
http://www.lolica.org

bug#2222: 23.0.90; Labels in RMAIL

[Xavier Maillard]

   All in all, it'd be better to avoid having to add such a magic message.

After some thinking, I tend to agree. Even more, I think we
should deport all X-RMAIL-* headers outside the rmail file and
keep it untouched.

How does other MUA do ? Gnus has a newsrc file AFAIK, we can take
inspiration and implement something like that.

	Xavier
-- 
http://www.gnu.org
http://www.april.org
http://www.lolica.org

bug#2222: 23.0.90; Labels in RMAIL

[Stefan Monnier]

> After some thinking, I tend to agree. Even more, I think we
> should deport all X-RMAIL-* headers outside the rmail file and
> keep it untouched.

Just like it's better to avoid adding a magic message, it's also better
to avoid adding a separate file, I think.  OTOH adding a special header
is pretty harmless.

Admittedly, adding a separate file would allow major performance
improvements, but it would need to be able to react correctly to
external changes (after all, that's one of the motivation for switching
to mbox).


        Stefan

bug#2222: 23.0.90; Labels in RMAIL

[Xavier Maillard]

   Richard M Stallman wrote:

   > If Rmail adds this special message
   > only when the file has messages with labels,

   I think adding a "special message" just so you can offer completion of
   labels (in the case where you don't want to generate a summary) is
   overly complex and generally not a good idea.

I do not agree and as far as I know, label completion is not
working until a label "has been activated during the rmail
session" -i.e. it has nothing to do with summary generation.

Apart this solution and a an third-party index file, how would you
do that ? (Parsing is not the right solution given the fact rmail
files can be quite huge; mine is currently 10K messages ~190Mb).
We must implement something like a TOC inside rmail file and
ideally in a form that would not prevent user on using other mbox
readers to work reliably.

If the addition is not the right thing, maybe an index file
following mbox file naming convention would not hurt:

INBOX.mbox -> INBOX.idx ?

Or a global index file referencing all *already* visited mbox
files with their list of LABELS ? This does not sound complicated
to implement this, does it ?

WDYT ?

	Xavier
-- 
http://www.gnu.org
http://www.april.org
http://www.lolica.org

bug#2222: 23.0.90; Labels in RMAIL

[Xavier Maillard]

       Still missing is completion over all labels defined for a given
       folder. That could be done by scanning all the X-RMAIL-KEYWORDS
       headers, but it might be slow.

   That's why I did not implement it.  In Babyl format, the list was
   stored in the beginning of the file, so this completion could be fast.
   I don't see any reliable way to do that with mbox files.

Why not adding a special "fake" message at the beginning of the
mbox file ? It could also be hidden by default so not to disturb
the user. Or we could maintain a special mbox file with a unique
message (still a fake) where we could store the labels. Reading
and storing labels would not be that slow for a unique and small
message, I guess.

WDYT ?

	Xavier
-- 
http://www.gnu.org
http://www.april.org
http://www.lolica.org

bug#2222: 23.0.90; Labels in RMAIL

[jpff]

Could one not add a "fake" message at the start of the RMAIL file to
carry a list of all tags like in babyl?  The thing I had in mind would
be like the format used in pop, viz

> From MAILER_DAEMON  Thu Apr 26 18:16:43 2007
> Date: Thu, 26 Apr 2007 18:16:43 +0100
> From: Mail System Internal Data <MAILER-DAEMON@snout>
> Subject: DON'T DELETE THIS MESSAGE -- FOLDER INTERNAL DATA
> Message-ID: <1177607803@snout>
> X-IMAP: 1177607795 0000000097
> Status: RO
> 
> This text is part of the internal format of your mail folder, and is not
> a real message.  It is created automatically by the mail system software.
> If deleted, important folder data will be lost, and it will be re-created
> with the data reset to initial values.

Surely that would not be expensive and would allow a tag list to
remain, and possibly even carry the -*- rmail -*- stuff?

==John ffitch

bug#2222: 23.0.90; Labels in RMAIL

[Richard M Stallman]

    Could one not add a "fake" message at the start of the RMAIL file to
    carry a list of all tags like in babyl?

It is possible, but we have a decision to make: whether to make
that message visible in Rmail or hide it.  To hide it would
require changing perhaps a dozen places.  If we show it, what
if someone deletes it because it looks like junk?

bug#2222: 23.0.90; Labels in RMAIL

[jpff]

Labels in Rmail no longer provide completion as they did.  I realise
this is because the Babyl format maintained a list of labels at start
of the file, but this is a loss of functionality.  Surely which
scanning for the ^From lines one could maintain a label list?
  Would also help towards stopping multiple identical labels
  perhaps...



In GNU Emacs 23.0.90.5 (i686-pc-linux-gnu, GTK+ Version 2.12.0)
 of 2009-02-06 on cardew
Windowing system distributor `The X.Org Foundation', version 11.0.70200000
Important settings:
  value of $LC_ALL: nil
  value of $LC_COLLATE: nil
  value of $LC_CTYPE: nil
  value of $LC_MESSAGES: nil
  value of $LC_MONETARY: nil
  value of $LC_NUMERIC: nil
  value of $LC_TIME: nil
  value of $LANG: en_GB.UTF-8
  value of $XMODIFIERS: @im=local
  locale-coding-system: utf-8-unix
  default-enable-multibyte-characters: t

Major mode: C/l

Minor modes in effect:
  shell-dirtrack-mode: t
  auto-image-file-mode: t
  show-paren-mode: t
  display-time-mode: t
  tooltip-mode: t
  mouse-wheel-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  global-auto-composition-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  line-number-mode: t
  transient-mark-mode: t
  abbrev-mode: t

Recent input:
C-v C-v <down-mouse-1> <mouse-movement> <mouse-1> C-x 
4 a N e w SPC f u n c t i o n , SPC d e p l o y e d 
SPC a s SPC w e l l <down-mouse-1> <mouse-movement> 
<drag-mouse-1> C-s l o c k C-s C-a <help-echo> <down-mouse-1> 
<mouse-1> SPC a l l SPC o v e r SPC t h i s SPC f i 
l e C-x C-s <help-echo> <down-mouse-1> <mouse-movement> 
<mouse-1> M-v M-v M-v M-v M-v M-v M-v M-v M-v C-v <escape> 
< C-v C-v C-v C-v C-v C-v C-v C-v C-v C-v C-v C-v <escape> 
< C-s l l o c k C-a <right> <right> <right> <right> 
<left> <right> <down> <down> C-x 2 C-x b <return> C-x 
C-f <backspace> <backspace> <backspace> <backspace> 
H / c s <tab> o <tab> . h <return> C-s C-s <down> <up> 
<left> <left> <left> <left> <left> <left> <left> <left> 
<left> <left> <left> <left> <left> <left> <left> <left> 
<left> <left> <left> <left> * <right> <down> <tab> 
C-x C-s <help-echo> <down-mouse-1> <mouse-1> <down> 
<down> <down> <left> <left> <left> <left> <left> <left> 
<left> <left> <left> <left> <left> N U L L M-d M-d 
C-x C-s <help-echo> <down-mouse-1> <mouse-1> C-x C-f 
H / c s <tab> o <tab> C <tab> <return> C-s l o c k 
C-s C-s C-s C-s C-s C-s C-s C-s C-s C-s C-s C-s C-s 
C-s C-s C-s C-a C-x 4 a A d d e d SPC <down-mouse-1> 
<mouse-movement> <mouse-movement> <drag-mouse-1> <help-echo> 
<help-echo> <down-mouse-2> <mouse-2> SPC t o SPC A 
P I C-x C-s C-x k <return> C-x k <return> C-x k <return> 
C-x 1 n SPC d n d SPC a g e <tab> n <tab> e a l o g 
y <return> SPC M-m C-x k <return> M-x r e p o r t <tab> 
<return>

Recent messages:
Saving file /home/jpff/Sourceforge/csound5/H/csound.h...
Wrote /home/jpff/Sourceforge/csound5/H/csound.h
Wrote /home/jpff/Sourceforge/csound5/OOps/bus.c
Making completion list...
Mark saved where search started
Mark set
Saving file /home/jpff/Sourceforge/csound5/ChangeLog...
Wrote /home/jpff/Sourceforge/csound5/ChangeLog
call-interactively: End of buffer
Auto save file for draft message exists; consider M-x mail-recover

==John ffitch

bug#2222: 23.0.90; Labels in RMAIL

[Glenn Morris]

severity 2222 wishlist
retitle 2222 completion of labels in rmail

jpff wrote:

> Labels in Rmail no longer provide completion as they did.

They do complete over any labels added within the course of a session,
and the standard "unseen" etc.

I have just added completion over the labels seen in the current
message (cumulative over the course of a session).

Still missing is completion over all labels defined for a given
folder. That could be done by scanning all the X-RMAIL-KEYWORDS
headers, but it might be slow. Leaving this open as a wishlist.

bug#2222: 23.0.90; Labels in RMAIL

[Richard M Stallman]

    Still missing is completion over all labels defined for a given
    folder. That could be done by scanning all the X-RMAIL-KEYWORDS
    headers, but it might be slow.

That's why I did not implement it.  In Babyl format, the list was
stored in the beginning of the file, so this completion could be fast.
I don't see any reliable way to do that with mbox files.

How about adding a user-customizable list of labels
to include in each completion?

Meanwhile, I think there is no particular reason to us an obarray
to hold the labels that have been seen.  If we store it as a list,
reading a keyword could merge all the lists (attributes, keywords seen,
and the keywords specified by the user) each time.  They are not likely
to be very long lists.

bug#2222: 23.0.90; Labels in RMAIL

[Glenn Morris]

Richard M Stallman wrote:

>     Still missing is completion over all labels defined for a given
>     folder. That could be done by scanning all the X-RMAIL-KEYWORDS
>     headers, but it might be slow.
>
> That's why I did not implement it.  In Babyl format, the list was
> stored in the beginning of the file, so this completion could be fast.
> I don't see any reliable way to do that with mbox files.

Creating a summary reads the necessary information anyway. I've now
made it so that all labels are available for completion after the
summary has been generated.

So I'd say this is done, except for the no-summary case.