* loaddefs and provide
[not found] <E1N5Tis-0002pY-NM@cvs.savannah.gnu.org>
@ 2009-11-04 3:12 ` Glenn Morris
2009-11-04 3:58 ` Stefan Monnier
2009-11-04 9:54 ` Juanma Barranquero
0 siblings, 2 replies; 13+ messages in thread
From: Glenn Morris @ 2009-11-04 3:12 UTC (permalink / raw)
To: Juanma Barranquero, Stefan Monnier; +Cc: emacs-devel
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
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: loaddefs and provide
2009-11-04 3:12 ` loaddefs and provide Glenn Morris
@ 2009-11-04 3:58 ` Stefan Monnier
2009-11-04 8:37 ` Glenn Morris
2009-11-04 17:10 ` Chong Yidong
2009-11-04 9:54 ` Juanma Barranquero
1 sibling, 2 replies; 13+ messages in thread
From: Stefan Monnier @ 2009-11-04 3:58 UTC (permalink / raw)
To: Glenn Morris; +Cc: Juanma Barranquero, emacs-devel
>> * 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
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: loaddefs and provide
2009-11-04 3:58 ` Stefan Monnier
@ 2009-11-04 8:37 ` Glenn Morris
2009-11-04 8:46 ` Glenn Morris
2009-11-04 17:10 ` Chong Yidong
1 sibling, 1 reply; 13+ messages in thread
From: Glenn Morris @ 2009-11-04 8:37 UTC (permalink / raw)
To: Stefan Monnier; +Cc: Juanma Barranquero, emacs-devel
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.
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: loaddefs and provide
2009-11-04 8:37 ` Glenn Morris
@ 2009-11-04 8:46 ` Glenn Morris
2009-11-04 18:36 ` Stefan Monnier
0 siblings, 1 reply; 13+ messages in thread
From: Glenn Morris @ 2009-11-04 8:46 UTC (permalink / raw)
To: Stefan Monnier; +Cc: Juanma Barranquero, emacs-devel
Glenn Morris wrote:
> Perhaps there could be an optional argument
(to autoload-rubric, I meant)
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: loaddefs and provide
2009-11-04 3:12 ` loaddefs and provide Glenn Morris
2009-11-04 3:58 ` Stefan Monnier
@ 2009-11-04 9:54 ` Juanma Barranquero
1 sibling, 0 replies; 13+ messages in thread
From: Juanma Barranquero @ 2009-11-04 9:54 UTC (permalink / raw)
To: Glenn Morris; +Cc: Stefan Monnier, emacs-devel
On Wed, Nov 4, 2009 at 04:12, Glenn Morris <rgm@gnu.org> 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
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: loaddefs and provide
2009-11-04 3:58 ` Stefan Monnier
2009-11-04 8:37 ` Glenn Morris
@ 2009-11-04 17:10 ` Chong Yidong
2009-11-04 20:45 ` Stefan Monnier
1 sibling, 1 reply; 13+ messages in thread
From: Chong Yidong @ 2009-11-04 17:10 UTC (permalink / raw)
To: Stefan Monnier; +Cc: emacs-devel, Juanma Barranquero
Stefan Monnier <monnier@iro.umontreal.ca> 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.
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: loaddefs and provide
2009-11-04 8:46 ` Glenn Morris
@ 2009-11-04 18:36 ` Stefan Monnier
2009-11-04 19:11 ` Glenn Morris
0 siblings, 1 reply; 13+ messages in thread
From: Stefan Monnier @ 2009-11-04 18:36 UTC (permalink / raw)
To: Glenn Morris; +Cc: Juanma Barranquero, emacs-devel
>> Perhaps there could be an optional argument
> (to autoload-rubric, I meant)
From where would it be provided?
Stefan
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: loaddefs and provide
2009-11-04 18:36 ` Stefan Monnier
@ 2009-11-04 19:11 ` Glenn Morris
2009-11-04 20:46 ` Stefan Monnier
0 siblings, 1 reply; 13+ messages in thread
From: Glenn Morris @ 2009-11-04 19:11 UTC (permalink / raw)
To: Stefan Monnier; +Cc: emacs-devel
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"
"\f\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 "\f")
(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 "\f")
(insert "(setq finder-package-info '(\n")
(let (processed summary keywords)
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: loaddefs and provide
2009-11-04 17:10 ` Chong Yidong
@ 2009-11-04 20:45 ` Stefan Monnier
2009-11-10 2:11 ` Glenn Morris
0 siblings, 1 reply; 13+ messages in thread
From: Stefan Monnier @ 2009-11-04 20:45 UTC (permalink / raw)
To: Chong Yidong; +Cc: emacs-devel, Juanma Barranquero
> 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
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: loaddefs and provide
2009-11-04 19:11 ` Glenn Morris
@ 2009-11-04 20:46 ` Stefan Monnier
0 siblings, 0 replies; 13+ messages in thread
From: Stefan Monnier @ 2009-11-04 20:46 UTC (permalink / raw)
To: Glenn Morris; +Cc: emacs-devel
>>>> 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"
> "\f\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
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: loaddefs and provide
2009-11-04 20:45 ` Stefan Monnier
@ 2009-11-10 2:11 ` Glenn Morris
2009-11-10 17:48 ` Stefan Monnier
0 siblings, 1 reply; 13+ messages in thread
From: Glenn Morris @ 2009-11-10 2:11 UTC (permalink / raw)
To: Stefan Monnier; +Cc: Chong Yidong, emacs-devel
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.
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: loaddefs and provide
2009-11-10 2:11 ` Glenn Morris
@ 2009-11-10 17:48 ` Stefan Monnier
2009-11-10 18:40 ` Chong Yidong
0 siblings, 1 reply; 13+ messages in thread
From: Stefan Monnier @ 2009-11-10 17:48 UTC (permalink / raw)
To: Glenn Morris; +Cc: Chong Yidong, emacs-devel
> 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
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: loaddefs and provide
2009-11-10 17:48 ` Stefan Monnier
@ 2009-11-10 18:40 ` Chong Yidong
0 siblings, 0 replies; 13+ messages in thread
From: Chong Yidong @ 2009-11-10 18:40 UTC (permalink / raw)
To: Stefan Monnier; +Cc: emacs-devel
Stefan Monnier <monnier@IRO.UMontreal.CA> 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.
^ permalink raw reply [flat|nested] 13+ messages in thread
end of thread, other threads:[~2009-11-10 18:40 UTC | newest]
Thread overview: 13+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
[not found] <E1N5Tis-0002pY-NM@cvs.savannah.gnu.org>
2009-11-04 3:12 ` loaddefs and provide Glenn Morris
2009-11-04 3:58 ` Stefan Monnier
2009-11-04 8:37 ` Glenn Morris
2009-11-04 8:46 ` Glenn Morris
2009-11-04 18:36 ` Stefan Monnier
2009-11-04 19:11 ` Glenn Morris
2009-11-04 20:46 ` Stefan Monnier
2009-11-04 17:10 ` Chong Yidong
2009-11-04 20:45 ` Stefan Monnier
2009-11-10 2:11 ` Glenn Morris
2009-11-10 17:48 ` Stefan Monnier
2009-11-10 18:40 ` Chong Yidong
2009-11-04 9:54 ` Juanma Barranquero
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.