Reiner Steib <[EMAIL PROTECTED]> writes:
[...]
> I have committed the changes to Gnus v5-10 branch. If anyone want to
> handle the compiler differently, feel free to change it.
I'd prefer to handle it like in the patch below. If the function
message-make-date or nnimap-date-days-ago is called
Miles Bader <[EMAIL PROTECTED]> writes:
> On Apr 5, 2005 4:14 PM, Kim F. Storm <[EMAIL PROTECTED]> wrote:
>> >> Can't you move this closer to the definition of message-make-date?
>> >> It's only necessary to suppress compiler warnings for that function.
>> >
>> > I put it inside the defun.
>>
>>
On Apr 5, 2005 4:14 PM, Kim F. Storm <[EMAIL PROTECTED]> wrote:
> >> Can't you move this closer to the definition of message-make-date?
> >> It's only necessary to suppress compiler warnings for that function.
> >
> > I put it inside the defun.
>
> Doing that will slow down the function, so if tha
Reiner Steib <[EMAIL PROTECTED]> writes:
>> Can't you move this closer to the definition of message-make-date?
>> It's only necessary to suppress compiler warnings for that function.
>
> I put it inside the defun.
Doing that will slow down the function, so if that function is used
a lot, I think
>>> (eval-when-compile
>>> (require 'cl)
>>> (defvar parse-time-weekdays) ;; parse-time is required where necessary
>>> (defvar parse-time-months)
Why not (require 'parse-time) simply?
This way if parse-time is ever changed to remove parse-time-months, the
byte-compiler will correctly catch
On Mon, Apr 04 2005, Lute Kamstra wrote:
> Reiner Steib <[EMAIL PROTECTED]> writes:
>> --- message.el 30 Mar 2005 08:14:32 - 1.75
>> +++ message.el 4 Apr 2005 11:36:12 -
>> @@ -32,6 +32,8 @@
>>
>> (eval-when-compile
>>(require 'cl)
>> + (defvar parse-time-weekdays)
Reiner Steib <[EMAIL PROTECTED]> writes:
>> I removed (require 'parse-time) from time-date because it uses just
>> parse-time-string, which is autoloaded. Do I understand correctly my
>> change uncovered some bugs in nnimap.el, nnultimate.el and pop3.el? I
>> already noticed (and fixed) this for
Reiner Steib <[EMAIL PROTECTED]> writes:
>>> Wouldn't it be better to put (require 'parse-time) at the beginning of
>>> the file instead of inside `message-make-date'?
>>
>> message-make-date is the only function in message.el that uses
>> parse-time, so it's best to put the require there. If you
On Thu, Mar 31 2005, Lute Kamstra wrote:
> Reiner Steib <[EMAIL PROTECTED]> writes:
>> On Wed, Mar 30 2005, Katsumi Yamaoka wrote:
>>> There's no ChangeLog for the recent changes of time-date.el and
>>> I don't know who did it for what purpose,
[...]
>> ,[ lisp/ChangeLog ]
>> | 2005-03-23 Lu
On Mon, Apr 04 2005, Lute Kamstra wrote:
> Reiner Steib <[EMAIL PROTECTED]> writes:
>> Wouldn't it be better to put (require 'parse-time) at the beginning of
>> the file instead of inside `message-make-date'?
>
> message-make-date is the only function in message.el that uses
> parse-time, so it's
I gather from this message that time-date's home is actually Gnus'
CVS?
That may have been true in the past, but nowadays time-date.el is an
ordinary file of Emacs, maintained the same way as most Emacs files.
As far as we are concerned it is not a part of Gnus.
___
Lute Kamstra <[EMAIL PROTECTED]> writes:
> I gather from this message that time-date's home is actually Gnus'
> CVS? I wasn't aware of that.
It does seem to have been originally written by the Gnus authors, but
who knows where its "home" is these days; it exists in both CVS trees
anyway.
> In Em
Reiner Steib <[EMAIL PROTECTED]> writes:
> On Wed, Mar 30 2005, Katsumi Yamaoka wrote:
>
>> There's no ChangeLog for the recent changes of time-date.el and
>> I don't know who did it for what purpose,
>
> [ I'm adding emacs-devel. ]
> In Emacs, `time-date.el' is located in the calendar subdirecto
On Mar 31, 2005 8:27 PM, Reiner Steib <[EMAIL PROTECTED]> wrote:
> > There's no ChangeLog for the recent changes of time-date.el and
> > I don't know who did it for what purpose,
>
> [ I'm adding emacs-devel. ]
> In Emacs, `time-date.el' is located in the calendar subdirectory.
> Probably Miles' s
14 matches
Mail list logo
