add some lispy support

[odanoburu]

• following instructions in Function for sending string to repl #300, create public racket-mode function
  (racket-lispy-visit-symbol-definition) to be used by lispy

  • create helper function racket--visit-symbol-definition shared
    between racket-lispy-visit-symbol-definition and
    racket-visit-definition

• lispy code at abo-abo/lispy@master...odanoburu:racket, I'll submit the PR to lispy after your approval

  • I'll be implementing the lispy functions as I need them, but the two functions in the link are the bare essentials I need

[greghendershott]

Quick glance, this seems good. Just give me a day to find time to review it.

As for #300, although I added a racket-eval-last-expr, it shows the value(s) using message. Does lispy actually need a wrapper that returns the value(s)?

Also, can lispy handle there being 0 or more Racket values (0 being the void case where Racket print normally prints nothing)?

I'm just thinking ahead to whether you'll need a similar wrapper for that, like you did here.

[greghendershott]

Also, please test the scenario where racket-repl-mode doesn't exist or doesn't have a "live" REPL prompt (no Racket back-end process yet)? Is there a reasonable end user error message?

I changed this recently to (by default) not automagically helpfully try to start things. See #344.

[odanoburu]

no problem -- take the time you need!

I have only added support for visiting definition and making RET work on the REPL. I haven't done anything about the lispy-eval capability, mostly because I don't use it very much, specially when using racket. but if I need or anyone else need it I'll probably end up implementing it at some point! I mentioned #300 because I needed to add a function here so that I wasn't using a racket-mode private function on lispy. so, hum, I don't know the answers to these questions yet!

Also, please test the scenario where racket-repl-mode doesn't exist or doesn't have a "live" REPL prompt (no Racket back-end process yet)? Is there a reasonable end user error message?

it just works well, actually! it asks to run the buffer, if user says yes, all works well, if user says no, it says you need to run the REPL first.

[greghendershott]

Also, please test the scenario where racket-repl-mode doesn't exist or doesn't have a "live" REPL prompt (no Racket back-end process yet)? Is there a reasonable end user error message?

it just works well, actually! it asks to run the buffer, if user says yes, all works well, if user says no, it says you need to run the REPL first.

Great -- thanks!

[greghendershott]

I have only added support for visiting definition and making RET work on the REPL. I haven't done anything about the lispy-eval capability, mostly because I don't use it very much, specially when using racket. but if I need or anyone else need it I'll probably end up implementing it at some point! I mentioned #300 because I needed to add a function here so that I wasn't using a racket-mode private function on lispy. so, hum, I don't know the answers to these questions yet!

OK I see. That makes sense.

Also that limited thing is fine with me. Honestly, I'm a little "anxious" about the idea of racket-mode attempting to support lispy very broadly. From browsing the issues and code, I get the impression -- an initial impression, admittedly perhaps unfair -- that it is very ambitious, very opinionated, and very DWIM. Which is all great for a user, but it makes me a little nervous about the initial and ongoing effort to interoperate with it broadly and correctly.

TL;DR one baby step at a time, is fine with me.

[odanoburu]

From browsing the issues and code, I get the impression -- an initial impression, admittedly perhaps unfair -- that it is very ambitious, very opinionated, and very DWIM.

although I've been using it for a while, I only use a very limited subset of it, so I wouldn't say my opinion is much more than an impression either, but I tend to agree with your assessment! I promise not to propose radical changes 🤞

[greghendershott]

Should this be a plain old defun instead? Genuine question; I'm not sure. (Inlining across packages seems like it could be trouble. e.g. Someday we need to change this. We do. User updates racket-mode package. But. That doesn't mean lispy package necessarily gets recompiled then. Ergo confusion.)

[greghendershott]

I'm sorry to be slow to follow up. Traveling last week. Manged to get a head cold over the weekend.

I added a comment/question about the use of defsubst. Otherwise I'm OK to merge this. Thanks again.

[greghendershott]

Thanks!

[odanoburu]

I added a comment/question about the use of defsubst

you were absolutely right about this, btw! I shouldn't inline things lightly, specially in a case like this.. thanks for the heads-up!

[greghendershott]

The funny thing is, I didn't know for sure it was wrong. I just had a hunch.

I recall some weirdness with racket-mode using Emacs Lisp macros -- even just used by/within itself -- when it comes time for users to do package updates. Even just updating just racket-mode, alone. That's what led to me adding a section to the docs, about uninstalling racket-mode, restarting Emacs, and innstalling racket-mode again, to be sure.

I suppose Emacs Lisp is very much from the neighborhood that motivated Racket's "separate compilation guarantee". 😄

[odanoburu]

that and racket's CREPL (c is for cleaning State up)!

I guess reloading everything all the time would make for an unpleasant editing experience, though..

[odanoburu]

just for the record, abo-abo acepted abo-abo/lispy#488 and even added (incomplete but still useful) eval functionality 🥂