[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Byte compiling questions

From: Stefan Monnier
Subject: Re: Byte compiling questions
Date: Mon, 03 Dec 2001 00:43:30 -0500

>   I got this error:
>     Compiling mh-utils.el
>     While compiling the end of the data in file 
> /usr/local/src/mh-e/src/mh-utils.el:
>       ** The function `gnus-article-highlight-citation' is not known to be 
> defined.
>     Wrote /usr/local/src/mh-e/src/mh-utils.elc

It's not an error, it's a warning.

>   I made it go away by placing the (require) in the function below in
>   (eval-and-compile) as shown. Is this the right thing to do?
> (defun mh-gnus-article-highlight-citation ()
>   "Highlight cited text in current buffer using gnus."
>   (interactive)
>   (eval-and-compile (require 'gnus-cite))

I think the accepted thing to do is to live with the warning.

>   (let ((modified (buffer-modified-p))
>         (gnus-article-buffer (buffer-name))
>         (gnus-cite-face-list 
>          '(gnus-cite-face-2 gnus-cite-face-3 gnus-cite-face-4 gnus-cite-face-5
>            gnus-cite-face-6 gnus-cite-face-7 gnus-cite-face-8 gnus-cite-face-9
>            gnus-cite-face-10 gnus-cite-face-11 gnus-cite-face-1)))
>     (gnus-article-highlight-citation t)
>     (set-buffer-modified-p modified)))

BTW, if this function is not autoloaded, how do you know that it will be
available (since you don't test (fboundp 'gnus-article-highlight-citation))?
Or is the `fboundp' somewhere else?
Oh no, wait I get it:  You did `eval-*and*-compile'.
In that case I recommend another approach: don't use `require' but put

        (autoload 'gnus-article-highlight-citation "gnus-cite")

somewhere at the top of your file instead.  [ Actually, it recently
occurred to me that we could provide a `lazy-require' which the
byte-compiler would recognize and turn into a series of autoloads. ]

>   I also got this:
>     While compiling mh-subject-thread-to-sequence in file 
> /usr/local/src/mh-e/src/mh-seq.el:
>       ** reference to free variable mh-scan-subject-regexp
>   Now mh-scan-subject-regexp is a defvar in mh-e.el which is required by
>   mh-seql.el. I don't understand why I'm getting the free variable
>   reference.

Is it a (defvar mh-scan-subject-regexp <val>) or a
(defvar mh-scan-subject-regexp) ?
If the latter, it's no wonder because when the byte-compiler loads
mh-e.el the (defvar mh-scan-subject-regexp) will have no effect
(it only has effect when the byte-compiler actually byte-compiles
this defvar, so it has to be in the same file).

>   Finally, and this is why this was posted to emacs-devel instead of
>   gnu.emacs.help, is the code expected to byte-compile clean before
>   being checked into Emacs?

It's better if it does, but loads of packages don't.
And it's better to keep the code clean than the compilation's
output clean, so it's only worth it to cleanup warnings if it
doesn't make the code ugly.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]