The followup will show the bug.

The followup will show the bug.

[Kai Großjohann]

kai
-- 
Silence is foo!

Re: The followup will show the bug.

[Reiner Steib]

Kai.Grossjohann@CS.Uni-Dortmund.DE (Kai writes:

| Subject: Re: The followup will show the bug.

> kai

I see it. ;-) Use `F' rather then `f' to show it.

Here's a hint for those who don't see it:
\f
<URL:http://groups.google.com/groups?
q=%22CS%2EUni%2DDortmund%2EDE+%28Kai+writes%22&as_qdr=m>

And one more detailed hint (in german):
\f
news:<v9adqpwo3x.fsf@marauder.physik.uni-ulm.de>

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

Re: The followup will show the bug.

[Kai Großjohann]

Reiner Steib <4uce.02.r.steib@gmx.net> writes:

> Kai.Grossjohann@CS.Uni-Dortmund.DE (Kai writes:
>
> | Subject: Re: The followup will show the bug.
>
>> kai
>
> I see it. ;-) Use `F' rather then `f' to show it.

Right.  Thanks, Reiner.  I really have no idea what's eating my last
name.  (A mutant of the NSA line eater?)

kai
-- 
Silence is foo!

Re: The followup will show the bug.

[Oystein Viggen]

* [Kai Großjohann] 

> Right.  Thanks, Reiner.  I really have no idea what's eating my last
> name.  (A mutant of the NSA line eater?)

Seems like a bug in the header unwrapping.

Your from header looks like this:
From: Kai.Grossjohann@CS.Uni-Dortmund.DE (Kai
 =?iso-8859-15?q?Gro=DFjohann?=)

I edited it to look like this instead:
From: Kai.Grossjohann@CS.Uni-Dortmund.DE (Kai =?iso-8859-15?q?Gro=DFjohann?=)

The results can be seen in the first line of my mail.

Oystein
-- 
Ebg13 arire tbrf bhg bs fglyr..

Re: The followup will show the bug.

[Christopher Splinter]

* Oystein Viggen <oysteivi@tihlde.org>:

> * [Kai Großjohann] 
>> Right.  Thanks, Reiner.  I really have no idea what's eating my last
>> name.  (A mutant of the NSA line eater?)
> Seems like a bug in the header unwrapping.
> 
> Your from header looks like this:
> From: Kai.Grossjohann@CS.Uni-Dortmund.DE (Kai
>  =?iso-8859-15?q?Gro=DFjohann?=)

Does it? To me it looks like this:

From: Kai.Grossjohann@CS.Uni-Dortmund.DE (Kai\
 =?iso-8859-15?q?Gro=DFjohann?=)

I wonder where the backslash comes from as it does not seem to be
there in the mailinglist archives ... do you think it might have
something to do with my settings?

Confused,
Chris

Re: The followup will show the bug.

[Kai Großjohann]

Christopher Splinter <chris@splinter.inka.de> writes:

> I wonder where the backslash comes from as it does not seem to be
> there in the mailinglist archives ... do you think it might have
> something to do with my settings?

I also have no idea where that backslash might come from.  Is it there
before Gnus sees the mail, or is it added after receives it?

kai
-- 
Silence is foo!

Re: The followup will show the bug.

[Oystein Viggen]

