search

joaotavora / sly

Sylvester the Cat's Common Lisp IDE
1.26k stars 142 forks source link

fix definition-source-for-emacs for case when source was categorized as :file-without-position #516

Open svetlyak40wt opened 2 years ago

svetlyak40wt commented 2 years ago

This fix relates to SBCL and the case when definition relates to a function.

Here definition-source-for-emacs is called with name having string type: https://github.com/joaotavora/sly/blob/b501b4335096fd4306c2c1eb86382b69e91c09e5/slynk/backend/sbcl.lisp#L872

In this case we have to use it as is instead of trying to call SYMBOL-NAME.

I've encounter this problem when attempted to setup logical pathname translations to make SLY open local files when connected to the remote Lisp image.

Here is the Reddit discussion where everything begins: https://www.reddit.com/r/Common_Lisp/comments/vc6hix/source_location_for_deployed_binary/

joaotavora commented 2 years ago

The patch looks harmless enough, but I can't understand from the long reddit thread what you are trying to do.

At any rate, if this patch is indeed fixing a bug in a real use case, it should likely be contributed to SLIME too, so let's hail its maintainer @luismbo here to see if he has anything to add.

svetlyak40wt commented 2 years ago

Here is what I'm trying to do.

I have following setup:

  1. Application built in a docker and running inside kubernetes cluster
  2. It's sources on my local hard drive
  3. Emacs and SLY running locally

I want to use Lisp's logical pathnames to translate paths from remote machine to my local pathnames. (I know about sly-filename-translations but approach with logical pathnames seems more natural to me.

To accomplish this, I need to teach SLY to work with logical pathnames. Diff from this pull-requiest fixes a small issue, but it is not enough. I've experimented with this approach today and found that for making opening location from a stack trace, I need more changes to the SLYNK backend. Here is the draft: https://github.com/svetlyak40wt/sly/commit/35f601eff75dcec5b17ea0b4223dd072aa65bcf8).

I'll play with this approach a little to see if it can be convenient and probably will create an additional pull-request.

svetlyak40wt commented 2 years ago

And one more. Idea of changes from https://github.com/svetlyak40wt/sly/commit/35f601eff75dcec5b17ea0b4223dd072aa65bcf8 is following:

  1. application is compiled using logical pathnames like APP:src;*.*.
  2. when SLY connects to this application, it adds a logical pathname translation for host APP-LOCAL, pointing it to the local sources of the application.
  3. also, SLY registers mapping from APP to APP-LOCAL hostname in some internal variable *remote-to-local-hosts*.
  4. after that, when SLYNK sends some pathname to the SLY, it translates logical pathnames by changing APP host to APP-LOCAL and then applying TRANSLATE-LOGICAL-PATHNAME to it.
  5. SLY sees local pathname and opens the local file.
svetlyak40wt commented 2 years ago

Probably I'm overcomplicating and there is more elegant solution for opening local files?