Re: [Emacs-diffs] master 5d1e62e: When autoload-timestamps is nil, use a dummy timestamp rather than "t".

Re: [Emacs-diffs] master 5d1e62e: When autoload-timestamps is nil, use a dummy timestamp rather than "t".

[Stefan Monnier]

> +;; In some ways it would be nicer to use a value that is recognisably
> +;; not a time-value, eg t, but that can cause issues if an older Emacs
> +;; that does not expect non-time-values loads the file.

I can't think of any scenario where this would be a problem, other than
far-fetched ones.


        Stefan

Re: [Emacs-diffs] master 5d1e62e: When autoload-timestamps is nil, use a dummy timestamp rather than "t".

[Glenn Morris]

Stefan Monnier wrote:

>> +;; In some ways it would be nicer to use a value that is recognisably
>> +;; not a time-value, eg t, but that can cause issues if an older Emacs
>> +;; that does not expect non-time-values loads the file.
>
> I can't think of any scenario where this would be a problem, other than
> far-fetched ones.

No, it (generate a loaddefs file with Emacs > 25.1, then try to
incrementally update it with <= 25.1) isn't very likely.
(I vaguely wondered if it could happen with package.el?)

This was a probable over-reaction to
http://lists.gnu.org/archive/html/emacs-devel/2016-04/msg00654.html
and subsequent.

Frankly I'm not sure what my preference is any more.
Do you think it should go back to "t"?

Re: [Emacs-diffs] master 5d1e62e: When autoload-timestamps is nil, use a dummy timestamp rather than "t".

[Stefan Monnier]

> (I vaguely wondered if it could happen with package.el?)

No, package.el should only ever build new autoloads files from scratch
and never update them afterwards.  But I guess some future package.el
(or other package that extends package.el) could conceivably try to do
it, admittedly in a hypothetical case.


        Stefan