loaddefs and provide

[Glenn Morris-3]

Juanma Barranquero wrote:

> * calendar/calendar.el (cal-loaddefs):
> * calendar/diary-lib.el (diary-loaddefs):
> * calendar/holidays.el (hol-loaddefs):
> * eshell/esh-module.el (esh-groups):
> * mh/mh-e.el (mh-loaddefs): Load rather than require.

The removal of the provide statement from autoload-rubric was
undocumented (it's a separate issue from generated-autoload-feature).

If it was unintentional, I would prefer to put this back to how it was.

http://lists.gnu.org/archive/html/emacs-devel/2008-04/msg01449.html

[Stefan Monnier]

>> * calendar/calendar.el (cal-loaddefs):
>> * calendar/diary-lib.el (diary-loaddefs):
>> * calendar/holidays.el (hol-loaddefs):
>> * eshell/esh-module.el (esh-groups):
>> * mh/mh-e.el (mh-loaddefs): Load rather than require.

> The removal of the provide statement from autoload-rubric was
> undocumented (it's a separate issue from generated-autoload-feature).

> If it was unintentional, I would prefer to put this back to how it was.

I hesitated, but in the end, given the fact that we now use files whose
non-directory names may clash, I think that auto-generating feature
names from files is too risky and not worth the trouble (and
generated-autoload-feature is not a solution since it is not at the
right place, and actually there's no right place for it).


        Stefan

[Glenn Morris-3]

Stefan Monnier wrote:

> I hesitated, but in the end, given the fact that we now use files whose
> non-directory names may clash, I think that auto-generating feature
> names from files is too risky and not worth the trouble (and
> generated-autoload-feature is not a solution since it is not at the
> right place, and actually there's no right place for it).

OK, thanks for explaining.

Perhaps there could be an optional argument to provide a feature.
Otherwise cus-edit.el, custom.el, info-xref.el and possibly external
libraries need updating for cus-load and finder-inf no longer
providing features.

[Glenn Morris-3]

Glenn Morris wrote:

> Perhaps there could be an optional argument

(to autoload-rubric, I meant)

[Juanma Barranquero]

On Wed, Nov 4, 2009 at 04:12, Glenn Morris <rgm@...> wrote:

> The removal of the provide statement from autoload-rubric was
> undocumented (it's a separate issue from generated-autoload-feature).
>
> If it was unintentional, I would prefer to put this back to how it was.

I don't have an opinion about this issue, just fixed the bootstrapping.

    Juanma

[Chong Yidong]

Stefan Monnier <monnier@...> writes:

>>> * calendar/calendar.el (cal-loaddefs):
>>> * calendar/diary-lib.el (diary-loaddefs):
>>> * calendar/holidays.el (hol-loaddefs):
>>> * eshell/esh-module.el (esh-groups):
>>> * mh/mh-e.el (mh-loaddefs): Load rather than require.
>
>> The removal of the provide statement from autoload-rubric was
>> undocumented (it's a separate issue from generated-autoload-feature).
>
>> If it was unintentional, I would prefer to put this back to how it was.
>
> I hesitated, but in the end, given the fact that we now use files whose
> non-directory names may clash, I think that auto-generating feature
> names from files is too risky and not worth the trouble (and
> generated-autoload-feature is not a solution since it is not at the
> right place, and actually there's no right place for it).

This is unwise.  There are several third-party packages that depend on
the old behavior (i.e. having a provide statement in the generated
loaddefs file).  The third-party version of CEDET is one example.

This change causes too much incompatibility.  We should revert it, at
least for the 23.2 release.

[Stefan Monnier]

>> Perhaps there could be an optional argument
> (to autoload-rubric, I meant)

From where would it be provided?


        Stefan

[Glenn Morris-3]

Stefan Monnier wrote:

>>> Perhaps there could be an optional argument
>> (to autoload-rubric, I meant)
>
>From where would it be provided?

In custom-make-dependencies and finder-compile-keywords, if I
understand the question correctly.


--- autoload.el 3 Nov 2009 21:45:31 -0000 1.151
+++ autoload.el 4 Nov 2009 18:48:43 -0000
@@ -253,16 +253,20 @@
       (print-escape-nonascii t))
   (print form outbuf)))))))
 
