eval-after-load not harmful after all (Was: Re: Why js-2mode?)

[Daniel Colascione <danc@merrillpress.com>]

On Aug 10, 2009, at 5:26 AM, Leo wrote:
> On 2009-08-10 09:54 +0100, CHENG Gao wrote:
> ,----[ (info "(elisp)Coding Conventions") ]
> | * Avoid using `eval-after-load' in libraries and packages (*note
> |   Hooks for Loading::).  This feature is meant for personal
> |   customizations; using it in a Lisp program is unclean, because it
> |   modifies the behavior of another Lisp file in a way that's not
> |   visible in that file.  This is an obstacle for debugging, much
> |   like advising a function in the other package.

Actually, I think the use of eval-after-load can be a *good* thing.

As other people have mentioned, sometimes the author of a mode would  
like to add support to some other mode that provides a certain  
feature, e.g., hideshow. Requiring that rarely-used feature mode is  
inefficient, so what seems to happen in practice is that these feature  
mdoes grow lists of major modes with which they word. Consider hs- 
minor-mode, which by default has c-mode, c++-mode, bibtex-mode, and  
java-mode, or speeedbar's speedbar-obj-alist. The problem is that  
these lists are seldom updated, and more importantly, cannot really be  
exhaustive. In fact, these lists are a blatant layering violation,  
because lower-level functions like hideshow should not be required to  
know anything in particular about C.

It's not really reasonable to expect the user to fill in the gaps.  
There are too many of them (the number of modes times the number of  
additional feature modes), and the user might not know enough to be  
able to customize the feature mode appropriately.

eval-after-load provides a perfect solution. If foo-mode can detect  
that hideshow has been loaded, it can customize hideshow to handle foo  
primitives appropriately --- after all, it's foo-mode --- and still  
not incur the overhead of loading hideshow every time. (Also, hideshow  
doesn't need to be patched to add support for foo.)

Granted, eval-after-load does have the potential to enable spooky  
action at a distance and make code hard to understand. But I don't  
think that fear is relevant when eval-after-load forms call functions   
specifically designed to be used by third parties to add support for a  
new environment of some sort.

I think the coding convention should be revised.