Date header rewrite

Date header rewrite

[Lars Ingebrigtsen]

As I hinted earlier, I've now totally rewritten the way date headers are
customised.  You can now have as many Date headers as you like.

I've removed a slew of date customisation variables, but it should still
respect the legacy variables.  (Sort of.)

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

Re: Date header rewrite

[Francis Moreau]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> As I hinted earlier, I've now totally rewritten the way date headers are
> customised.  You can now have as many Date headers as you like.
>
> I've removed a slew of date customisation variables, but it should still
> respect the legacy variables.  (Sort of.)

Would be nice if you could a least give the revelant commits.

Thanks
-- 
Francis

Re: Date header rewrite

[Rupert Swarbrick]

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

Francis Moreau <francis.moro@gmail.com> writes:
> Lars Ingebrigtsen <larsi@gnus.org> writes:
>
>> As I hinted earlier, I've now totally rewritten the way date headers are
>> customised.  You can now have as many Date headers as you like.
>>
>> I've removed a slew of date customisation variables, but it should still
>> respect the legacy variables.  (Sort of.)
>
> Would be nice if you could a least give the revelant commits.
>
> Thanks

Or just look at the git log. I presume it's

commit 5b81b4b7b447c64f3c09bad8541b3dfa71c392d1
Author: Lars Magne Ingebrigtsen <larsi@gnus.org>
Date:   Sun Jan 30 17:55:08 2011 -0800

    Rewrite the Date header formatting functionality.
    
    The user can now have infinitely many Date headers.
    
    This change should be pretty much backwards-compatible, even though
    many customisation variables have been removed.


Rupert


P.S. No, the user can't have infinitely many Date headers. Arbitrarily
many, maybe. Infinitely many would require a message of infinite
length. Grr.

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

Re: Date header rewrite

[Robert Pluim]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> As I hinted earlier, I've now totally rewritten the way date headers are
> customised.  You can now have as many Date headers as you like.
>
> I've removed a slew of date customisation variables, but it should still
> respect the legacy variables.  (Sort of.)