-(defun autoload-rubric (file &optional type)
+(defun autoload-rubric (file &optional type feature)
   "Return a string giving the appropriate autoload rubric for FILE.
 TYPE (default \"autoloads\") is a string stating the type of
-information contained in FILE."
+information contained in FILE.  If FEATURE is non-nil, FILE
+will provide a feature based on FILE."
   (let ((basename (file-name-nondirectory file)))
     (concat ";;; " basename
     " --- automatically extracted " (or type "autoloads") "\n"
     ";;\n"
     ";;; Code:\n\n"
     "\n"
+    (if feature
+ (concat "(provide '" (file-name-sans-extension basename) ")\n")
+      "")
     ";; Local Variables:\n"
     ";; version-control: never\n"
     ";; no-byte-compile: t\n"


--- cus-dep.el 5 Jan 2009 03:18:49 -0000 1.46
+++ cus-dep.el 4 Nov 2009 18:49:05 -0000
@@ -87,7 +87,7 @@
   (setq buffer-undo-list t)
   (erase-buffer)
   (insert (autoload-rubric generated-custom-dependencies-file
-                           "custom dependencies"))
+                           "custom dependencies" t))
   (search-backward "")
   (mapatoms (lambda (symbol)
       (let ((members (get symbol 'custom-group))


--- finder.el 8 Mar 2009 19:54:32 -0000 1.82
+++ finder.el 4 Nov 2009 18:49:26 -0000
@@ -141,7 +141,7 @@
     (setq buffer-undo-list t)
     (erase-buffer)
     (insert (autoload-rubric generated-finder-keywords-file
-                             "keyword-to-package mapping"))
+                             "keyword-to-package mapping" t))
     (search-backward "")
     (insert "(setq finder-package-info '(\n")
     (let (processed summary keywords)

[Stefan Monnier]

> This is unwise.  There are several third-party packages that depend on
> the old behavior (i.e. having a provide statement in the generated
> loaddefs file).

These only work with Emacs-23.1, then, so there can't be that many.

> This change causes too much incompatibility.  We should revert it, at
> least for the 23.2 release.

If you want to revert it, go for it.  The main thing I really wanted to
remove was generated-autoload-feature (tho I also think that without
a way to tweak the provided feature, the `provide' should better not be
there),


        Stefan

[Stefan Monnier]

>>>> Perhaps there could be an optional argument
>>> (to autoload-rubric, I meant)
>> From where would it be provided?

> In custom-make-dependencies and finder-compile-keywords, if I
> understand the question correctly.

That would be fine, yes.

> -information contained in FILE."
> +information contained in FILE.  If FEATURE is non-nil, FILE
> +will provide a feature based on FILE."
>    (let ((basename (file-name-nondirectory file)))
>      (concat ";;; " basename
>      " --- automatically extracted " (or type "autoloads") "\n"
>      ";;\n"
>      ";;; Code:\n\n"
>      "\n"
> +    (if feature
> + (concat "(provide '" (file-name-sans-extension basename) ")\n")
> +      "")

Better make FEATURE be the symbol to provide, rather than auto-compute
it based on the file name.  That's more flexible.


        Stefan

[Glenn Morris-3]

Stefan Monnier wrote:

> If you want to revert it, go for it.  The main thing I really wanted to
> remove was generated-autoload-feature (tho I also think that without
> a way to tweak the provided feature, the `provide' should better not be
> there),

It was semi-reverted, and now I'm confused as to what the recommended
practice is here. Is the provision of a feature in an autoload file
considered obsolete and not to be used? (I do get the point of the
last quoted sentence above, I think.)

BTW, although it seems harmless, there are now 4 files in Emacs that
provide the 'loaddefs feature.

[Stefan Monnier]

> It was semi-reverted, and now I'm confused as to what the recommended
> practice is here. Is the provision of a feature in an autoload file
> considered obsolete and not to be used?

Yes.

> BTW, although it seems harmless, there are now 4 files in Emacs that
> provide the 'loaddefs feature.

Yes, it's not good.  I'd rather get rid of them.


        Stefan

[Chong Yidong]

Stefan Monnier <monnier@...> writes:

>> BTW, although it seems harmless, there are now 4 files in Emacs that
>> provide the 'loaddefs feature.
>
> Yes, it's not good.  I'd rather get rid of them.

As I said, this breaks third-party packages.