Re: Is (provide 'foo) at the start good or bad?

[Stephen J. Turnbull]

William Xu writes:

 > That makes sense.  But looks like doesn't work very well? I tried the
 > following: 

Of course that doesn't work.  You've got a dependency loop.  In this
particular case you can break it by using "just-in-time" requires:

a.el:
(provide 'a)
(defun a-hi ())
(require 'b)
(b-hi)

b.el:
(provide 'b)
(defun b-hi ())
(require 'a)
(a-hi)

but that won't always work.  However, this:

a.el:
(require 'b)
(provide 'a)

b.el:
(require 'a)
(provide 'b)

is already an infloop.

Bottom line: In mutually recursive requires, provide at the top gives
you rope.  You can knit a hammock and enjoy life, or knot a noose and
die.  Your choice.  Provide at the bottom is an obtuse way to find out
how much memory you have.  No choice.

On the other hand you do have the original problem that
eval-after-load will not necessarily work right.  This is basically
the same issue, though, and probably needs to be fixed by refactoring
eventually.  Using a mode-activation hook is one such refactoring,
although it doesn't work in this case.

 > 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:

(eval-after-load
  ;; eventually fails silently if the list-variable was never defined
  ;; probably not what you want
  (when (boundp 'list-variable)
    (add-to-list 'list-variable element-to-add)))

or

(eval-after-load
  ;; eventually fails loudly if the list-variable was never defined
  ;; probably what you want
  (unless load-file-name
    (add-to-list 'list-variable element-to-add)))

might work, but I forget the original context.

Of course Alan is correct, there is no one right way, and you might
consider the "cures" above worse than the "disease".