[Top][All Lists]

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

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

From: Daniel Colascione
Subject: eval-after-load not harmful after all (Was: Re: Why js-2mode?)
Date: Mon, 10 Aug 2009 11:21:32 -0400

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.

reply via email to

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