Norbert Koch <viteno(a)xemacs.org> wrote:
> It looks like nobody has run gen-macro-list.awk since I first
> it nearly a year ago. :-( It needs to be run to bring macro.list up to
> date. Do one of you package guys want to grab that, or would you rather
> I submitted a patch?
Of course I prefer patches :-) I haven't even known about your
scripts. You've brought it up in a time when I was (even more) only
an XEmacs user (and I've never wondered about them, my bad).
Except that I'm an idiot. The macro.list file is listed in .cvsignore,
for the simple fact that it's so quick and easy to generate using
gen-macro-list.awk. So the fact that mine is nearly a year old means
that *I* haven't run it in all that time, and says nothing about anybody
else. That deserves a smack in the forehead. <*smack!*>
About a year ago, we had a rash of reports about miscompiled macro
calls. I thought that there must be an automatic way of finding those
before package release, and wrote the scripts. That they are AWK
scripts you can blame on the fact that I wanted to learn AWK at the
This is the idea. The gen-macro-list.awk script searches through the
package code for every defmacro, defmacro*, defsubst, etc. it can find,
and outputs the macro/subst name and file of definition for each. This
output is stored in macro.list by convention. When the packages are
built, save the build messages somewhere, maybe packages-make-all.err to
be parallel with the source distribution. Since the byte-compiler
complains about unknown functions, what we want to do is match up those
complaints with the list of macro/subst definitions. The match-up is
done like this:
awk -f find-macro-err.awk < packages-make-all.err
That spits out a list of the mataches, and where they are defined. It
is not perfect; there is at least one false positive on the list.
However, it is a durn sight better than nothing.
> The one exception is combine-after-change-calls, which is called
> mmm-mode/mmm-cmds.el. We don't have it. An example of working around
> that is in prog-modes/diff-mode.el. This is something that should go
> into the fsf-compat package.
Can you cons up something for this?
Hmmmm... The existing stuff in fsf-compat is in files named after the
Emacs version. However, combine-after-change-calls is in subr.el in
Emacs, and we already have a subr.el. How should I name it? Does it
really belong in fsf-compat after all?
> You package guys don't have a Real Life (tm), right? :-)
:-) It's begun to kick in lately.
Me, too, except that I've spent yesterday and today basking in the glow
of too much consumed turkey.
Jerry James, thankful for American holidays