11:30 p.m.
[moved to xemacs-beta]
On Mon, 2002-11-04 at 20:45, Martin Stjernholm wrote:
> Allrighty, here's the packages part of the "move
auto-mode-alist and
> interpreter-mode-alist associations from core to packages" for
> applicable modes.
[...]
Marcelo Matus has noted a problem with this approach when a package
is
loaded where the entry isn't equal to any already on auto-mode-alist
(can e.g. happen when another version of the package than the one
distributed with XEmacs is installed): add-to-list will then add the
entry, and it will do that to the beginning of auto-mode-alist which
causes it to override any user settings that has been made before the
package is loaded.
True.
A fix for this would be to append the new entries to the end of
auto-mode-alist instead, e.g:
;;;###autoload
(add-to-list 'auto-mode-alist '("\\.m\\'" . objc-mode) t)
This will work with Emacs 21 and XEmacs in the cvs since add-to-list
has gotten the third APPEND argument there. To make it work with older
(X)Emacsen, the package maintainer can add something like this:
[...]
Yep, you're right, the APPEND argument would be better, unfortunately it
cannot be used in XEmacs packages at the moment because of the backwards
compatibility stuff you already mentioned. And I wouldn't like to see
too big workarounds for this in every package.
Your suggestion would be a good candidate to the (yet unstarted)
forward-compat package. Or we could try to make sure these *-mode-alist
associations are only used for generating package autoloads, and not
evaluated when loading the file. I don't know how to do that, though.
Ideas?
--
\/ille Skyttä
scop at xemacs.org
12:14 a.m.
New subject: [PATCH] [packages] Move filename and interpreter associations to packages
Ville Skyttä <scop(a)xemacs.org> wrote:
> A fix for this would be to append the new entries to the end of
> auto-mode-alist instead, e.g:
>
> ;;;###autoload
> (add-to-list 'auto-mode-alist '("\\.m\\'" . objc-mode) t)
>
> This will work with Emacs 21 and XEmacs in the cvs since add-to-list
> has gotten the third APPEND argument there. To make it work with older
> (X)Emacsen, the package maintainer can add something like this:
/.../
Yep, you're right, the APPEND argument would be better,
unfortunately it
cannot be used in XEmacs packages at the moment because of the backwards
compatibility stuff you already mentioned. And I wouldn't like to see
too big workarounds for this in every package.
That is the workaround I intended to have in CC Mode. Why can't it be
used? Is there some situation where loaddefs.el in older XEmacsen are
updated with newer packages? (The size and ugliness of the kludge
itself doesn't become me very much; CC Mode already has plenty more of
similar cruft to work around bugs and limitations in various
versions. This one hardly makes a dent.)
/.../ Or we could try to make sure these *-mode-alist associations
are only used for generating package autoloads, and not evaluated
when loading the file. I don't know how to do that, though. Ideas?
From the elisp manual:
/.../ You can also use a magic comment to execute a form at build
time *without* executing it when the file itself is loaded. To do
this, write the form *on the same line* as the magic comment.
Since it is in a comment, it does nothing when you load the source
file; but `update-file-autoloads' copies it to `loaddefs.el',
where it is executed while building Emacs. /.../
Thus an alternative could be something like this:
(defun c-append-to-auto-mode-alist (element)
(unless (member element auto-mode-alist)
(setq auto-mode-alist (nconc auto-mode-alist (list element)))))
/.../
;;;###autoload (add-to-list 'auto-mode-alist '("\\.m\\'" .
objc-mode))
(c-append-to-auto-mode-alist '("\\.m\\'" . objc-mode))
But that would duplicate all the entries in the source, which I'd
rather avoid. One might of course skip the second step; it'd work
equally well as in earlier versions, when the package relied on the
central auto-mode-alist value. But I rather liked the idea to update
auto-mode-alist on package load, to install bindings for new modes
that doesn't exist in older (X)Emacsen.
7:55 a.m.
New subject: [PATCH] [packages] Move filename and interpreter associations to packages
On Tue, 2002-11-05 at 02:14, Martin Stjernholm wrote:
Ville Skyttä <scop(a)xemacs.org> wrote:
> > A fix for this would be to append the new entries to the end of
> > auto-mode-alist instead, e.g:
> >
> > ;;;###autoload
> > (add-to-list 'auto-mode-alist '("\\.m\\'" .
objc-mode) t)
> >
> > This will work with Emacs 21 and XEmacs in the cvs since add-to-list
> > has gotten the third APPEND argument there. To make it work with older
> > (X)Emacsen, the package maintainer can add something like this:
/.../
> Yep, you're right, the APPEND argument would be better, unfortunately it
> cannot be used in XEmacs packages at the moment because of the backwards
> compatibility stuff you already mentioned. And I wouldn't like to see
> too big workarounds for this in every package.
That is the workaround I intended to have in CC Mode. Why can't it be
used?
It can, but doing that in CC Mode doesn't help the N other packages out
there. I'm looking for a solution that would need to be done once, and
which would work for all of them.
Is there some situation where loaddefs.el in older XEmacsen are
updated with newer packages?
Not the file itself.
(The size and ugliness of the kludge
itself doesn't become me very much; CC Mode already has plenty more of
similar cruft to work around bugs and limitations in various
versions. This one hardly makes a dent.)
Yes, but I'm just wondering if it wouldn't have to be that way for this
particular case.
> /.../ Or we could try to make sure these *-mode-alist
associations
> are only used for generating package autoloads, and not evaluated
> when loading the file. I don't know how to do that, though. Ideas?
>From the elisp manual:
/.../ You can also use a magic comment to execute a form at build
time *without* executing it when the file itself is loaded. To do
this, write the form *on the same line* as the magic comment.
Since it is in a comment, it does nothing when you load the source
file; but `update-file-autoloads' copies it to `loaddefs.el',
where it is executed while building Emacs. /.../
Ah, thanks! But this clearly needs clarification regarding packages;
autoloads in packages are *not* copied to loaddefs.el, but into a
package-specific auto-autoloads.el. And autoloads in packages have
nothing to do with building XEmacs.
Thus an alternative could be something like this:
(defun c-append-to-auto-mode-alist (element)
(unless (member element auto-mode-alist)
(setq auto-mode-alist (nconc auto-mode-alist (list element)))))
/.../
;;;###autoload (add-to-list 'auto-mode-alist '("\\.m\\'" .
objc-mode))
(c-append-to-auto-mode-alist '("\\.m\\'" . objc-mode))
That looks kinda better to me.
But that would duplicate all the entries in the source, which
I'd
rather avoid. One might of course skip the second step; it'd work
equally well as in earlier versions, when the package relied on the
central auto-mode-alist value. But I rather liked the idea to update
auto-mode-alist on package load, to install bindings for new modes
that doesn't exist in older (X)Emacsen.
I'm not sure if I understand you correctly now, but the autoload cookies
in packages are used for that. Autoloads generated from packages stay
in packages and are installed with them. And modes in packages don't
"exist in" any XEmacsen (>= 21.1). That's why it makes no sense to have
a central auto-mode-alist in core containing entries for modes that
don't necessarily exist.
Given this, I don't see a reason why doing just a
;;;###autoload (add-to-list 'auto-mode-alist '("\\.m\\'" .
objc-mode))
...wouldn't solve the problem (ie. the only change to the current
situation being that the list wouldn't be updated on mode load time).
--
\/ille Skyttä
scop at xemacs.org
2:57 p.m.
New subject: [PATCH] [packages] Move filename and interpreter associations to packages
Ville Skyttä <scop(a)xemacs.org> wrote:
> That is the workaround I intended to have in CC Mode. Why
can't it be
> used?
It can, but doing that in CC Mode doesn't help the N other packages out
there. I'm looking for a solution that would need to be done once, and
which would work for all of them.
Ok, I just wanted to be sure about the reason. Note that I approach
this from the perspective of an independent package maintainer, not an
XEmacs maintainer.
/.../ autoloads in packages are *not* copied to loaddefs.el, but
into a package-specific auto-autoloads.el. And autoloads in
packages have nothing to do with building XEmacs.
Ok, but the end result approximately the same from the package point
of view, i.e. that the form after the ;;;###autoload cookie is
executed at XEmacs startup or some other time before the rest of the
package is loaded?
If so, my question essentially remains: Is there some situation where
the autoloads (wherever they might be stored) in older XEmacsen are
updated with newer packages?
/.../ Autoloads generated from packages stay in packages and are
installed with them. And modes in packages don't "exist in" any
XEmacsen (>= 21.1). That's why it makes no sense to have a central
auto-mode-alist in core containing entries for modes that don't
necessarily exist.
That's very neat.
Given this, I don't see a reason why doing just a
;;;###autoload (add-to-list 'auto-mode-alist '("\\.m\\'" .
objc-mode))
...wouldn't solve the problem (ie. the only change to the current
situation being that the list wouldn't be updated on mode load time).
It would be enough in XEmacs >= 21.1 when the user installs CC Mode
via the XEmacs package system, but I have to make sure things work
nicely also in older XEmacs versions, and in FSF Emacs, and when the
CC Mode dist tarball is downloaded directly from my website.
7:01 p.m.
New subject: [PATCH] [packages] Move filename and interpreter associations to packages
[perhaps xemacs-beta is enough for the Cc list...]
On Tue, 2002-11-05 at 16:57, Martin Stjernholm wrote:
> It can, but doing that in CC Mode doesn't help the N other
packages out
> there. I'm looking for a solution that would need to be done once, and
> which would work for all of them.
Ok, I just wanted to be sure about the reason. Note that I approach
this from the perspective of an independent package maintainer, not an
XEmacs maintainer.
Cool. And I think we can work out a solution that will suit all
flavours of Emacsen out there.
Ok, but the end result approximately the same from the package point
of view, i.e. that the form after the ;;;###autoload cookie is
executed at XEmacs startup or some other time before the rest of the
package is loaded?
Yes. And user customizations are loaded after that. I'm sure someone
on the list can tell all the details about the load order of various
defaults and customizations; I don't know all the details.
If so, my question essentially remains: Is there some situation
where
the autoloads (wherever they might be stored) in older XEmacsen are
updated with newer packages?
No, if you mean that a package would actually touch some files that are
part of the core XEmacs. But of course, we are modifying something that
is defined in these files; for example these additions to
auto-mode-alist, and another one would be our recent new image-mode.el,
which removes offending entries from format-alist (they exist in XEmacs
< 21.4).
> /.../ Autoloads generated from packages stay in packages and
are
> installed with them. And modes in packages don't "exist in" any
> XEmacsen (>= 21.1). That's why it makes no sense to have a central
> auto-mode-alist in core containing entries for modes that don't
> necessarily exist.
That's very neat.
Indeed:)
> Given this, I don't see a reason why doing just a
>
> ;;;###autoload (add-to-list 'auto-mode-alist '("\\.m\\'" .
objc-mode))
>
> ...wouldn't solve the problem (ie. the only change to the current
> situation being that the list wouldn't be updated on mode load time).
It would be enough in XEmacs >= 21.1 when the user installs CC Mode
via the XEmacs package system, but I have to make sure things work
nicely also in older XEmacs versions, and in FSF Emacs, and when the
CC Mode dist tarball is downloaded directly from my website.
Ok. In that case, I'd say your earlier proposal with
c-append-to-auto-mode-alist would be the way to go.
And thanks for the heads up, I'll take a look at changing the
auto-mode-alist autoloads in other packages to the one-line
;;;###autoload(foo) form.
Cheers,
--
\/ille Skyttä
scop at xemacs.org
8054
days inactive
8055
days old
4 comments
2 participants
participants (2)
-
Martin Stjernholm -
Ville Skyttä