I had (gnus-treat-date-local 'head), which now seems to be ignored, I
had to do (setq gnus-article-date-headers '(local)) to get it back.

Just for fun, I tried:

(setq gnus-article-date-headers '(local lapsed))

which caused my CPU to overheat, and everything in a summary buffer to
become ridiculously slow. Using just combined-lapsed didn't have those
issues (but that shows the original Date header, <sigh>). This is on
XEmacs 21.5 (beta29) "garbanzo" 7ea837399734+ [Lucid] (i686-pc-cygwin,
Mule)

Regards

Robert

Re: Date header rewrite

[Lars Ingebrigtsen]

Robert Pluim <rpluim@gmail.com> writes:

> I had (gnus-treat-date-local 'head), which now seems to be ignored, I
> had to do (setq gnus-article-date-headers '(local)) to get it back.

`gnus-article-date-headers' is set from -date-local, etc, and if I try
setting it, I get the expected result.

Are you setting gnus-treat-date-local after loading gnus-art, by any
chance? 

> Just for fun, I tried:
>
> (setq gnus-article-date-headers '(local lapsed))
>
> which caused my CPU to overheat, and everything in a summary buffer to
> become ridiculously slow.

Should be fixed now.

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

Re: Date header rewrite

[Robert Pluim]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> Robert Pluim <rpluim@gmail.com> writes:
>
>> I had (gnus-treat-date-local 'head), which now seems to be ignored, I
>> had to do (setq gnus-article-date-headers '(local)) to get it back.
>
> `gnus-article-date-headers' is set from -date-local, etc, and if I try
> setting it, I get the expected result.
>
> Are you setting gnus-treat-date-local after loading gnus-art, by any
> chance? 

So this turned out to be because I'd set gnus-treat-date-local using
customize, which means this:

    (dolist (type types)
      (let ((variable (intern (format "gnus-treat-date-%s" type))))
	(when (and (boundp variable)
		   (symbol-value variable))

fails when doing the boundp test. Setting it with setq in .gnus.el makes
things work fine.

Whether customize should create variable bindings for variables that
don't exist is a question I'm not going to think about early on a Monday
morning :)

>> Just for fun, I tried:
>>
>> (setq gnus-article-date-headers '(local lapsed))
>>
>> which caused my CPU to overheat, and everything in a summary buffer to
>> become ridiculously slow.
>
> Should be fixed now.

Confirmed.

Robert

Re: Date header rewrite

[Lars Ingebrigtsen]

Robert Pluim <rpluim@gmail.com> writes:

> Whether customize should create variable bindings for variables that
> don't exist is a question I'm not going to think about early on a Monday
> morning :)

It's later now.  (In some regions.)  :-)

Yeah, I had no idea that customize didn't define the variables unless
already existing.

So...

There are three options here that I can see:

1) Rip out all the -treat-date-* compat stuff and just let people deal
with the new variable.  It's nice, because then you don't any
confusion.  Just annoyed people.

2) Redefine all the -treat-date-* variables again, but only use the for
the defaults.  This is confusing, but would probably work slightly
better for more people.

3) Make the new variable totally "dynamic".  That is, if it isn't set
explicitly by the user, then use all the -treat-date-* variables
instead at article rendering time.  This is totally confusing, but would
probably annoy the least people right now.

I'm leaning towards 1).

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

Re: Date header rewrite

[Robert Pluim]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> Robert Pluim <rpluim@gmail.com> writes:
>
>> Whether customize should create variable bindings for variables that
>> don't exist is a question I'm not going to think about early on a Monday
>> morning :)
>
> It's later now.  (In some regions.)  :-)
>
> Yeah, I had no idea that customize didn't define the variables unless
> already existing.
>
> So...
>
> There are three options here that I can see:
>
> 1) Rip out all the -treat-date-* compat stuff and just let people deal
> with the new variable.  It's nice, because then you don't any
> confusion.  Just annoyed people.

I don't mind this option. It's not like having the date header display
differently from expected prevents important stuff from working. [1]

> 2) Redefine all the -treat-date-* variables again, but only use the for
> the defaults.  This is confusing, but would probably work slightly
> better for more people.
>
> 3) Make the new variable totally "dynamic".  That is, if it isn't set
> explicitly by the user, then use all the -treat-date-* variables
> instead at article rendering time.  This is totally confusing, but would
> probably annoy the least people right now.
>

Please don't do this. I'm too easily confused as it is.

> I'm leaning towards 1).

Go for it.

Robert

Footnotes: 
[1]  Famous last words, I'm sure

Re: Date header rewrite

[Eric S Fraga]

Lars Ingebrigtsen <larsi@gnus.org> writes:

[...]

>
> There are three options here that I can see:
>
> 1) Rip out all the -treat-date-* compat stuff and just let people deal
> with the new variable.  It's nice, because then you don't any
> confusion.  Just annoyed people.

go for this option!
annoyance is temporary;
confusion (for me) seems to be eternal,
especially wrt gnus ;-)

-- 
: Eric S Fraga (GnuPG: 0xC89193D8FFFCF67D) in Emacs 24.0.50.1 + No Gnus v0.11

Re: Date header rewrite

[Lars Ingebrigtsen]

Eric S Fraga <e.fraga@ucl.ac.uk> writes:

>> 1) Rip out all the -treat-date-* compat stuff and just let people deal
>> with the new variable.  It's nice, because then you don't any
>> confusion.  Just annoyed people.
>
> go for this option!

I've now done this.

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

Re: Date header rewrite

[Greg Troxel]

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


  As I hinted earlier, I've now totally rewritten the way date headers are
  customised.  You can now have as many Date headers as you like.

This isn't clearly a bug, but I think it is.  In the "ago"  display,
seconds are omitted if 0.  This results in something like

