message.el user References control

[jidanni]

In message.el, the user should be given some variables in case he
wishes to have some control over the wads of References, and their
order.

<   "Trim REFERENCES to be 21 Message-ID long or less, and fold them.
---
>   "Trim REFERENCES to be jidanni:1 Message-ID long or less, and fold them.
<   (let ((maxcount 21)
---
>   (let ((maxcount 1);jidanni
<       (setq refs (nreverse refs)
---
>       (setq ;refs (nreverse refs);jidanni off

Here I just keep one Reference, the last, which, though small, will
maintain chains, where as hardwired "first 21", will break them!


_______________________________________________
emacs-pretest-bug mailing list
emacs-pretest-bug@...
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug

[Stefan Monnier]

> In message.el, the user should be given some variables in case he
> wishes to have some control over the wads of References, and their
> order.

IIRC, the order is fixed by the relevant RFC, so we can't really let the
user mess it up.

As for making 21 customizable, well.... it seems like a good value, what
with it being half of 42 and just old enough to drink: why would you want to
change it?


        Stefan


_______________________________________________
emacs-pretest-bug mailing list
emacs-pretest-bug@...
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug

[jidanni]

S> IIRC, the order is fixed by the relevant RFC, so we can't really let the
S> user mess it up.

We demand shoot-feet control. Actually here we are smarter than the
RFC. RFC? bah! KFChicken.

S> As for making 21 customizable, well.... it seems like a good value, what
S> with it being half of 42 and just old enough to drink: why would you want to
S> change it?

Imagine me, spartan header environmental enthusiast, spewing out mails
with an ever growing pile of References, as if I was not in control of
my computer. The next thing you know I would be plastering on some
HTML too, or signatures, or GPG, or "Get Yahoo!" against my will. One
Reference is enough. Would go leave home with some beehive hairdo of
headers?


_______________________________________________
emacs-pretest-bug mailing list
emacs-pretest-bug@...
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug

[Stefan Monnier]

S> IIRC, the order is fixed by the relevant RFC, so we can't really let the
S> user mess it up.

> We demand shoot-feet control. Actually here we are smarter than the
> RFC. RFC? bah! KFChicken.

Since you use a length of 1, I'm wondering why you'd care about
the ordering.
Or are you saying that when the 21 limit is reached it incorrectly keeps the
oldest 21 rather than the most recent 21?  That would indeed be a plain bug.

> One Reference is enough.  Would go leave home with some beehive hairdo
> of headers?

While 21 references is probably always overkill, 1 is not always enough,
because of the unreliability of the NNTP protocol as well as other effects
(e.g. when not all messages in a thread are sent to the same participants).


        Stefan


_______________________________________________
emacs-pretest-bug mailing list
emacs-pretest-bug@...
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug

[jidanni]

> oldest 21 rather than the most recent 21?  That would indeed be a plain bug.

But that is what Lars said the RFC said the last time I brought this
up. Which you can see somewhere in news://news.gnus.org/gnus.gnus-bug
which is what http://gnus.org/resources.html says is the only way to
see gnus bug reports.

Better add a nil/t defvar so the user can override the order just in
case Lars wasn't joking.

> While 21 references is probably always overkill, 1 is not always enough,

OK, make you a deal: 20, or OK, 25, anything, as long as you have a
defvar so the user can override it -- allow him as big a beehive
hairdo of references as he wants. Make 0 mean no references at all.

I mean hardwiring any number without a defvar alternative should raise
a red flag anyway.

Anyway, thanks for your persistence in this matter. Farther than I got
last time just posting to bugs@....


_______________________________________________
emacs-pretest-bug mailing list
emacs-pretest-bug@...
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug

[Miles Bader-2]

On 7/26/07, jidanni@... <jidanni@...> wrote:
> I mean hardwiring any number without a defvar alternative should raise
> a red flag anyway.

Good point.

> Anyway, thanks for your persistence in this matter. Farther than I got
> last time just posting to bugs@....

I'm not sure that anyone actually reads bugs@... -- every bug
report I send there seems to be entirely ignored...

-miles
--
Do not taunt Happy Fun Ball.


_______________________________________________
emacs-pretest-bug mailing list
emacs-pretest-bug@...
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug

[Reiner Steib]

On Wed, Aug 01 2007, Miles Bader wrote:

> I'm not sure that anyone actually reads bugs@... -- every bug
> report I send there seems to be entirely ignored...

Within all articles in gnus.gnus-bug, I only found 2 unanswered
messages from you (8 years ago).  But it's true that there was quite a
long time when the group was full of spam (before Lars set up some
simple filter).  Nowaday the reports usually are answered, I think.

I wouldn't mind if the bug-report address would be changed to
ding@gnus (so that the reports are archived on Gname), but Lars
doesn't want this because of the user settings included in the
auto-generated reports.  If I reply, I often Cc ding@gnus.

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


_______________________________________________
emacs-pretest-bug mailing list
emacs-pretest-bug@...
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug

[Reiner Steib]

On Thu, Jul 26 2007, jidanni@... wrote:

>> Or are you saying that when the 21 limit is reached it incorrectly keeps the
>> oldest 21 rather than the most recent 21?  

Neither one is the case.  See below.

>> That would indeed be a plain bug.

> But that is what Lars said the RFC said the last time I brought this
> up. Which you can see somewhere in news://news.gnus.org/gnus.gnus-bug
> which is what http://gnus.org/resources.html says is the only way to
> see gnus bug reports.

ELISP> (message-shorten-references
         'References
         "<0> <1> <2> <3> <4> <5> <6> <7> <8> <9> <10> \
     <11> <12> <13> <14> <15> <16> <17> <18> <19> <20> \
     <21> <22> <23> <24> <25> <26> <27> <28> <29> <30> \
     <31> <32> <33> <34> <35> <36> <37> <38> <39> <40>")
nil
ELISP> References: <0> <21> <22> <23> <24> <25> <26> <27> <28> <29> <30> \
<31> <32> <33> <34> <35> <36> <37> <38> <39> <40>

> Better add a nil/t defvar so the user can override the order just in
> case Lars wasn't joking.
>
>> While 21 references is probably always overkill, 1 is not always enough,

,----[ http://www.landfield.com/usefor/drafts/gnksa-useage.txt ]
|               Comparison of GNKSA and USEAGE
|               C. H. Lindsey
|        5 June 2004
|
| This document describes the differences between GNKSA
| <http://www.faqs.org/faqs/usenet/software/good-netkeeping-seal> and USEAGE
| <http://www.landfield.com/usefor/drafts/draft-ietf-usefor-useage-00.txt>,
| also with some references to USEFOR (draft-ietf-usefor-article-13.txt).
|
| [...]
|
| > The software MUST include at least three additional Message-IDs from
| > the original article's References header as well, if they are available.
| > Try to stay as close as possible to the spirit of "son-of-1036", which
| > states:
| >
| >         <<Followup agents SHOULD not shorten References  headers.   If
| >           it  is absolutely necessary to shorten the header, as a des-
| >           perate last resort, a followup agent MAY do this by deleting
| >           some  of  the  message IDs.  However, it MUST not delete the
| >           first message ID, the last three message IDs (including that
| >           of  the immediate precursor), or any message ID mentioned in
| >           the body of the followup.>>
|
| That requirement concerning Message-IDs in the body is no longer in
| USEFOR. It would be a pain to implement, and I doubt it ever was.
|
| >
| > However, it also says:
| >
| >         <<If  it  is  absolutely  necessary  for  an implementation to
| >           impose a limit on the length of header lines, body lines, or
| >           header  logical  lines,  that  limit  shall be at least 1000
| >           octets, including EOL representations.>>
|
| USEAGE has 20 rather then 3.
`----

20 + 1 = 21

> OK, make you a deal: 20, or OK, 25, anything, as long as you have a
> defvar so the user can override it -- allow him as big a beehive
> hairdo of references as he wants. Make 0 mean no references at all.
>
> I mean hardwiring any number without a defvar alternative should raise
> a red flag anyway.

Not if the hardwired number is recommended by the relevant standards.
I'm not convinced that we should have a defvar (or even a defconst for
this).

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


_______________________________________________
emacs-pretest-bug mailing list
emacs-pretest-bug@...
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug

[Stefan Monnier]

> Not if the hardwired number is recommended by the relevant standards.
> I'm not convinced that we should have a defvar (or even a defconst for
> this).

Agreed.  But it does deserve a comment justifying the value chosen.


        Stefan


_______________________________________________
emacs-pretest-bug mailing list
emacs-pretest-bug@...
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug