GNU bug report logs -
#2222
completion of labels in rmail
Previous Next
Reported by: jpff <jpff <at> codemist.co.uk>
Date: Fri, 6 Feb 2009 14:00:03 UTC
Severity: wishlist
Tags: wontfix
Done: Lars Ingebrigtsen <larsi <at> gnus.org>
Bug is archived. No further changes may be made.
To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 2222 in the body.
You can then email your comments to 2222 AT debbugs.gnu.org in the normal way.
Toggle the display of automated, internal messages from the tracker.
Report forwarded
to
bug-submit-list <at> lists.donarmstrong.com, Emacs Bugs <bug-gnu-emacs <at> gnu.org>
:
bug#2222
; Package
emacs
.
(Fri, 06 Feb 2009 14:00:03 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
jpff <jpff <at> codemist.co.uk>
:
New bug report received and forwarded. Copy sent to
Emacs Bugs <bug-gnu-emacs <at> gnu.org>
.
(Fri, 06 Feb 2009 14:00:03 GMT)
Full text and
rfc822 format available.
Message #5 received at submit <at> emacsbugs.donarmstrong.com (full text, mbox):
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 reassigned from package `emacs' to `emacs,rmail'.
Request was from
Glenn Morris <rgm <at> gnu.org>
to
control <at> emacsbugs.donarmstrong.com
.
(Fri, 06 Feb 2009 17:40:04 GMT)
Full text and
rfc822 format available.
Information forwarded
to
bug-submit-list <at> lists.donarmstrong.com, Emacs Bugs <bug-gnu-emacs <at> gnu.org>, Rmail Maintainers <bug-gnu-emacs <at> gnu.org>
:
bug#2222
; Package
emacs,rmail
.
(Wed, 11 Feb 2009 04:10:04 GMT)
Full text and
rfc822 format available.
Message #10 received at 2222 <at> emacsbugs.donarmstrong.com (full text, mbox):
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.
Severity set to `wishlist' from `normal'
Request was from
Glenn Morris <rgm <at> gnu.org>
to
control <at> emacsbugs.donarmstrong.com
.
(Wed, 11 Feb 2009 04:10:05 GMT)
Full text and
rfc822 format available.
Changed bug title to `completion of labels in rmail' from `23.0.90; Labels in RMAIL'.
Request was from
Glenn Morris <rgm <at> gnu.org>
to
control <at> emacsbugs.donarmstrong.com
.
(Wed, 11 Feb 2009 04:10:06 GMT)
Full text and
rfc822 format available.
Information forwarded
to
bug-submit-list <at> lists.donarmstrong.com, Emacs Bugs <bug-gnu-emacs <at> gnu.org>, Rmail Maintainers <bug-gnu-emacs <at> gnu.org>
:
bug#2222
; Package
emacs,rmail
.
(Wed, 11 Feb 2009 21:10:03 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
rms <at> gnu.org
:
Extra info received and forwarded to list. Copy sent to
Emacs Bugs <bug-gnu-emacs <at> gnu.org>, Rmail Maintainers <bug-gnu-emacs <at> gnu.org>
.
(Wed, 11 Feb 2009 21:10:03 GMT)
Full text and
rfc822 format available.
Message #19 received at 2222 <at> emacsbugs.donarmstrong.com (full text, mbox):
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.
Information forwarded
to
bug-submit-list <at> lists.donarmstrong.com, Emacs Bugs <bug-gnu-emacs <at> gnu.org>, Rmail Maintainers <bug-gnu-emacs <at> gnu.org>
:
bug#2222
; Package
emacs,rmail
.
(Thu, 12 Feb 2009 03:40:03 GMT)
Full text and
rfc822 format available.
Message #22 received at 2222 <at> emacsbugs.donarmstrong.com (full text, mbox):
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.
Information forwarded
to
bug-submit-list <at> lists.donarmstrong.com, Emacs Bugs <bug-gnu-emacs <at> gnu.org>, Rmail Maintainers <bug-gnu-emacs <at> gnu.org>
:
bug#2222
; Package
emacs,rmail
.
(Thu, 12 Feb 2009 06:30:02 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
jpff <jpff <at> codemist.co.uk>
:
Extra info received and forwarded to list. Copy sent to
Emacs Bugs <bug-gnu-emacs <at> gnu.org>, Rmail Maintainers <bug-gnu-emacs <at> gnu.org>
.
(Thu, 12 Feb 2009 06:30:03 GMT)
Full text and
rfc822 format available.
Message #27 received at 2222 <at> emacsbugs.donarmstrong.com (full text, mbox):
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 <at> snout>
> Subject: DON'T DELETE THIS MESSAGE -- FOLDER INTERNAL DATA
> Message-ID: <1177607803 <at> 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
Information forwarded
to
bug-submit-list <at> lists.donarmstrong.com, Emacs Bugs <bug-gnu-emacs <at> gnu.org>, Rmail Maintainers <bug-gnu-emacs <at> gnu.org>
:
bug#2222
; Package
emacs,rmail
.
(Thu, 12 Feb 2009 23:35:03 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
Xavier Maillard <xma <at> gnu.org>
:
Extra info received and forwarded to list. Copy sent to
Emacs Bugs <bug-gnu-emacs <at> gnu.org>, Rmail Maintainers <bug-gnu-emacs <at> gnu.org>
.
(Thu, 12 Feb 2009 23:35:03 GMT)
Full text and
rfc822 format available.
Message #32 received at 2222 <at> emacsbugs.donarmstrong.com (full text, mbox):
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
Information forwarded
to
bug-submit-list <at> lists.donarmstrong.com, Emacs Bugs <bug-gnu-emacs <at> gnu.org>, Rmail Maintainers <bug-gnu-emacs <at> gnu.org>
:
bug#2222
; Package
emacs,rmail
.
(Fri, 13 Feb 2009 06:45:02 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
rms <at> gnu.org
:
Extra info received and forwarded to list. Copy sent to
Emacs Bugs <bug-gnu-emacs <at> gnu.org>, Rmail Maintainers <bug-gnu-emacs <at> gnu.org>
.
(Fri, 13 Feb 2009 06:45:03 GMT)
Full text and
rfc822 format available.
Message #37 received at 2222 <at> emacsbugs.donarmstrong.com (full text, mbox):
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?
Information forwarded
to
bug-submit-list <at> lists.donarmstrong.com, Emacs Bugs <bug-gnu-emacs <at> gnu.org>, Rmail Maintainers <bug-gnu-emacs <at> gnu.org>
:
bug#2222
; Package
emacs,rmail
.
(Sat, 14 Feb 2009 21:30:02 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
Xavier Maillard <xma <at> gnu.org>
:
Extra info received and forwarded to list. Copy sent to
Emacs Bugs <bug-gnu-emacs <at> gnu.org>, Rmail Maintainers <bug-gnu-emacs <at> gnu.org>
.
(Sat, 14 Feb 2009 21:30:02 GMT)
Full text and
rfc822 format available.
Message #42 received at 2222 <at> emacsbugs.donarmstrong.com (full text, mbox):
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
Information forwarded
to
bug-submit-list <at> lists.donarmstrong.com, Emacs Bugs <bug-gnu-emacs <at> gnu.org>, Rmail Maintainers <bug-gnu-emacs <at> gnu.org>
:
bug#2222
; Package
emacs,rmail
.
(Mon, 16 Feb 2009 15:50:02 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
rms <at> gnu.org
:
Extra info received and forwarded to list. Copy sent to
Emacs Bugs <bug-gnu-emacs <at> gnu.org>, Rmail Maintainers <bug-gnu-emacs <at> gnu.org>
.
(Mon, 16 Feb 2009 15:50:02 GMT)
Full text and
rfc822 format available.
Message #47 received at 2222 <at> emacsbugs.donarmstrong.com (full text, mbox):
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.
Information forwarded
to
bug-submit-list <at> lists.donarmstrong.com, Emacs Bugs <bug-gnu-emacs <at> gnu.org>, Rmail Maintainers <bug-gnu-emacs <at> gnu.org>
:
bug#2222
; Package
emacs,rmail
.
(Mon, 16 Feb 2009 19:45:04 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
Stefan Monnier <monnier <at> iro.umontreal.ca>
:
Extra info received and forwarded to list. Copy sent to
Emacs Bugs <bug-gnu-emacs <at> gnu.org>, Rmail Maintainers <bug-gnu-emacs <at> gnu.org>
.
(Mon, 16 Feb 2009 19:45:04 GMT)
Full text and
rfc822 format available.
Message #52 received at 2222 <at> emacsbugs.donarmstrong.com (full text, mbox):
> 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
Information forwarded
to
bug-submit-list <at> lists.donarmstrong.com, Emacs Bugs <bug-gnu-emacs <at> gnu.org>, Rmail Maintainers <bug-gnu-emacs <at> gnu.org>
:
bug#2222
; Package
emacs,rmail
.
(Tue, 17 Feb 2009 03:05:07 GMT)
Full text and
rfc822 format available.
Message #55 received at 2222 <at> emacsbugs.donarmstrong.com (full text, mbox):
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.
Information forwarded
to
bug-submit-list <at> lists.donarmstrong.com, Emacs Bugs <bug-gnu-emacs <at> gnu.org>, Rmail Maintainers <bug-gnu-emacs <at> gnu.org>
:
bug#2222
; Package
emacs,rmail
.
(Tue, 17 Feb 2009 12:25:04 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
rms <at> gnu.org
:
Extra info received and forwarded to list. Copy sent to
Emacs Bugs <bug-gnu-emacs <at> gnu.org>, Rmail Maintainers <bug-gnu-emacs <at> gnu.org>
.
(Tue, 17 Feb 2009 12:25:04 GMT)
Full text and
rfc822 format available.
Message #60 received at 2222 <at> emacsbugs.donarmstrong.com (full text, mbox):
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.
Information forwarded
to
bug-submit-list <at> lists.donarmstrong.com, Emacs Bugs <bug-gnu-emacs <at> gnu.org>, Rmail Maintainers <bug-gnu-emacs <at> gnu.org>
:
bug#2222
; Package
emacs,rmail
.
(Tue, 17 Feb 2009 18:15:04 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
rms <at> gnu.org
:
Extra info received and forwarded to list. Copy sent to
Emacs Bugs <bug-gnu-emacs <at> gnu.org>, Rmail Maintainers <bug-gnu-emacs <at> gnu.org>
.
(Tue, 17 Feb 2009 18:15:04 GMT)
Full text and
rfc822 format available.
Message #65 received at 2222 <at> emacsbugs.donarmstrong.com (full text, mbox):
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.
Information forwarded
to
bug-submit-list <at> lists.donarmstrong.com, Emacs Bugs <bug-gnu-emacs <at> gnu.org>, Rmail Maintainers <bug-gnu-emacs <at> gnu.org>
:
bug#2222
; Package
emacs,rmail
.
(Wed, 18 Feb 2009 00:00:10 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
Xavier Maillard <xma <at> gnu.org>
:
Extra info received and forwarded to list. Copy sent to
Emacs Bugs <bug-gnu-emacs <at> gnu.org>, Rmail Maintainers <bug-gnu-emacs <at> gnu.org>
.
(Wed, 18 Feb 2009 00:00:10 GMT)
Full text and
rfc822 format available.
Message #70 received at 2222 <at> emacsbugs.donarmstrong.com (full text, mbox):
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
Information forwarded
to
bug-submit-list <at> lists.donarmstrong.com, Emacs Bugs <bug-gnu-emacs <at> gnu.org>, Rmail Maintainers <bug-gnu-emacs <at> gnu.org>
:
bug#2222
; Package
emacs,rmail
.
(Wed, 18 Feb 2009 00:00:14 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
Xavier Maillard <xma <at> gnu.org>
:
Extra info received and forwarded to list. Copy sent to
Emacs Bugs <bug-gnu-emacs <at> gnu.org>, Rmail Maintainers <bug-gnu-emacs <at> gnu.org>
.
(Wed, 18 Feb 2009 00:00:15 GMT)
Full text and
rfc822 format available.
Message #75 received at 2222 <at> emacsbugs.donarmstrong.com (full text, mbox):
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
Information forwarded
to
bug-submit-list <at> lists.donarmstrong.com, Emacs Bugs <bug-gnu-emacs <at> gnu.org>, Rmail Maintainers <bug-gnu-emacs <at> gnu.org>
:
bug#2222
; Package
emacs,rmail
.
(Wed, 18 Feb 2009 03:10:04 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
Stefan Monnier <monnier <at> iro.umontreal.ca>
:
Extra info received and forwarded to list. Copy sent to
Emacs Bugs <bug-gnu-emacs <at> gnu.org>, Rmail Maintainers <bug-gnu-emacs <at> gnu.org>
.
(Wed, 18 Feb 2009 03:10:04 GMT)
Full text and
rfc822 format available.
Message #80 received at 2222 <at> emacsbugs.donarmstrong.com (full text, mbox):
> 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
Information forwarded
to
bug-submit-list <at> lists.donarmstrong.com, Emacs Bugs <bug-gnu-emacs <at> gnu.org>, Rmail Maintainers <bug-gnu-emacs <at> gnu.org>
:
bug#2222
; Package
emacs,rmail
.
(Thu, 19 Feb 2009 00:25:05 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
Xavier Maillard <xma <at> gnu.org>
:
Extra info received and forwarded to list. Copy sent to
Emacs Bugs <bug-gnu-emacs <at> gnu.org>, Rmail Maintainers <bug-gnu-emacs <at> gnu.org>
.
(Thu, 19 Feb 2009 00:25:05 GMT)
Full text and
rfc822 format available.
Message #85 received at 2222 <at> emacsbugs.donarmstrong.com (full text, mbox):
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
Added tag(s) wontfix.
Request was from
Glenn Morris <rgm <at> gnu.org>
to
control <at> debbugs.gnu.org
.
(Tue, 28 Feb 2017 07:34:02 GMT)
Full text and
rfc822 format available.
bug closed, send any further explanations to
2222 <at> debbugs.gnu.org and jpff <jpff <at> codemist.co.uk>
Request was from
Lars Ingebrigtsen <larsi <at> gnus.org>
to
control <at> debbugs.gnu.org
.
(Sun, 15 Apr 2018 22:10:03 GMT)
Full text and
rfc822 format available.
bug archived.
Request was from
Debbugs Internal Request <help-debbugs <at> gnu.org>
to
internal_control <at> debbugs.gnu.org
.
(Mon, 14 May 2018 11:24:04 GMT)
Full text and
rfc822 format available.
This bug report was last modified 7 years and 95 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.