Date: Sun, 30 Jan 2011 17:56:53 -0800 (11 hours, 49 minutes, 59 seconds ago)
Date: Sun, 30 Jan 2011 17:56:53 -0800 (11 hours, 50 minutes ago)
Date: Sun, 30 Jan 2011 17:56:53 -0800 (11 hours, 50 minutes, 1 second ago)

I find the seconds coming and going to be distracting.   Plus I wonder
if the minutes would go away as well when 0.


I have no problem omitting leading hours/days/minutes as zero, and
omitting seconds because there is a day, etc.   I am only objecting to
suppressing fields because they are zero.



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

Re: Date header rewrite

[Lars Ingebrigtsen]

Greg Troxel <gdt@work.lexort.com> writes:

> This isn't clearly a bug, but I think it is.  In the "ago"  display,
> seconds are omitted if 0. 

All segments that are of zero size are omitted.  It's a feature.

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

Re: Date header rewrite

[Richard Riley]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> Greg Troxel <gdt@work.lexort.com> writes:
>
>> This isn't clearly a bug, but I think it is.  In the "ago"  display,
>> seconds are omitted if 0. 
>
> All segments that are of zero size are omitted.  It's a feature.

Whats the official way to disable this ticking time feature? I did have 

'(gnus-article-update-lapsed-header nil)
 
but that doesnt work now.

cheers,

r.

Re: Date header rewrite

[Lars Ingebrigtsen]

Richard Riley <rileyrg@googlemail.com> writes:

> Whats the official way to disable this ticking time feature? I did have 
>
> '(gnus-article-update-lapsed-header nil)
>
> but that doesnt work now.

The information you're looking for is cleverly hidden in the "Article
Date" section in the Gnus manual.

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

Re: Date header rewrite

[Richard Riley]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> Richard Riley <rileyrg@googlemail.com> writes:
>
>> Whats the official way to disable this ticking time feature? I did have 
>>
>> '(gnus-article-update-lapsed-header nil)
>>
>> but that doesnt work now.
>
> The information you're looking for is cleverly hidden in the "Article
> Date" section in the Gnus manual.

So it is. Now. Thanks.

gnus-article-update-date-headers is a variable defined in `gnus-art.el'.

Re: Date header rewrite

[Lars Ingebrigtsen]

Richard Riley <rileyrg@googlemail.com> writes:

> So it is. Now. 

The manual was updated in the same checkin as the code.

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

Re: Date header rewrite

[Richard Riley]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> Richard Riley <rileyrg@googlemail.com> writes:
>
>> So it is. Now. 
>
> The manual was updated in the same checkin as the code.

Yes, and thanks for pointing it out. Previously the way was the variable
I quoted. It can be hard to second guess a variable rename. One could,
of course, re-read the manual with each pull .. ;)

Re: Date header rewrite

[Lars Ingebrigtsen]

Richard Riley <rileyrg@googlemail.com> writes:

> Yes, and thanks for pointing it out. Previously the way was the variable
> I quoted. It can be hard to second guess a variable rename. One could,
> of course, re-read the manual with each pull .. ;)

You mean you don't?!?

We can do a deal.  If you promise to read the entire manual for every
commit, I promise to document variables/functionality that I plan on
introducing in the source code one week ahead of time.

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

Re: Date header rewrite

[Richard Riley]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> Richard Riley <rileyrg@googlemail.com> writes:
>
>> Yes, and thanks for pointing it out. Previously the way was the variable
>> I quoted. It can be hard to second guess a variable rename. One could,
>> of course, re-read the manual with each pull .. ;)
>
> You mean you don't?!?
>
> We can do a deal.  If you promise to read the entire manual for every
> commit, I promise to document variables/functionality that I plan on
> introducing in the source code one week ahead of time.

It's a deal. Who knows, with that agreement my spam processing might
even start working as I finally notice the correct spam variable or
quoting method that's currently making it a non starter. Which reminds me
.. I need to retest the  issue with emails being reprocessed.

Re: Date header rewrite

[Philipp Haselwarter]

Greg Troxel <gdt@work.lexort.com> writes:

>   As I hinted earlier, I've now totally rewritten the way date headers are
>   customised.  You can now have as many Date headers as you like.
>
> This isn't clearly a bug, but I think it is.  In the "ago"  display,
> seconds are omitted if 0.  This results in something like
>
> Date: Sun, 30 Jan 2011 17:56:53 -0800 (11 hours, 49 minutes, 59 seconds ago)
> Date: Sun, 30 Jan 2011 17:56:53 -0800 (11 hours, 50 minutes ago)
> Date: Sun, 30 Jan 2011 17:56:53 -0800 (11 hours, 50 minutes, 1 second ago)
>
> I find the seconds coming and going to be distracting.   Plus I wonder
> if the minutes would go away as well when 0.
>
>
> I have no problem omitting leading hours/days/minutes as zero, and
> omitting seconds because there is a day, etc.   I am only objecting to
> suppressing fields because they are zero.
>

+1
I'd also prefer if the seconds/the least relevant portion didn't
disappear when it's zero; a counter is fine with me, but the changing
length of the date string is somewhat distracting.

Oh and what happened to months (between weeks and years)?

-- 
Philipp Haselwarter

Re: Date header rewrite

[Michael Welsh Duggan]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> As I hinted earlier, I've now totally rewritten the way date headers are
> customised.  You can now have as many Date headers as you like.
>
> I've removed a slew of date customisation variables, but it should still
> respect the legacy variables.  (Sort of.)

I really like the new combined-lapsed.  The max-segments for the lapsed
part is hard-coded at 3 currently.  I find that 2 is preferable for me,
by far.  I can obviously change the hard-coded value (and have in my own
branch), but maybe this should be customizable?  Just an opinion.

-- 
Michael Welsh Duggan
(md5i@md5i.com)

Re: Date header rewrite

[Lars Ingebrigtsen]

Michael Welsh Duggan <md5i@md5i.com> writes:

> I really like the new combined-lapsed.  The max-segments for the lapsed
> part is hard-coded at 3 currently.  I find that 2 is preferable for me,
> by far.  I can obviously change the hard-coded value (and have in my own
> branch), but maybe this should be customizable?  Just an opinion.

I'm not sure what the defaults should be.  I mean, most people seem to
dislike the seconds, so those might possibly go.  But it's been
necessary to have them switched on to be able to debug the various "why
is the cursor moving around when stuff updates?" bugs.

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

Re: Date header rewrite

[James Cloos]

>>>>> "LI" == Lars Ingebrigtsen <larsi@gnus.org> writes:

LI> I'm not sure what the defaults should be.  I mean, most people seem
LI> to dislike the seconds, so those might possibly go.

As long as it is static, I don't understand the aversion to seconds.

But the dynamic updates are unwelcome.

My second gnus runs the emacs trunk code; on that one I found that I
like the combined lapsed format.  But only /static/!

-JimC
-- 
James Cloos <cloos@jhcloos.com>         OpenPGP: 1024D/ED7DAEA6

Re: Date header rewrite

[Francis Moreau]

James Cloos <cloos@jhcloos.com> writes:

[...]

> My second gnus runs the emacs trunk code; on that one I found that I
> like the combined lapsed format.  But only /static/!

I think a lot (most) of people agree with that.

I would really like to understand why Lars wants to make it dynamic...

If the reason is: Gnus is the only one to do that, then it should be
taken as a big hint.
-- 
Francis

Re: Date header rewrite

[Greg Troxel]

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


Lars Ingebrigtsen <larsi@gnus.org> writes:

> I'm not sure what the defaults should be.  I mean, most people seem to
> dislike the seconds, so those might possibly go.  But it's been
> necessary to have them switched on to be able to debug the various "why
> is the cursor moving around when stuff updates?" bugs.

I generally am a liking-seconds type; I have them displayed on the clock
on various taskbars.  But that's about the current time, once, where I
asked for it, and I don't find any value in knowing whether someone
wrote a message, for example, 11 hours, 24 minutes, and 17 seconds ago
vs just 11 hours and 24 minutes ago.

Also, I know you said that omiting values with 0 was in your opinion a
feature, but after mulling it over I now feel very strongly that it's a
bug. Leaving it out has two problems:
  * The user can't disambiguate between
     "17 minutes, 0 seconds", and
     "17 minutes" (rounded)
  * frequently, and for brief periods (1 min, 1s), the display blinks
    in a visually distracting manner as ", 59 seconds" disappears and is
    replaced by ", 1 second".

I realize these two opinions are preference, so it makes sense to
defcustom them.   Then we could see how most people feel.

So I propose:

  variable to say how many date/time components to show.  Currently this
  is 3, but I would default to 2.

  variable to suppress other than MSD when zero.  currently this is t,
  but I would argue the default should be nil.

  perhaps: minimum time component to ever show.  could be seconds to get
  current behavior, or minutes to let one have 3 components but drop to
  1 or 2 for recent mail.

I think that with the above, most people will find the default display
of the Date line to be reasonable.

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

Re: Date header rewrite

[Lars Ingebrigtsen]

Greg Troxel <gdt@work.lexort.com> writes:

> So I propose:
>
>   variable to say how many date/time components to show.  Currently this
>   is 3, but I would default to 2.
>
>   variable to suppress other than MSD when zero.  currently this is t,
>   but I would argue the default should be nil.

I think this is way, way more customisation than what a frivolous
feature like this warrants.

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

Re: Date header rewrite

[Greg Troxel]

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


Lars Ingebrigtsen <larsi@gnus.org> writes:

> Greg Troxel <gdt@work.lexort.com> writes:
>
>> So I propose:
>>
>>   variable to say how many date/time components to show.  Currently this
>>   is 3, but I would default to 2.
>>
>>   variable to suppress other than MSD when zero.  currently this is t,
>>   but I would argue the default should be nil.
>
> I think this is way, way more customisation than what a frivolous
> feature like this warrants.

The problem is that the hard-coded defaults you chose are viewed as too
flashy by many.  So if you don't suppress zero MSD, and change to 2
components then probably there wouldn't be critical mass in wanting it
more complicated.


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

Re: Date header rewrite

[Francis Moreau]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> As I hinted earlier, I've now totally rewritten the way date headers are
> customised.  You can now have as many Date headers as you like.
>
> I've removed a slew of date customisation variables, but it should still
> respect the legacy variables.  (Sort of.)

With latest git as of this writing (head is at
dd811978420ac00e1e71c00b9291aa667950afbf)


This doing this doesn't work:

(setq gnus-article-date-headers 'combined-elapsed)
(setq gnus-article-update-date-headers nil)

=> article-make-date-line: Unknown conversion type: combined-elapsed


Also this doesn't:

(setq gnus-article-date-headers 'lapsed)
(setq gnus-article-update-date-headers nil)

=> the seconds are still updated...

-- 
Francis

Re: Date header rewrite

[Robert Pluim]

Francis Moreau <francis.moro@gmail.com> writes:

> Lars Ingebrigtsen <larsi@gnus.org> writes:
>
>> As I hinted earlier, I've now totally rewritten the way date headers are
>> customised.  You can now have as many Date headers as you like.
>>
>> I've removed a slew of date customisation variables, but it should still
>> respect the legacy variables.  (Sort of.)
>
> With latest git as of this writing (head is at
> dd811978420ac00e1e71c00b9291aa667950afbf)
>
>
> This doing this doesn't work:
>
> (setq gnus-article-date-headers 'combined-elapsed)
> (setq gnus-article-update-date-headers nil)
>
> => article-make-date-line: Unknown conversion type: combined-elapsed
 
It's 'combined-lapsed' (no e)

> Also this doesn't:
>
> (setq gnus-article-date-headers 'lapsed)
> (setq gnus-article-update-date-headers nil)
>
> => the seconds are still updated...

Yes, I see the same thing. I'm waiting for Lars to fix it.

Robert

Re: Date header rewrite

[Francis Moreau]

Robert Pluim <rpluim@gmail.com> writes:

> Francis Moreau <francis.moro@gmail.com> writes:
>
>> Lars Ingebrigtsen <larsi@gnus.org> writes:
>>
>>> As I hinted earlier, I've now totally rewritten the way date headers are
>>> customised.  You can now have as many Date headers as you like.
>>>
>>> I've removed a slew of date customisation variables, but it should still
>>> respect the legacy variables.  (Sort of.)
>>
>> With latest git as of this writing (head is at
>> dd811978420ac00e1e71c00b9291aa667950afbf)
>>
>>
>> This doing this doesn't work:
>>
>> (setq gnus-article-date-headers 'combined-elapsed)
>> (setq gnus-article-update-date-headers nil)
>>
>> => article-make-date-line: Unknown conversion type: combined-elapsed
>  
> It's 'combined-lapsed' (no e)
>

That's not what I'm seeing in the doc and changing it still fails:

=> article-make-date-line: Unknown conversion type: combine-lapsed

Thanks
-- 
Francis

Re: Date header rewrite

[Tassilo Horn]

Francis Moreau <francis.moro@gmail.com> writes:

Hi Francis,

>>> (setq gnus-article-date-headers 'combined-elapsed)
>>> (setq gnus-article-update-date-headers nil)
>>>
>>> => article-make-date-line: Unknown conversion type: combined-elapsed
>>  
>> It's 'combined-lapsed' (no e)
>
> That's not what I'm seeing in the doc

,----[ (info "(gnus)Customizing Articles") ]
| `gnus-treat-date (head)'
|      This will transform/add date headers according to the
|      `gnus-article-date-headers' variable.  This is a list of Date
|      headers to display.  The formats available are:
| 
|      [...]
|
|     `combined-elapsed'
|           Both the original date header and a (shortened) elapsed time.
`----

Indeed, it seems the docs are wrong.

> and changing it still fails:
>
> => article-make-date-line: Unknown conversion type: combine-lapsed

Now you've missed the d in combine_d_. ;-)

Bye,
Tassilo
-- 
Sent from my Emacs

Re: Date header rewrite

[Francis Moreau]

Tassilo Horn <tassilo@member.fsf.org> writes:

> Francis Moreau <francis.moro@gmail.com> writes:
>
> Hi Francis,
>
>>>> (setq gnus-article-date-headers 'combined-elapsed)
>>>> (setq gnus-article-update-date-headers nil)
>>>>
>>>> => article-make-date-line: Unknown conversion type: combined-elapsed
>>>  
>>> It's 'combined-lapsed' (no e)
>>
>> That's not what I'm seeing in the doc
>
> ,----[ (info "(gnus)Customizing Articles") ]
> | `gnus-treat-date (head)'
> |      This will transform/add date headers according to the
> |      `gnus-article-date-headers' variable.  This is a list of Date
> |      headers to display.  The formats available are:
> | 
> |      [...]
> |
> |     `combined-elapsed'
> |           Both the original date header and a (shortened) elapsed time.
> `----
>
> Indeed, it seems the docs are wrong.
>
>> and changing it still fails:
>>
>> => article-make-date-line: Unknown conversion type: combine-lapsed
>
> Now you've missed the d in combine_d_. ;-)

:)

Thanks.
-- 
Francis

Re: Date header rewrite

[Lars Ingebrigtsen]

Tassilo Horn <tassilo@member.fsf.org> writes:

> Indeed, it seems the docs are wrong.

Fixed and pushed.

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

Re: Date header rewrite

[Lars Ingebrigtsen]

Francis Moreau <francis.moro@gmail.com> writes:

>> It's 'combined-lapsed' (no e)
>
> That's not what I'm seeing in the doc and changing it still fails:
>
> => article-make-date-line: Unknown conversion type: combine-lapsed

It's `combined-lapsed' (you missed the d).

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

Re: Date header rewrite

[Francis Moreau]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> Francis Moreau <francis.moro@gmail.com> writes:
>
>>> It's 'combined-lapsed' (no e)
>>
>> That's not what I'm seeing in the doc and changing it still fails:
>>
>> => article-make-date-line: Unknown conversion type: combine-lapsed
>
> It's `combined-lapsed' (you missed the d).

Ok thanks
-- 
Francis

Re: Date header rewrite

[Robert Pluim]

Francis Moreau <francis.moro@gmail.com> writes:

> Robert Pluim <rpluim@gmail.com> writes:
>
>> Francis Moreau <francis.moro@gmail.com> writes:
>>
>>> Lars Ingebrigtsen <larsi@gnus.org> writes:
>>>
>>>> As I hinted earlier, I've now totally rewritten the way date headers are
>>>> customised.  You can now have as many Date headers as you like.
>>>>
>>>> I've removed a slew of date customisation variables, but it should still
>>>> respect the legacy variables.  (Sort of.)
>>>
>>> With latest git as of this writing (head is at
>>> dd811978420ac00e1e71c00b9291aa667950afbf)
>>>
>>>
>>> This doing this doesn't work:
>>>
>>> (setq gnus-article-date-headers 'combined-elapsed)
>>> (setq gnus-article-update-date-headers nil)
>>>
>>> => article-make-date-line: Unknown conversion type: combined-elapsed
>>  
>> It's 'combined-lapsed' (no e)
>>
>
> That's not what I'm seeing in the doc and changing it still fails:
>
> => article-make-date-line: Unknown conversion type: combine-lapsed

You've dropped the 'd' this time :)

Looks like the info docs are wrong. Doc in the code say:

    `gnus-article-date-headers' is a variable declared in Lisp.
      -- loaded from "gnus-art"
    
    Value: (local lapsed)
    
    Documentation:
    A list of Date header formats to display.
    Valid formats are `ut' (universal time), `local' (local time
    zone), `english' (readable English), `lapsed' (elapsed time),
    `combined-lapsed' (both the original date and the elapsed time),
    `original' (the original date header), `iso8601' (ISO8601
    format), and `user-defined' (a user-defined format defined by the
    `gnus-article-time-format' variable).
    
    You have as many date headers as you want in the article buffer.
    Some of these headers are updated automatically.  See
    `gnus-article-update-date-headers' for details.


Robert

Re: Date header rewrite

[Lars Ingebrigtsen]

Robert Pluim <rpluim@gmail.com> writes:

>> (setq gnus-article-update-date-headers nil)
>>
>> => the seconds are still updated...
>
> Yes, I see the same thing. I'm waiting for Lars to fix it.

If you put the setq in your .gnus.el and restart Gnus, does it work? 

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

Re: Date header rewrite

[Robert Pluim]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> Robert Pluim <rpluim@gmail.com> writes:
>
>>> (setq gnus-article-update-date-headers nil)
>>>
>>> => the seconds are still updated...
>>
>> Yes, I see the same thing. I'm waiting for Lars to fix it.
>
> If you put the setq in your .gnus.el and restart Gnus, does it work? 

No, it only takes effect if I restart emacs.

Robert

Re: Date header rewrite

[Lars Ingebrigtsen]

Robert Pluim <rpluim@gmail.com> writes:

>>>> (setq gnus-article-update-date-headers nil)

[...]

> No, it only takes effect if I restart emacs.

Hm.  Well, I guess Gnus could just stop the timer if that variable is
nil.  Fixed now.

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