Peter S Galbraith <[EMAIL PROTECTED]> writes: >> In theory, you could ship the *.el in a dpkg-dev-el-doc package, but I >> assume it isn't a large file so it would be bloat. >> >> IMHO documentation is important. Only installing *.elc is like >> installing software without info manual or man pages. > > The *.el files are of course shipped. How else could I byte-compile > them! :-)
Right, but they aren't "installed" as far as Emacs is concerned, since emacs doesn't find them when it wants to. >> Perhaps you don't need to byte compile the package? Few elisp >> packages really need it, and doing things this way would fix the >> problem. Compare the 'idn' package, it simply put files in >> /usr/share/emacs/site-lisp/. It also make Emacs generate better >> debugging information, should users ever encounter a bug. And it >> doesn't bloat load-path. > > Right. I think the files are large enough to warrant byte-compilation. > Although, they probably don't do tasks that take very long. Maybe try it uncompiled (on a slow machine) and see if it is usable? >> You could also consider using autoload instead of bloating load-path >> at all, although I'm not sure if Emacs is smart enough to locate >> documentation this way. If not, it should probably be regarded as a >> bug, and reported. If you need to byte compile the file, this is >> probably the best solution. > > I'm sorry. I don't follow. The byte-compiled library is already loaded > by then, so how is autoload supposed to work? Documentation is > available from the .elc files. What doesn't work is the clickable link > to the source code, e.g. the `debian-bts-control' string below is > clickable after doing `C-h f debian-bts-control': > > : debian-bts-control is an interactive autoloaded Lisp function in > `debian-bts-control'. > : [Arg list not available until function definition is loaded.] > : > : Contruct a message with initial ACTION command for [EMAIL PROTECTED] > : Contructs a new control command line if called from within the message > : being constructed. > > I think the only way to make this work if to have the .el file in the > load-path. But is it worth it? I see. Close to a solution seem to be in find-function-source-path, only problem is that when it is defined it completely overrides load-path. Perhaps it would be useful to propose a find-function-source-path-extra which find-function could look into, after load-path was exhausted. Then when *.elc and *.el are installed in different places, instead of adding the *.el path to load-path, it could be added to f-f-s-p-e, to make find-function find it. Of course, this would require emacs to be changed, either upstream or by debian, which may be too much work to solve this problem.