* [Kai.Grossjohann@CS.Uni-Dortmund.DE (Kai] 

> I also have no idea where that backslash might come from.  Is it there
> before Gnus sees the mail, or is it added after receives it?

I don't see any such backslash at all, but I believe the (hopefully)
well formed From: header in this mail should give some of the same
behaviour on followup.

(Oh, and it seems that this mail _will_ show up with a backslash in my
xemacs)

Oystein
-- 
When in doubt: Recompile.

Re: The followup will show the bug.

[Paul Jarc]

oysteivi@tihlde.org (Oystein\ wrote:
> I don't see any such backslash at all, but I believe the (hopefully)
> well formed From: header in this mail should give some of the same
> behaviour on followup.

You have a backslash too, and it's present before Gnus sees the
message.  So it seems to be an encoding problem rather than a decoding
problem.


paul

Re: The followup will show the bug.

[Christopher Splinter]

* Paul Jarc <prj@po.cwru.edu>:

> oysteivi@tihlde.org (Oystein\ wrote:
>> I don't see any such backslash at all, but I believe the
>> (hopefully) well formed From: header in this mail should give
>> some of the same behaviour on followup.
> You have a backslash too, and it's present before Gnus sees the
> message.  So it seems to be an encoding problem rather than a
> decoding problem.

But not all users seem to have this problem as Kai's headers seem
intact (to everybody but me).

Re: The followup will show the bug.

[Niklas Morberg]

This is probably unrelated, but BBDB keeps updating your
name every time I see a new message from you.

My *Messages* buffer tells me:

name mismatch: "Kai Großjohann" changed to "Kai Großjohann"

I don't get it and I certainly don't know what to do about
it...

Niklas

Re: he followup will show the bug.

[Marco Lonsing]

Niklas Morberg <niklas.morberg@axis.com> writes:

> This is probably unrelated, but BBDB keeps updating your
> name every time I see a new message from you.
>
> My *Messages* buffer tells me:
>
> name mismatch: "Kai Großjohann" changed to "Kai Großjohann"
>

I was additionally asked to choose a proper coding-system for bbdb's
database file.

Raymond Scholz suggested to use 

   (setq bbdb-file-coding-system 'emacs-mule)

This solved both problems for me. See thread "bbdb and searching"
on gnu.emacs.gnus

Marco

-- 
Marco Lonsing
Mathematik XI - Numerik	       email: Marco.Lonsing@ruhr-uni-bochum.de
Ruhr-Universitaet Bochum       phone: +49-234-32-23244
Universitaetsstr. 150	       fax  : +49-234-32-03244
D-44721 Bochum, GERMANY	       www  : http://www.ruhr-uni-bochum.de/num1/marco/

Re: The followup will show the bug.

[David Kågedal]

[-- Attachment #1: Type: text/plain, Size: 810 bytes --]

Niklas Morberg <niklas.morberg@axis.com> writes:

> This is probably unrelated, but BBDB keeps updating your
> name every time I see a new message from you.
> 
> My *Messages* buffer tells me:
> 
> name mismatch: "Kai Großjohann" changed to "Kai Großjohann"
> 
> I don't get it and I certainly don't know what to do about
> it...

I've been getting that too, and the problem seems to be that bbdb no
longer opens the bbdb file using the encoding I tell it to use.

This used to work, but after updating bbdb from cvs recently-ish, it
stopped working.  The .bbdb buffer had iso-2022-jp or something
similar when I checked it.

(modify-coding-system-alist 'file (regexp-quote (expand-file-name bbdb-file))
			      'iso-8859-1)

And now, message insists on splitting this message.  *sigh*

[-- Attachment #2: Type: text/plain, Size: 22 bytes --]


-- 
David Kågedal

Re: The followup will show the bug.

[David Kågedal]

[-- Attachment #1: Type: text/plain, Size: 810 bytes --]

Niklas Morberg <niklas.morberg@axis.com> writes:

> This is probably unrelated, but BBDB keeps updating your
> name every time I see a new message from you.
> 
> My *Messages* buffer tells me:
> 
> name mismatch: "Kai Großjohann" changed to "Kai Großjohann"
> 
> I don't get it and I certainly don't know what to do about
> it...

I've been getting that too, and the problem seems to be that bbdb no
longer opens the bbdb file using the encoding I tell it to use.

This used to work, but after updating bbdb from cvs recently-ish, it
stopped working.  The .bbdb buffer had iso-2022-jp or something
similar when I checked it.

(modify-coding-system-alist 'file (regexp-quote (expand-file-name bbdb-file))
			      'iso-8859-1)

And now, message insists on splitting this message.  *sigh*

[-- Attachment #2: Type: text/plain, Size: 22 bytes --]


-- 
David Kågedal

Re: The followup will show the bug.

[Kai Großjohann]

Niklas Morberg <niklas.morberg@axis.com> writes:

> This is probably unrelated, but BBDB keeps updating your
> name every time I see a new message from you.
>
> My *Messages* buffer tells me:
>
> name mismatch: "Kai Großjohann" changed to "Kai Großjohann"
>
> I don't get it and I certainly don't know what to do about
> it...

This is because I used to use Latin-1 and now I use Latin-9.  And
Emacs regards ß as two different characters, when coming from the two
charsets/encodings.

On Emacs, installing ucs-tables.el (get it from the current version
from savannah.gnu.org) helps.  On XEmacs, Latin-Unity is the package.
With these, the two ß characters are unified (regarded as the same).

kai
-- 
Silence is foo!

Re: The followup will show the bug.

[Niklas Morberg]

Kai.Grossjohann@CS.Uni-Dortmund.DE (Kai writes:

> On Emacs, installing ucs-tables.el (get it from the current
> version from savannah.gnu.org) helps.

I'll do this. I couldn't find it on savannah, but it was
included in the gnus/contrib dir.

Niklas

Re: The followup will show the bug.

[Ronan Waide]

On May 28, davidk@lysator.liu.se said:
> 
> This used to work, but after updating bbdb from cvs recently-ish, it
> stopped working.  The .bbdb buffer had iso-2022-jp or something
> similar when I checked it.

A recent patch added an explicit coding to the BBDB buffer. See the
variable bbdb-file-coding-system for more info.

Cheers,
Waider.
-- 
waider@waider.ie / Yes, it /is/ very personal of me.
"yeah, you're in no position to be talking. telling dirty limericks to
 a cat lady on the other side of the planet at half past two in the
 morning? really, now." - Meredith.

Re: The followup will show the bug.

[Alex Schroeder]

"David Kågedal" <davidk@lysator.liu.se> writes:

> Niklas Morberg <niklas.morberg@axis.com> writes:
>> 
>> name mismatch: "Kai Großjohann" changed to "Kai Großjohann"

> (modify-coding-system-alist 'file (regexp-quote (expand-file-name bbdb-file))
> 			      'iso-8859-1)

I think your .bbdb is encoded in latin-1, but Kai switched his name to
latin-15.  When saving, the latin-15 sz (the name for the beta like
glyph) is saved as latin-1, so next time when BBDB compares the
strings again, the message has the latin-15 variant, and your bbdb has
the latin-1 variant -- again!  The only solution is to save the bbdb
in something that keeps the correct encoding (not latin-1, emacs-mule,
for example).  Or automatically unify all latin encodings.  (Code by
Dave Love.)

Alex.
-- 
http://www.electronicintifada.net/diaries/index.html
http://www.us-israel.org/jsource/US-Israel/hr2506c.html

Re: The followup will show the bug.

[Christopher Splinter]

*  <Kai.Grossjohann@CS.Uni-Dortmund.DE (Kai >:

> I also have no idea where that backslash might come from.  Is
> it there before Gnus sees the mail, or is it added after
> receives it?

It's there before Gnus processes it.

Since Gnus doesn't add a backslash, I guess it would have to be
one of the mailservers involved in transportation.
That'd be a Bad Thing.

Re: The followup will show the bug.

[Jesper Harder]

[-- Attachment #1: Type: text/plain, Size: 263 bytes --]

Kai.Grossjohann@CS.Uni-Dortmund.DE (Kai Großjohann) writes:

> Right.  Thanks, Reiner.  I really have no idea what's eating my last
> name.

`nnheader-parse-head' is eating it, because it doesn't grok folded
headers.

I think this patch should fix it:


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: gnus-msg.el.diff --]
[-- Type: text/x-patch, Size: 373 bytes --]

--- /home/harder/gnus/lisp/gnus-msg.el	Sun May 26 02:18:51 2002
+++ gnus-msg.el	Mon May 27 19:33:50 2002
@@ -683,6 +683,7 @@
 	    (message-reply-headers
 	     ;; The headers are decoded.
 	     (with-current-buffer gnus-article-copy
+	       (nnheader-fold-continuation-lines)
 	       (nnheader-parse-head t))))
 	(message-yank-original)
 	(setq beg (or beg (mark t))))

[-- Attachment #3: Type: text/plain, Size: 110 bytes --]



(BTW, `nnheader-fold-continuation-lines' is a strange name -- it doesn't
fold lines, but _\bu_\bnfolds them).

Re: The followup will show the bug.

[Kai Großjohann]

Jesper Harder <harder@ifa.au.dk> writes:

> `nnheader-parse-head' is eating it, because it doesn't grok folded
> headers.
>
> I think this patch should fix it:

Very nice!  Committed.

kai
-- 
Silence is foo!

Re: The followup will show the bug.

[Kai Großjohann]

Jesper Harder <harder@ifa.au.dk> writes:

> I think this patch should fix it:

I think it doesn't.

See: it
 also folds lines that look like headers in the body.

You should wait for the followup to see this.

kai
-- 
Silence is foo!

Re: The followup will show the bug.

[Kai Großjohann]

Kai.Grossjohann@CS.Uni-Dortmund.DE (Kai Großjohann) writes:

> I think it doesn't.
>
> See: it also folds lines that look like headers in the body.
>
> You should wait for the followup to see this.

See how it removed the newline after "See: "?  No good.

kai
-- 
Silence is foo!

Re: The followup will show the bug.

[Jesper Harder]

[-- Attachment #1: Type: text/plain, Size: 411 bytes --]

Kai.Grossjohann@CS.Uni-Dortmund.DE (Kai Großjohann) writes:

> Kai.Grossjohann@CS.Uni-Dortmund.DE (Kai Großjohann) writes:
>
>> I think it doesn't.
>>
>> See: it also folds lines that look like headers in the body.
>>
>> You should wait for the followup to see this.
>
> See how it removed the newline after "See: "?  No good.

Ah, right.  We need to narrow to the headers before unfolding them:


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: gnus-msg.el.diff --]
[-- Type: text/x-patch, Size: 516 bytes --]

--- /home/harder/gnus/lisp/gnus-msg.el	Tue May 28 17:52:02 2002
+++ gnus-msg.el	Tue May 28 18:14:16 2002
@@ -683,8 +683,10 @@
 	    (message-reply-headers
 	     ;; The headers are decoded.
 	     (with-current-buffer gnus-article-copy
-	       (nnheader-fold-continuation-lines)
-	       (nnheader-parse-head t))))
+	       (save-restriction
+		 (nnheader-narrow-to-headers)
+		 (ietf-drums-unfold-fws)
+		 (nnheader-parse-head t)))))
 	(message-yank-original)
 	(setq beg (or beg (mark t))))
       (when articles

[-- Attachment #3: Type: text/plain, Size: 142 bytes --]



`nnheader-fold-continuation-lines' seems to work in a weird way when
narrowing is in effect, so I replaced it with `ietf-drums-unfold-fws'.

Re: The followup will show the bug.

[Kai Großjohann]

Jesper Harder <harder@ifa.au.dk> writes:

> Ah, right.  We need to narrow to the headers before unfolding them:

I have slightly different code.  It's not clear to me which is
better.  Does anyone have opinions?

      (let ((message-reply-buffer gnus-article-copy)
	    (message-reply-headers
	     ;; The headers are decoded.
	     (with-current-buffer gnus-article-copy
	       (save-excursion
		 (rfc2047-unfold-region (point-min)
					(progn
					  (search-forward "\n\n")
					  (point))))
	       (nnheader-parse-head t))))
	(message-yank-original)
	(setq beg (or beg (mark t))))

kai
-- 
Silence is foo!

Re: The followup will show the bug.

[Johann Gambolputty de von ausfern schplenden schlitter...von Hautkopft of Ulm]

Kai.Grossjohann@CS.Uni-Dortmund.DE (Kai Großjohann) writes:

> Jesper Harder <harder@ifa.au.dk> writes:
>
>> Ah, right.  We need to narrow to the headers before unfolding them:
>
> I have slightly different code.  It's not clear to me which is
> better.  Does anyone have opinions?
>
>       (let ((message-reply-buffer gnus-article-copy)
> 	    (message-reply-headers
> 	     ;; The headers are decoded.
> 	     (with-current-buffer gnus-article-copy
> 	       (save-excursion
> 		 (rfc2047-unfold-region (point-min)
> 					(progn
> 					  (search-forward "\n\n")
> 					  (point))))
> 	       (nnheader-parse-head t))))
> 	(message-yank-original)
> 	(setq beg (or beg (mark t))))

They're nearly equivalent.  Hmm, `rfc2047-unfold-region' doesn't unfold
long lines -- I don't know it that's desirable or not.  Try replying to
this message.

Re: The followup will show the bug.

[Jesper Harder]

harder@ifa.au.dk ("Johann Gambolputty de von ausfern schplenden schlitter...von Hautkopft of Ulm") writes:

> They're nearly equivalent.  Hmm, `rfc2047-unfold-region' doesn't unfold
> long lines -- I don't know it that's desirable or not.  Try replying to
> this message.

Ah, the mailing list software rewrites From headers, so the issue
didn't show up.  

But the point is that `rfc2047-unfold-region' doesn't unfold headers if
the result is longer than 76 chars:

	(if (and (looking-at "[ \t]")
		 (< (- (gnus-point-at-eol) bol) 76))

Re: The followup will show the bug.

[Kai Großjohann]

Jesper Harder <harder@ifa.au.dk> writes:

> But the point is that `rfc2047-unfold-region' doesn't unfold headers if
> the result is longer than 76 chars:
>  (if (and (looking-at "[ \t]") (< (- (gnus-point-at-eol) bol) 76))

Aha.  So I shall install your patch.  Hm.  Gotta back out mine,
first.  Just a sec...

kai
-- 
Silence is foo!

Re: The followup will show the bug.

[Kai Großjohann]

Kai.Grossjohann@cs.uni-dortmund.de (Kai Großjohann) writes:

> Aha.  So I shall install your patch.  Hm.  Gotta back out mine,
> first.  Just a sec...

Done.  Please holler if anything is wrong now.

kai
-- 
Silence is foo!

Re: The followup will show the bug.

[Kai Großjohann]

"Johann Gambolputty de von ausfern schplenden schlitter...von Hautkopft of Ulm" <harder@ifa.au.dk> writes:

> They're nearly equivalent.  Hmm, `rfc2047-unfold-region' doesn't unfold
> long lines -- I don't know it that's desirable or not.  Try replying to
> this message.

The first line in this message is long but otherwise okay, I think.  So?

kai
-- 
Silence is foo!

Re: The followup will show the bug.

[Christopher Splinter]

* Kai Großjohann <Kai.Grossjohann@CS.Uni-Dortmund.DE>:

>> I think this patch should fix it:
> 
> I think it doesn't.
> 
> See: it also folds lines that look like headers in the body.
> 
> You should wait for the followup to see this.

You're right.

I think it'd be necessary to alter
nnheader-fold-continuation-lines and possibly
nnheader-skeleton-replace as well in order to make Jesper's patch
work. Unfortunately, I can't do this right now.

Re: The followup will show the bug.

[Andreas Fuchs]

[-- Attachment #1: Type: text/plain, Size: 1021 bytes --]

On 2002-05-24, Kai Großjohann <Kai.Grossjohann@cs.uni-dortmund.de>
wrote:
> 
> kai

Strange, using my augmented trivial cite function, it works:

,----
| (defun anti-tc-simple-attribution ()
|   "Produce an attribution string, using the real name and the date
| of the message."
|   (let* ((date (sc-jk-normalize-date (cdr (assoc "date" tc-strings-list))))
| 	(today (sc-jk-normalize-date (current-time-string)))
| 	(email (assoc "email-addr" tc-strings-list))
|         (name (assoc "real-name" tc-strings-list))
| 	(person (concat (cdr (or name '(nil . ""))) " <"
| 			(cdr (or email '(nil . "unknown-user@unknownnet")))
| 			">")))
|     ;(message "found %s <%s>" name email)
|     (if (null date)
| 	(concat person " wrote:\n\n")
|       (concat (if (equal today date)
| 		  "Today"
| 		(concat "On " date))
| 	      ", " person " wrote:\n\n"))))
`----

I understand that this might be a bug in message itself. Hm.

Have fun,
-- 
Andreas Fuchs, <asf@acm.org>, asf@jabber.at, antifuchs

[-- Attachment #2: Type: application/pgp-signature, Size: 188 bytes --]

ISO date in attribution line (Was: Re: The followup will show the bug.)

[Svend Tollak Munkejord]

On Sat, 25 May 2002, Andreas Fuchs wrote:
> On 2002-05-24, Kai Großjohann <Kai.Grossjohann@cs.uni-dortmund.de>
> wrote:
...
> ,----
> | (defun anti-tc-simple-attribution ()
> |   "Produce an attribution string, using the real name and the date
> | of the message."
> |   (let* ((date (sc-jk-normalize-date (cdr (assoc "date" tc-strings-list))))
> | 	(today (sc-jk-normalize-date (current-time-string)))
> | 	(email (assoc "email-addr" tc-strings-list))
> |         (name (assoc "real-name" tc-strings-list))
> | 	(person (concat (cdr (or name '(nil . ""))) " <"
> | 			(cdr (or email '(nil . "unknown-user@unknownnet")))
> | 			">")))
> |     ;(message "found %s <%s>" name email)
> |     (if (null date)
> | 	(concat person " wrote:\n\n")
> |       (concat (if (equal today date)
> | 		  "Today"
> | 		(concat "On " date))
> | 	      ", " person " wrote:\n\n"))))
> `----

I use Trivial-cite, and would like to change the date in the attribution
line to ISO format, like the one you have. Is it sc-jk-normalize-date that
is the clue?  In that case, could you please give a hint as to how (or
where) it is defined?

Thanks,

-- 
Svend Tollak Munkejord 

Re: ISO date in attribution line

[Andreas Fuchs]

[-- Attachment #1: Type: text/plain, Size: 1181 bytes --]

Today, Svend Tollak Munkejord <stm@bacchus.pvv.org> wrote:
> On Sat, 25 May 2002, Andreas Fuchs wrote:
>> | (defun anti-tc-simple-attribution ()
[...]
> I use Trivial-cite, and would like to change the date in the
> attribution line to ISO format, like the one you have. Is it
> sc-jk-normalize-date that is the clue?  In that case, could you please
> give a hint as to how (or where) it is defined?

My mistake. I had thought that I had included that defun.

Here it is:
,----
| (defun sc-jk-normalize-date (date)
|   "Extract the date (day month year) from an RFC 822 message
| and write it as year-month-day (ISO 8601)"
|   (let ((date-list (cdr (cdr (cdr (parse-time-string date))))))
|     (let ((day (pop date-list)))
|       (let ((month (pop date-list)))
| 	(let ((year (car date-list)))
| 	  (and 
| 	   year month day 
| 	   (format "%d-%02d-%02d" year month day)))))))
`----

I got that one (and probably modified it pretty much) from a supercite
library written by Jens Klöcker <kloecker@springer.de> in 1999, posted
to this list (sc-jk-headers.el was the filename).

Have fun,
-- 
Andreas Fuchs, <asf@acm.org>, asf@jabber.at, antifuchs

[-- Attachment #2: Type: application/pgp-signature, Size: 188 bytes --]

Re: ISO date in attribution line

[Kai Großjohann]

Andreas Fuchs <asf@void.at> writes:

> ,----
> | (defun sc-jk-normalize-date (date)
> |   "Extract the date (day month year) from an RFC 822 message
> | and write it as year-month-day (ISO 8601)"
> |   (let ((date-list (cdr (cdr (cdr (parse-time-string date))))))
> |     (let ((day (pop date-list)))
> |       (let ((month (pop date-list)))
> | 	(let ((year (car date-list)))
> | 	  (and 
> | 	   year month day 
> | 	   (format "%d-%02d-%02d" year month day)))))))
> `----

I get the feeling that doing format-time-string on the result of
parse-time-string would be enough.  Anyone want to try this?

(defun sc-jk-normalize-date (date)
  "..."
  (let ((date (encode-time (parse-time-string date))))
    (format-time-string "..." date)))

kai
-- 
~/.signature is: umop 3p!sdn    (Frank Nobis)

Re: ISO date in attribution line

[lawrence mitchell]

Kai Grossjohann wrote:
> Andreas Fuchs <asf@void.at> writes:

>> ,----
>> | (defun sc-jk-normalize-date (date)
>> |   "Extract the date (day month year) from an RFC 822 message
>> | and write it as year-month-day (ISO 8601)"
>> |   (let ((date-list (cdr (cdr (cdr (parse-time-string date))))))
>> |     (let ((day (pop date-list)))
>> |       (let ((month (pop date-list)))
>> | 	(let ((year (car date-list)))
>> | 	  (and
>> | 	   year month day
>> | 	   (format "%d-%02d-%02d" year month day)))))))
>> `----

> I get the feeling that doing format-time-string on the result
> of parse-time-string would be enough.  Anyone want to try this?

> (defun sc-jk-normalize-date (date)
>   "..."
>   (let ((date (encode-time (parse-time-string date))))
>     (format-time-string "..." date)))

Elegant though it is, not quite, since encode-time doesn't like a
list, it wants each argument separetely, at least it does in 21.2
and 20.4, which is odd, since the doc-string claims that it's the
reverse of decode-time, which returns a list.  Hmm, I wonder if
this is a pseudo-bug.

Im any case, you can manage without quite as many let bindings as
Andreas used:
(defun sc-jk-normalize-date (date)
  (let ((date-list (cdddr (parse-time-string date)))
        day month year)
    (setq day (pop date-list)
          month (pop date-list)
          year (car date-list))
    (format "%d-%02d-%02d" year month day)))

However, I'm not sure if this isn't slower.

-- 
lawrence mitchell <0198183+ding@sms.ed.ac.uk>

Re: ISO date in attribution line

[Kai Großjohann]

lawrence mitchell <0198183+ding@sms.ed.ac.uk> writes:

>> (defun sc-jk-normalize-date (date)
>>   "..."
>>   (let ((date (encode-time (parse-time-string date))))
>>     (format-time-string "..." date)))
>
> Elegant though it is, not quite, since encode-time doesn't like a
> list, it wants each argument separetely, at least it does in 21.2
> and 20.4, which is odd, since the doc-string claims that it's the
> reverse of decode-time, which returns a list.

Ah, I missed that.

(apply 'encode-time (parse-time-string date)) should fix it.

kai
-- 
~/.signature is: umop 3p!sdn    (Frank Nobis)

Re: ISO date in attribution line

[Andreas Fuchs]

[-- Attachment #1: Type: text/plain, Size: 974 bytes --]

Today, Kai Großjohann <Kai.Grossjohann@cs.uni-dortmund.de> wrote:
> lawrence mitchell <0198183+ding@sms.ed.ac.uk> writes:
>> Elegant though it is, not quite, since encode-time doesn't like a
>> list, it wants each argument separetely, at least it does in 21.2
>> and 20.4, which is odd, since the doc-string claims that it's the
>> reverse of decode-time, which returns a list.
> 
> Ah, I missed that.
> 
> (apply 'encode-time (parse-time-string date)) should fix it.

Doesn't, sorry. encode-time complains because of non-integer values
(and inded, parse-time-string of the string passed from the TC function
yields nil values in its result list. that is because only the day,
month and year are contained in the string.

I would really like to use your solution. What do you think would be a
good aproach to fixing that? Add a parameter to tc.el's header alist,
or fix encode-time?

Thanks,
-- 
Andreas Fuchs, <asf@acm.org>, asf@jabber.at, antifuchs

[-- Attachment #2: Type: application/pgp-signature, Size: 188 bytes --]

Re: ISO date in attribution line

[Kai Großjohann]

Andreas Fuchs <asf@void.at> writes:

> Today, Kai Großjohann <Kai.Grossjohann@cs.uni-dortmund.de> wrote:
>> lawrence mitchell <0198183+ding@sms.ed.ac.uk> writes:
>>> Elegant though it is, not quite, since encode-time doesn't like a
>>> list, it wants each argument separetely, at least it does in 21.2
>>> and 20.4, which is odd, since the doc-string claims that it's the
>>> reverse of decode-time, which returns a list.
>> 
>> Ah, I missed that.
>> 
>> (apply 'encode-time (parse-time-string date)) should fix it.
>
> Doesn't, sorry. encode-time complains because of non-integer values
> (and inded, parse-time-string of the string passed from the TC function
> yields nil values in its result list. that is because only the day,
> month and year are contained in the string.

Ah, hm.  parse-time-string leaves nil values, right?  Hm.

I guess that one needs to call parse-time-string, extract the ymd
values from it, anyway.  Then it doesn't matter if one uses format on
those values directly, rather than calling encode-time with the three
values and a lot of zeros and then calling format-time-string on that.

Whee.  I wish it was easier to use format-time-string here.

kai
-- 
~/.signature is: umop 3p!sdn    (Frank Nobis)

Re: ISO date in attribution line

[Andreas Fuchs]

[-- Attachment #1: Type: text/plain, Size: 1239 bytes --]

Today, Kai Großjohann <Kai.Grossjohann@cs.uni-dortmund.de> wrote:
> I get the feeling that doing format-time-string on the result of
> parse-time-string would be enough.  Anyone want to try this?
> (defun sc-jk-normalize-date (date)
>   "..."
>   (let ((date (encode-time (parse-time-string date))))
>     (format-time-string "..." date)))

This would have to be written as "(apply 'encode-time (parse...", and
then it will fail (integerp nil) because of tc's slightly braindead date
format: "Sun, 9 Jun 2002". That's it, all seconds, minutes, etc removed
From the time string. Don't know why.

A slightly more readable version is this (but I guess the right thing
is to fix tc's date behaviour, which will be hard because I've seen
modules depend on it):
,----
| (defun sc-jk-normalize-date (date)
|   "Extract the date (day month year) from an RFC 822 message
|  and write it as year-month-day (ISO 8601)"
|   (let* ((date-list (cdr (cdr (cdr (parse-time-string date)))))
| 	 (day (pop date-list))
| 	 (month (pop date-list))
| 	 (year (car date-list)))
|     (and year month day 
|      (format "%d-%02d-%02d" year month day))))
`----

Have fun,
-- 
Andreas Fuchs, <asf@acm.org>, asf@jabber.at, antifuchs

[-- Attachment #2: Type: application/pgp-signature, Size: 188 bytes --]

Re: ISO date in attribution line

[Svend Tollak Munkejord]

Today, Andreas Fuchs <asf@void.at> wrote:
> Today, Svend Tollak Munkejord <stm@bacchus.pvv.org> wrote:
>> On Sat, 25 May 2002, Andreas Fuchs wrote:
>>> | (defun anti-tc-simple-attribution ()
> [...]
>> I use Trivial-cite, and would like to change the date in the
>> attribution line to ISO format, like the one you have. Is it
>> sc-jk-normalize-date that is the clue?  In that case, could you please
>> give a hint as to how (or where) it is defined?
> 
> My mistake. I had thought that I had included that defun.
> 
> Here it is:

[...]

That worked fine. Thanks!

-- 
Svend Tollak Munkejord