Re: Gnus dependencies

On Sat, 05 Jan 2002, jas(a)extundo.com wrote: Because they're all three fundamentally broken together. APEL is a basically good idea that is not sufficiently robustly implemented, and TM depends on it, and RMAIL depends on TM for all MIME services. Neither APEL nor TM can be effectively unloaded, either. This might be a good idea, depending on whether we make any attempt to keep RMAIL synched to GNU Emacs. It might also be possible to get rid of the TM dependency in RMAIL if you're only moving whole messages around, and don't need to parse MIME. That should get rid of the APEL dependency. It would probably be easier to keep such an RMAIL synched. Jeff> While we're at it, vm winds up loading lots of files in APEL Jeff> if you convert a rmail file to vm. In particular poe.el in Jeff> APEL redefines a large number of functions, like require. Yup. Avoiding APEL is a really good idea. Jeff> If you have advised any of the functions that poe.el Jeff> redefines then it breaks badly. Advising functions is generally not a good idea for this reason, anyway. Jeff> Symbol-function does not return the real function definition Jeff> if the function has been advised. I was rather annoyed when Jeff> I finally tracked down this particular problem. I don't understand. Do you mean it returns the original definition (wouldn't that be a bug in either symbol-function or advice?), or that it returns the advised definition (what seems logical to me)? -- Institute of Policy and Planning Sciences http://turnbull.sk.tsukuba.ac.jp University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN Don't ask how you can "do" free software business; ask what your business can "do for" free software.