slime-edit-definition from within of (defpackage )
On 2 Sep 2022, at 04:42, Anton Vodonosov <avodonosov@yandex.ru> wrote:
Hello.
People may want to open package.lisp of some library to study the public API, and quickly navigate to definition of any symbol from the :export list, in order to read the docstring.
I use slime-edit-definition (with the M-. shortcut) for navigation to docstrings.
But that usually does not work from within of (defpackage ) form, because slime determines the current package based on the (in-package) at the top of the file and usually package files have
(in-package :cl-user)
(defpackage :some-lib (:export #:some-function #:another-function ...))
So when cursor stays on #:some-function and M-. is pressed slime says "No known definition for: #:some-function (in :cl-user)"
As a workaround I temporarily insert (in-pakcage :some-lib) above the (defpackage ).
But it would be convenient if slime understood that the within the :export option of defpackage the symbols belong to the package being defined and not to the closest (in-package ).
So that the proposal for consideration of the slime maintainers.
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). From the documentation, the symbols are usually tagged, with a prefix or suffix [macro] or [function] or [class] etc…. The identification of the package may be more difficult since it’s often more informal, (just a title). -- __Pascal J. Bourguignon__
That makes sense. There already exist other similar extensions to M-. that allow it to find local functions for instance. See the slime-mdot-fu contrib. Cheers, Luís On Fri, 2 Sep 2022 at 03:43, Anton Vodonosov <avodonosov@yandex.ru> wrote:
Hello.
People may want to open package.lisp of some library to study the public API, and quickly navigate to definition of any symbol from the :export list, in order to read the docstring.
I use slime-edit-definition (with the M-. shortcut) for navigation to docstrings.
But that usually does not work from within of (defpackage ) form, because slime determines the current package based on the (in-package) at the top of the file and usually package files have
(in-package :cl-user)
(defpackage :some-lib (:export #:some-function #:another-function ...))
So when cursor stays on #:some-function and M-. is pressed slime says "No known definition for: #:some-function (in :cl-user)"
As a workaround I temporarily insert (in-pakcage :some-lib) above the (defpackage ).
But it would be convenient if slime understood that the within the :export option of defpackage the symbols belong to the package being defined and not to the closest (in-package ).
So that the proposal for consideration of the slime maintainers.
Best regards, - Anton
-- Luís Oliveira https://kerno.org/~luis/
How does it break sbcl? On Thu, Nov 17, 2022 at 5:34 AM Anton Vodonosov <avodonosov@yandex.ru> wrote:
17.11.2022, 02:29, "Anton Vodonosov" <avodonosov@yandex.ru>:
My workaround for now: https://github.com/cl-plus-ssl/cl-plus-ssl/commit/d2b42922bf8395e7d921a1b76f... (committed permanently, instead of manually adding it every time)
Surprisingly, this breaks SBCL when the system is loaded second time - when previously compiled .fasl files are available....
Le 17/11/2022 à 00:29, Anton Vodonosov a écrit :
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
My workaround for now: https://github.com/cl-plus-ssl/cl-plus-ssl/commit/d2b42922bf8395e7d921a1b76f... (committed permanently, instead of manually adding it every time) 02.09.2022, 11:30, "Pascal Bourguignon" <pjb@informatimago.com>: 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__
participants (4)
-
Anton Vodonosov -
Luís Oliveira -
Pascal Bourguignon -
Stas Boukarev