all those timers, they make my head swim ...

all those timers, they make my head swim ...

[Didier Verna]

        Hey Lars, I finally played with gnus-start-date-timers ...

What would be really neat is having BOTH the standard Date (in which you can
also see the jetlag which is usefull) and the X-Sent line.

        Anyway, I'm not going to fall on my knees this time ;-)

-- 
    /     /   _   _       Didier Verna        http://www.inf.enst.fr/~verna/
 - / / - / / /_/ /      E.N.S.T. INF C201.1      mailto:verna@inf.enst.fr
/_/ / /_/ / /__ /        46 rue Barrault        Tel.   (33) 01 45 81 73 46
                      75634 Paris  cedex 13     Fax.   (33) 01 45 81 31 19

Re: all those timers, they make my head swim ...

[Lars Magne Ingebrigtsen]

Didier Verna <verna@inf.enst.fr> writes:

>         Hey Lars, I finally played with gnus-start-date-timers ...
> 
> What would be really neat is having BOTH the standard Date (in which you can
> also see the jetlag which is usefull) and the X-Sent line.

Hm.  Well, I think the best way to do that would be to write an
article hook function to do that.

>         Anyway, I'm not going to fall on my knees this time ;-)

And, as you can see, you didn't get the desired results.  :-)

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

Re: all those timers, they make my head swim ...

[Didier Verna]

Lars Magne Ingebrigtsen <larsi@gnus.org> writes:

> Didier Verna <verna@inf.enst.fr> writes:

>> What would be really neat is having BOTH the standard Date (in which you
>> can also see the jetlag which is usefull) and the X-Sent line.

> Hm.  Well, I think the best way to do that would be to write an
> article hook function to do that.

        Currently, yes, but I think it should be doable in a simpler way. All
the other gnus-treat-date-* features do the same thing: they display the date
in a particular format. However, the gnus-treat-date-lapsed feature does more,
since it needs *your* current time to compute a difference with the original
date. Hence it provides an additional information. That's why I don't consider
it as just another way to display the date.

        So IMHO, it should be treated a bit differently and in particular, it
shouldn't necessarily remove the previous date header, but behave according to
the value of some user option. If you agree with this, I can provide a patch.


        Also, since all those gnus-treat-date-* variables can't work together
(they all remove the previous date header), why having different variables?
Wouldn't it be better to have only one with a set of possible values?


> >         Anyway, I'm not going to fall on my knees this time ;-)
> 
> And, as you can see, you didn't get the desired results.  :-)

        :-P

-- 
    /     /   _   _       Didier Verna        http://www.inf.enst.fr/~verna/
 - / / - / / /_/ /      E.N.S.T. INF C201.1      mailto:verna@inf.enst.fr
/_/ / /_/ / /__ /        46 rue Barrault        Tel.   (33) 01 45 81 73 46
                      75634 Paris  cedex 13     Fax.   (33) 01 45 81 31 19

Re: all those timers, they make my head swim ...

[Lars Magne Ingebrigtsen]

Didier Verna <verna@inf.enst.fr> writes:

> So IMHO, it should be treated a bit differently and in particular,
> it shouldn't necessarily remove the previous date header, but behave
> according to the value of some user option. If you agree with this,
> I can provide a patch.

I agree with this, and look forward to the patch.  :-)

>         Also, since all those gnus-treat-date-* variables can't work together
> (they all remove the previous date header), why having different variables?
> Wouldn't it be better to have only one with a set of possible values?

I want all the gnus-treat-* variables to have the same semantics.

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

Re: all those timers, they make my head swim ...

[Didier Verna]

Lars Magne Ingebrigtsen <larsi@gnus.org> writes:

>> Also, since all those gnus-treat-date-* variables can't work together (they
>> all remove the previous date header), why having different variables? 
>> Wouldn't it be better to have only one with a set of possible values?

> I want all the gnus-treat-* variables to have the same semantics.

        I'm not sure what you call `semantics' here, this doesn't make sense:
the user can set all the gnus-treat-date-* variables to t, but only one
will really work. Moreover, if several of them are set to t, you basically
don't know which one is going to win, appart from snarfing in the code. This
is confusing.

-- 
    /     /   _   _       Didier Verna        http://www.inf.enst.fr/~verna/
 - / / - / / /_/ /      E.N.S.T. INF C201.1      mailto:verna@inf.enst.fr
