slime-edit-definition from within of (defpackage )

Pascal Bourguignon pjb at informatimago.com
Thu Nov 17 08:53:55 UTC 2022


Le 17/11/2022 à 00:29, Anton Vodonosov a écrit :
> My workaround for now: 
> https://github.com/cl-plus-ssl/cl-plus-ssl/commit/d2b42922bf8395e7d921a1b76f2558bcb41f5227
> (committed permanently, instead of manually adding it every time)
> 02.09.2022, 11:30, "Pascal Bourguignon" <pjb at informatimago.com>:
>  > 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?

Yes, since in general, the generated documentation has some kind of 
hyperlink already.  That would be a simple minor mode add-on to slime, 
to allow M-. to work in documentation source files (whatever the format, 
.org, .md, .txt, etc). The heuristic to find the package would have to 
be extended (no in-package form, but there are other hints).

-- 
__Pascal Bourguignon__




More information about the slime-devel mailing list