[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Is (provide 'foo) at the start good or bad?
From: |
William Xu |
Subject: |
Re: Is (provide 'foo) at the start good or bad? |
Date: |
Fri, 12 Jun 2009 08:01:32 +0300 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/23.0.91 (windows-nt) |
"Stephen J. Turnbull" <address@hidden> writes:
> Leo writes:
>
> > > one less char). So what is the benefit of providing it at the very
> > > start?
> >
> > I have run into this problem before. I prefer putting provide at the end
> > of the file.
>
> Putting the provide form at the beginning allows mutually recursive
> requires to succeed. I also prefer it as a matter of style, sort of
> serving as a `declare-package'.
That makes sense. But looks like doesn't work very well? I tried the
following:
a.el
====
(provide 'a)
(require 'b)
(defun a-hi ()
)
(b-hi)
b.el
====
(provide 'b)
(require 'a)
(defun b-hi ()
)
(a-hi)
Put them under load-path, now if I try (require 'a), i got:
,----
| Debugger entered--Lisp error: (void-function a-hi)
| (a-hi)
| eval-buffer(#<buffer *load*<2>> nil "q:/.emacs.d/site-lisp/b.el" nil t) ;
Reading at buffer position 55
| load-with-code-conversion("q:/.emacs.d/site-lisp/b.el"
"q:/.emacs.d/site-lisp/b.el" nil t)
| require(b)
| eval-buffer(#<buffer *load*> nil "q:/.emacs.d/site-lisp/a.el" nil t) ;
Reading at buffer position 27
| load-with-code-conversion("q:/.emacs.d/site-lisp/a.el"
"q:/.emacs.d/site-lisp/a.el" nil t)
| require(a)
| eval((require (quote a)))
| eval-last-sexp-1(nil)
| eval-last-sexp(nil)
| call-interactively(eval-last-sexp nil nil)
`----
So this doesn't really resolve the recursive requires?
> Regarding work-arounds, I would do the OP's task (customizing a
> variable) in a mode-hook using `add-to-list', rather than as an
> eval-after-load.
Unfortunately, ffap has no such hook available, and it is not a mode.
add-to-list itself recommends eval-after-load at some point somehow:
,----[ C-h f add-to-list RET ]
| add-to-list is a compiled Lisp function in `subr.el'.
|
| (add-to-list LIST-VAR ELEMENT &optional APPEND COMPARE-FN)
|
| Add ELEMENT to the value of LIST-VAR if it isn't there yet.
| The test for presence of ELEMENT is done with `equal',
| or with COMPARE-FN if that's non-nil.
| If ELEMENT is added, it is added at the beginning of the list,
| unless the optional argument APPEND is non-nil, in which case
| ELEMENT is added at the end.
|
| The return value is the new value of LIST-VAR.
|
| If you want to use `add-to-list' on a variable that is not defined
| until a certain package is loaded, you should put the call to `add-to-list'
| into a hook function that will be run only after loading the package.
| `eval-after-load' provides one way to do this. In some cases
| other hooks, such as major mode hooks, can do the job.
`----
--
William
http://xwl.appspot.com
- Is (provide 'foo) at the start good or bad?, William Xu, 2009/06/11
- Re: Is (provide 'foo) at the start good or bad?, Alan Mackenzie, 2009/06/12
- Re: Is (provide 'foo) at the start good or bad?, Stephen J. Turnbull, 2009/06/12
- Re: Is (provide 'foo) at the start good or bad?, Davis Herring, 2009/06/12
- Re: Is (provide 'foo) at the start good or bad?, Stephen J. Turnbull, 2009/06/13
- Re: Is (provide 'foo) at the start good or bad?, Davis Herring, 2009/06/14
- Re: Is (provide 'foo) at the start good or bad?, Stephen J. Turnbull, 2009/06/14