/_/ / /_/ / /__ /        46 rue Barrault        Tel.   (33) 01 45 81 73 46
                      75634 Paris  cedex 13     Fax.   (33) 01 45 81 31 19

Re: all those timers, they make my head swim ...

[Didier Verna]

Lars Magne Ingebrigtsen <larsi@gnus.org> writes:

> Didier Verna <verna@inf.enst.fr> writes:
>
> > So IMHO, it should be treated a bit differently and in particular,
> > it shouldn't necessarily remove the previous date header, but behave
> > according to the value of some user option. If you agree with this,
> > I can provide a patch.
>
> I agree with this, and look forward to the patch.  :-)


1999-04-18  Didier Verna  <verna@inf.enst.fr>

	* gnus-art.el (gnus-article-date-lapsed-new-header): new variable.
	(article-date-ut): use it.


1999-04-18  Didier Verna  <verna@inf.enst.fr>

	* gnus.texi (Article treatment): document the new variable
	`gnus-article-date-lapsed-new-header'.

--- lisp/gnus-art.el.orig	Sun Apr 18 17:27:41 1999
+++ lisp/gnus-art.el	Sun Apr 18 18:28:34 1999
@@ -754,6 +754,13 @@
   :group 'gnus-article-treat
   :type gnus-article-treat-head-custom)
 
+(defcustom gnus-article-date-lapsed-new-header t
+  "When using `gnus-treat-date-lapsed', the \"X-Sent:\" header will either
+replace the old \"Date:\" header (if this variable is nil), or be added below
+it (otherwise)."
+  :group 'gnus-article-headers
+  :type 'boolean)
+
 (defcustom gnus-treat-date-original nil
   "Display the date in the original timezone.
 Valid values are nil, t, `head', `last', an integer or a predicate.
@@ -1748,7 +1755,9 @@
 (defun article-date-ut (&optional type highlight header)
   "Convert DATE date to universal time in the current article.
 If TYPE is `local', convert to local time; if it is `lapsed', output
-how much time has lapsed since DATE."
+how much time has lapsed since DATE. For `lapsed', the value of
+`gnus-article-date-lapsed-new-header' says whether the \"X-Sent:\" header
+should replace the \"Date:\" one, or should be added below it."
   (interactive (list 'ut t))
   (let* ((header (or header
 		     (mail-header-date (save-excursion
@@ -1758,25 +1767,38 @@
 		     ""))
 	 (date (if (vectorp header) (mail-header-date header)
 		 header))
-	 (date-regexp "^Date:[ \t]\\|^X-Sent:[ \t]")
 	 (inhibit-point-motion-hooks t)
-	 bface eface newline)
+	 bface eface newline replace)
     (when (and date (not (string= date "")))
       (save-excursion
 	(save-restriction
 	  (article-narrow-to-head)
 	  (let ((buffer-read-only nil))
-	    ;; Delete any old Date headers.
-	    (if (re-search-forward date-regexp nil t)
-		(progn
-		  (setq bface (get-text-property (gnus-point-at-bol) 'face)
-			eface (get-text-property (1- (gnus-point-at-eol))
-						 'face))
-		  (delete-region (progn (beginning-of-line) (point))
-				 (progn (end-of-line) (point)))
-		  (beginning-of-line))
-	      (goto-char (point-max))
-	      (setq newline t))
+	    (if (or (eq type 'local)
+		    (not gnus-article-date-lapsed-new-header))
+		(if (re-search-forward  "^Date:[ \t]\\|^X-Sent:[ \t]" nil t)
+		    (setq replace t)
+		  (goto-char (point-max))
+		  (setq newline t))
+	      ;; else: lapsed and gnus-article-date-lapsed-new-header
+	      (if (re-search-forward  "^X-Sent:[ \t]" nil t)
+		  (setq replace t)
+		(if (re-search-forward  "^Date:[ \t]" nil t)
+		    (progn
+		      (setq bface (get-text-property (gnus-point-at-bol) 'face)
+			    eface (get-text-property (1- (gnus-point-at-eol))
+						     'face))
+		      (forward-line 1)
+		      (setq newline t))
+		  (goto-char (point-max))
+		  (setq newline t))))
+	    (when replace
+	      (setq bface (get-text-property (gnus-point-at-bol) 'face)
+		    eface (get-text-property (1- (gnus-point-at-eol))
+					     'face))
+	      (delete-region (progn (beginning-of-line) (point))
+			     (progn (end-of-line) (point)))
+	      (beginning-of-line))
 	    (insert (article-make-date-line date type))
 	    ;; Do highlighting.
 	    (beginning-of-line)

--- texi/gnus.texi.orig	Sun Apr 18 14:44:13 1999
+++ texi/gnus.texi	Sun Apr 18 18:36:50 1999
@@ -4757,7 +4757,7 @@
 @item / M
 @kindex / M (Summary)
 @findex gnus-summary-limit-exclude-marks
-Exclude all marked articles (@code{gnus-summary-limit-exclude-marks}). 
+Exclude all marked articles (@code{gnus-summary-limit-exclude-marks}).
 
 @item / T
 @kindex / T (Summary)
@@ -6927,9 +6927,13 @@
 (@code{gnus-article-date-lapsed}).  It looks something like:
 
 @example
-X-Sent: 29 years, 6 weeks, 4 days, 10 hours, 3 minutes, 28 seconds ago
+X-Sent: 9 years, 6 weeks, 4 days, 9 hours, 3 minutes, 28 seconds ago
 @end example
 
+The value of @code{gnus-article-date-lapsed-new-header} determines
+whether this header will just be added below the old Date one, or will
+replace it.
+
 An advantage of using Gnus to read mail is that it converts simple bugs
 into wonderful absurdities.
 
@@ -10181,7 +10185,7 @@
 
 @table @code
 @item :path
-The path of the directory where the mails are stored.  The default is 
+The path of the directory where the mails are stored.  The default is
 @samp{~/Maildir/new}.
 
 If you sometimes look at your mail through a pop3 daemon before fetching
@@ -10835,7 +10839,7 @@
 There are five different mail backends in the standard Gnus, and more
 backends are available separately.  The mail backend most people use
 (because it is the fastest and most flexible) is @code{nnml}
-(@pxref{Mail Spool}).  
+(@pxref{Mail Spool}).
 
 @menu
 * Unix Mail Box::               Using the (quite) standard Un*x mbox.
@@ -16589,7 +16593,7 @@
 Gnus is developed in a two-phased cycle.  The first phase involves much
 discussion on the @samp{ding@@gnus.org} mailing list, where people
 propose changes and new features, post patches and new backends.  This
-phase is called the @dfn{alpha} phase, since the Gnusae released in this 
+phase is called the @dfn{alpha} phase, since the Gnusae released in this
 phase are @dfn{alpha releases}, or (perhaps more commonly in other
 circles) @dfn{snapshots}.  During this phase, Gnus is assumed to be
 unstable and should not be used by casual users.  Gnus alpha releases
@@ -16610,13 +16614,13 @@
 
 The division of discussion between the ding mailing list and the Gnus
 newsgroup is not purely based on publicity concerns.  It's true that
-having people write about the horrible things that an alpha Gnus release 
+having people write about the horrible things that an alpha Gnus release
 can do (sometimes) in a public forum may scare people off, but more
 importantly, talking about new experimental features that have been
 introduced may confuse casual users.  New features are frequently
 introduced, fiddled with, and judged to be found wanting, and then
 either discarded or totally rewritten.  People reading the mailing list
-usually keep up with these rapid changes, whille people on the newsgroup 
+usually keep up with these rapid changes, whille people on the newsgroup
 can't be assumed to do so.
 
 


-- 
    /     /   _   _       Didier Verna        http://www.inf.enst.fr/~verna/
 - / / - / / /_/ /      E.N.S.T. INF C201.1      mailto:verna@inf.enst.fr
/_/ / /_/ / /__ /        46 rue Barrault        Tel.   (33) 01 45 81 73 46
                      75634 Paris  cedex 13     Fax.   (33) 01 45 81 31 19

Re: all those timers, they make my head swim ...

[Lars Magne Ingebrigtsen]

Didier Verna <verna@inf.enst.fr> writes:

>         I'm not sure what you call `semantics' here, this doesn't make sense:
> the user can set all the gnus-treat-date-* variables to t, but only one
> will really work. Moreover, if several of them are set to t, you basically
> don't know which one is going to win, appart from snarfing in the code. This
> is confusing.

The semantics of all the gnus-treat-* variables are the same -- set
the variable to t, and the function will be done.  There are, however,
"competing" variables.  For instance -- gnus-treat-highlight-signature
and gnus-treat-hide-signature.  Set the latter, and you want see the
results of setting the former.

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen