Open Sasanidas opened 1 year ago
Oh, this TODO is very helpful. I was just starting to investigate sly to improve the functionality of lisp-mode.
sly-quicklisp
There is a contrib in Slime, IDK if it's on by default. In case:
(slime-setup '(slime-fancy
slime-quicklisp ;; on by default ?
…
))
It provides slime-quicklisp-quickload
and it adds a coma command in the REPL: ,ql RET system RET
.
https://slime.common-lisp.dev/doc/html/Quicklisp.html#Quicklisp
trace dialog
the same? https://slime.common-lisp.dev/doc/html/SLIME-Trace-Dialog.html#SLIME-Trace-Dialog
interactive objects
They are called presentations? https://slime.common-lisp.dev/doc/html/Presentations.html#Presentations
(Lem can inspect an object with C-c I
(even if it isn't colored in the repl output)).
the same? https://slime.common-lisp.dev/doc/html/SLIME-Trace-Dialog.html#SLIME-Trace-Dialog
Indeed it's the same :+1:
They are called presentations? https://slime.common-lisp.dev/doc/html/Presentations.html#Presentations
(Lem can inspect an object with C-c I (even if it isn't colored in the repl output)).
Oh yeah, same thing probably, in Lem you can indeed inspect but it's not the default behavior (not a button or similar thing).
It provides slime-quicklisp-quickload and it adds a coma command in the REPL: ,ql RET system RET.
https://slime.common-lisp.dev/doc/html/Quicklisp.html#Quicklisp
Also really similar
https://github.com/lem-project/lem/pull/778
slime/sly quicklisp
is implemented.
https://github.com/lem-project/lem/pull/783 Would this qualify as an interactive object?
783 Would this qualify as an interactive object?
Oh! Really cool, It seems really interactive for me :+1:
https://github.com/lem-project/lem/pull/792 I have implemented trace commands in this PR, what do you think?
792 I have implemented trace commands in this PR, what do you think?
Oh it's really cool, seems like it's showing the messages at the REPL, maybe having a dedicated buffer for the output? (and separated between functions so if I trace more I can clean the output if there is too much noise)
Let me know what do you think. Still, really this is already quite useful indeed :100:
Hmmm, adding a new buffer is likely to increase the cognitive load. Output to the REPL would be mixed with print debug, making it easier to keep track of execution timing. But if you just want to see a pure trace, you might want to separate the buffers. I'm having a hard time with this.
I see, don't worry, it can also be a matter of taste (I'm really used to sly), but if you want to keep this approach I'll mark the trace as done :+1:
Thanks, it's very helpful to have different opinions than mine.
the same? https://slime.common-lisp.dev/doc/html/SLIME-Trace-Dialog.html#SLIME-Trace-Dialog
I implemented both SLY and SLIME trace dialogs. I know the SLIME version is buggy (at least when I left it), especially regarding traces from multiple threads
Lem uses swank as a backend (aka Micros) that is really similar to slynk so we can probably implement a lot of features that sly have in Lem (sly is a hard fork of SLIME that has some nice additions).
Those features that I think are more interesting for Lem are:
There are maybe other improvements/features that I overlook, so don't hesitate to comment below.
Lem right now its really to close in terms of IDE features from GNU Emacs, and with a few improvement + packages I have no doubt that we can surpass it quite soon :+1: