jpirie
commented
10 years ago (From bugzilla) Scott Fotheringham: Possible solution: Find the correct way to get the directory containing the uncompiled .el files /usr/local/share/emacs/site-lisp/smltesemacs on my system) added to load-path after the directory containing the compiled .elc files (/usr/local/share/emacs22/site-lisp/smltesemacs on my system).
It is possible this is a bug in the recommended way for packaging Emacs Lisp extensions under Debian (i.e., there may be lots of other Emacs extensions with the same problem).
Further explanation: The Emacs internal function describe-function-1 in help-fns.el does the equivalent of this when generating the hyperlink to the source file for function Xyzzy:
(describe-simplify-lib-file-name (symbol-file 'Xyzzy 'defun))
symbol-file will return the file name from which the actual definition was loaded, but then describe-simplify-lib-file-name will convert a .elc to the corresponding .el file name. This is usually good, because you don't want to look at the byte-compiled version. But Emacs needs to be able to find the source file, and in our case it can not.
When getting help on an SML-TES function, Emacs creates a help buffer with a hyperlink to the source code. The hyperlink generally refers to the file name sml-tes-main.el, which Emacs can not find, because the directory containing the uncompiled el files is not in Emacs's load-path. This cripples an important part of the help functionality and makes it much harder to debug the code.