> And slightly more difficult, but it would be nice too, to consider making M-. work from documentation files.
> It’s a good idea to start from the package export list to browse a package, but I never did it, notably because the export list loses the kind of definition the symbols name. (Agreed, it’s often obvious, but there are a lot of cases where multiple definitions of different kinds exist).
Yes, the type of definition is missing.
As a library maintainer, I like this approach for simplicity - no need to care about doc generation. And it encourages to maintain a well organized package.lisp file. In simple cases comments and grouping will help to compensate the missing definition type information (func / macro / etc).
As a library user, I would like this working because it's the quickest way to study some dependency you have problems with.
Also, I like the uniformity - list of symbols is a CLHS -style dictionary. Different library docs may have different formatting conventions,
while when opening source code definition I deal with usual formatted lisp code, which I am used to read anyways. Also for undocumented libraries, the source code is the only documentation.
I plan / hope to make a tool to generate a colorized hyperlinked version of package.lisp files. Every exported symbols will be linked source code lines at github, the links will be generated using swank.
The same can be used for documentation generators (here I mean generators for html docs published online). Although, Pascal,you probably mean some other documentation files, brows-able from Emacs?