How do Sly features replace SLIME presentations?

[spwhitton]

Hello,

I'm new to both SLIME and Sly, and so far as I can tell the only significant SLIME feature that Sly drops is presentations, presumably because they're not compatible with having Sly use more modern Emacs features like comint. Are there other significant things that have been dropped? And if not, what combination of Sly features is meant to replace presentations? Is it backreferences together with M-RET and M-S-RET, or something else too?

Thanks in advance for input!

[monnier]

I'm new to both SLIME and Sly, and so far as I can tell the only significant SLIME feature that Sly drops is presentations, presumably because they're not compatible with having Sly use more modern Emacs features like comint.

[ Non-SLIME user here who doesn't know what are SLIME's "presentations". ] I'd just want to point out that `comint` has been in Emacs "for ever", probably since before SLIME's name was chosen. And it has seen very little development in the last 20 years :-( Stefan

[joaotavora]

Hello, thanks for posting.

Are there other significant things that have been dropped?

The SBCL profiler contrib, because it's SBCL specific, and I was working on a portable profiler, which stalled. Shouldn't be very hard to port that contrib back into SLY though. I've just never tried it. Likely one has to replace a lot of slime->sly and swank-slynk. A good part of SLY's contribs are just that :-)

Is it backreferences together with M-RET and M-S-RET,

Yes, yes it is. I think back-references are, in practice, more useful than presentations. In theory presentations are the superior choice, but that's in the old Lisp machines where they supposedly work perfectly. In Emacs/SLIME, they don't, as far as I remember:

• It is possible to delete the code of a presentation representing a Lisp object, for example, which doesn't make sense.
• Also, if your print functions are borked, so are your presentations.
• Also, if your print function are not borked, but print unbalanced parenthesis, so goes the parenthesis balancing in your REPL, including electric-pair-mode, or paredit (which doesn't work well with SLIME anyway, afair). Emacs just doesn't understand all that text to be an indivisible entity in a variety of parsing contexts.
• There's no easy way to pull in a presentation to the current input other than navigating to its place either with the mouse or with the keyboard. With back-references, you can even reference stuff that isn't visible (the echo area will guide you).
• Not sure if your indentation isn't potentially broken when you do manage to pull them in.
• They make the sexp's very noisy (but that's just an opinion). And potentially unlispy, unless you're operating entirely with impeccably printed objects.

It's certainly not impossible to implement presentations well in SLY, addressing these shortcomings. It's just that back-references do the job so well from my experience. (I'm of course assuming you understand how they work).

To implement presentations in SLY comint.el wouldn't be a hindrance here, I think. As Stefan comments, is quite old, but quite performing and feature-packed.

[spwhitton]

Hello João,

On Thu 25 Feb 2021 at 09:09AM -08, João Távora wrote: > Are there other significant things that have been dropped? The SBCL profiler contrib, because it's SBCL specific, and I was working on a portable profiler, which stalled. Shouldn't be very hard to port that contrib back into SLY though. I've just never tried it. Likely one has to replace a lot of `slime->sly` and `swank-slynk`. A good part of SLY's contribs are just that :-)

Okay.

> Is it backreferences together with M-RET and M-S-RET, Yes, yes it is. I think back-references are, _in practice_, more useful than presentations. In _theory_ presentations are the superior choice, but that's in the old Lisp machines where they supposedly work perfectly. In Emacs/SLIME, they don't, as far as I remember: - It is possible to delete the code of a presentation representing a Lisp object, for example, which doesn't make sense. - Also, if your print functions are borked, so are your presentations. - Also, if your print function are not borked, but print unbalanced parenthesis, so goes the parenthesis balancing in your REPL, including electric-pair-mode, or paredit (which doesn't work well with SLIME anyway, afair). Emacs just doesn't understand all that text to be an indivisible entity in a variety of parsing contexts. - There's no easy way to pull in a presentation to the current input other than navigating to its place either with the mouse or with the keyboard. With back-references, you can even reference stuff that isn't visible (the echo area will guide you). - Not sure if your indentation isn't potentially broken when you do manage to pull them in. - They make the sexp's very noisy (but that's just an opinion). And potentially unlispy, unless you're operating entirely with impeccably printed objects.

Well, I've read the docs, but haven't tried them out yet. How about this: SLIME presentations have two purposes, (i) to provide something you can right-click on to get to things like the inspector, and (ii) to give you something you can kill and yank into new ad hoc forms for evaluation. Whereas Sly uses two different kinds of entity to achieve these two purposes -- interactive objects for (i), and back references for (ii) -- how does that sound?

…

-- Sean Whitton

[joaotavora]

Well, I've read the docs, but haven't tried them out yet. How about
this: SLIME presentations have two purposes, (i) to provide something
you can right-click on to get to things like the inspector, and (ii) to
give you something you can kill and yank into new ad hoc forms for
evaluation. Whereas Sly uses two different kinds of entity to achieve
these two purposes -- interactive objects for (i), and back references
for (ii) -- how does that sound?

Do you mean: is that a fair theoretical assessment of the differences
from reading the docs without having actually tried both things?
I don't know. For example, you can also kill and yank back-references too,
because they're just text.

SLIME presentations also use back-references as an implementation
detail, it's just that SLY exposes this implementation slightly more, with
good effect IMHO. Kind of like the same way Git gives you git pull but also
git fetch and git reset. I like the latter, because the former is sometimes
a footgun in terms of under-the-covers magic.

Same in SLIME: if two presentations have the same textual presentation,
they're indistinguishable to the user, but they might mean two very different
objects. The same doesn't happen with backreferences: it's very clear
to which REPL result they a actually point.

I guess it'd be easy to provide a menu option so one can click the
presentations and it shoots it to where point is on the REPL. Additionally
-- but only as a user option that I personally wouldn't turn on --, put whatever
is already displayed in the echo area (which you can count as the "presentation")
as a skin (an "overlay" in Emacs parlance) on top of the backreference text itself.
That skin could also have a mouse menu.

But I think you should actually try the thing and come to your own conclusions.
Are you having trouble installing SLY?

[spwhitton]

On Fri 26 Feb 2021 at 03:01AM -08, João Távora wrote: SLIME presentations also use back-references as an implementation detail, it's just that SLY exposes this implementation slightly more, with good effect IMHO. Kind of like the same way Git gives you `git pull` but also `git fetch` and `git reset`. I like the latter, because the former is sometimes a footgun in terms of under-the-covers magic.

Ah, interesting.

I guess it'd be easy to provide a menu option so one can click the presentations and it shoots it to where point is on the REPL. Additionally -- but only as a user option that I personally wouldn't turn on --, put whatever is already displayed in the echo area (which you can count as the "presentation") as a skin (an "overlay" in Emacs parlance) on top of the backreference text itself. That skin could also have a mouse menu. But I think you should actually try the thing and come to your own conclusions. Are you having trouble installing SLY?

Well, I asked because I had been using SLIME for a few weeks and hadn't been using presentations, because I didn't realise you could do anything other than right-click on them to inspect. I like to keep my REPL in a small side window at the bottom of my Emacs frame, because I don't normally need to see all the old output. This doesn't work too well with back references, because to use the completion you need to be able to see the old value; it's not enough just to C-r and go look at it. Is there already a feature where I could C-r up to the value, and hit a key to insert a back reference to it at the end of the current input text? M-RET doesn't seem to do that; it just seems to update the value of '*'. I also noticed that the REPL buffer behaves more like a terminal emulator than I am used to in Emacs. For example, all text aside from the current input is read-only. Is this necessary for back references to work, or just a side-effect of the switch to comint? Can I make the REPL more like Eshell? I am quite used to going to an old input, editing it, and then hitting RET to run it again (this works in SLIME though not as smoothly as it does in Eshell). I am really appreciating how much more consistent Sly is than SLIME. Thanks for reading!

…

-- Sean Whitton

[joaotavora]

Is there already a feature where I could C-r up to the value, and hit a key to insert a back reference to it at
the end of the current input text? M-RET doesn't seem to do that; it just seems to update the value of '*'.

No there isn't, but it's a useful feature, and not too hard to add, I think. If you want to try, let me know.

I also noticed that the REPL buffer behaves more like a terminal
emulator than I am used to in Emacs.

Exactly, this is by design. The idea is that you shouldn't edit your transcript, because you would be falsifying your session results, and that could be misleading. I guess I could make a command to turn it off on a region. But why do you want to edit things there in place? Why not copy the thing to the current input and then edit it?

I am really appreciating how much more consistent Sly is than SLIME.

And I appreciate your appreciation! Thanks

[spwhitton]

Hello João,

On Wed 03 Mar 2021 at 02:04AM -08, João Távora wrote: > Is there already a feature where I could C-r up to the value, and hit a key to insert a back reference to it at the end of the current input text? M-RET doesn't seem to do that; it just seems to update the value of '*'. No there isn't, but it's a useful feature, and not too hard to add, I think. If you want to try, let me know.

A more precise definition of the feature would be: a new defcustom which changes the behaviour of M-RET across Sly, so that it inserts a backreference to the object at point, instead of causing '*' to refer to that object. If the point in the REPL is somewhere within the current input, the backreference is inserted there; otherwise, the backreference is inserted at the end of the current REPL input. I would indeed like to try adding this.

> I also noticed that the REPL buffer behaves more like a terminal emulator than I am used to in Emacs. Exactly, this is by design. The idea is that you shouldn't edit your transcript, because you would be falsifying your session results, and that could be misleading? I guess I could make a command to turn it off on a region. But why do you want to edit things there in place? Why not copy the thing to the current input and _then_ edit it?

I just find it to be a very natural and Emacs-y workflow to edit in place -- for one thing, you can see the surrounding input and output, which might be what you need to see to produce what you want to eval next. This is the main way in which I use Eshell, and it would be nice to do the same in Sly. Would it be feasible for me to add a defcustom which makes all input in the REPL editable, do you think? I guess the output has to remain uneditable because it contains buttons? Ideally I'd like it all to be editable but I doubt that is feasible. (In Eshell, I often edit command output too; C-u C-c C-r makes for a convenient workflow for filtering and editing what you got out of a command with keyboard macros.)

…

-- Sean Whitton

[spwhitton]

@joaotavora do you have any comments on these two proposed features, and are you interested in applying patches implementing them? If so, I can get to work.

[joaotavora]

Hi @spwhitton . To be honest, I'm not particularly interested in either feature, but I'm not the only user of SLY, so I guess you can try. I guess it depends on how much code and complexity it adds to an already heavy contrib/sly-mrepl.el.

But the first feature may contain a slight misunderstanding of what backreferences are. Or maybe not, I may be misunderstanding myself. Backreferences are references to objects in the REPL, not anywhere else. You can't REPL-backreference an object in the inspector unless you first return it to the REPL. Are you saying you'd like the backreference to be added to the current input at point automatically as soon as you copy an object to the REPL?

Wouldn't you rather work on that more ambitious goal of "skinning" backreferences to look like SLIME's presentations instead. I think that's a more interesting feature, but that's just an opinion.

If you're just looking for ways to contribute, analysing bug reports in the bug tracker and discussing solutions with other authors is a good way to help. I'm completely full at the moment, I don't have a second of brainpower to spare, and it's really a shame.

[spwhitton]

@joaotavora Thanks for the reply! I've thought about it some more and I think I have a simpler, less invasive idea: how about adding a new button action so that pressing 'w' on a value will copy a back reference to that value to the kill ring? If the value is already in the REPL then 'w' just copies a back reference to it; if the value if not in the REPL, it gets returned there first, so it's like M-RET immediately followed by the new button action (for buttons in the inspector or debugger, it would always return a new copy to the REPL and then copy the backreference to the kill ring, for simplicity).

Does that sound like something I can probably implement?

[spwhitton]

On Sat 06 Mar 2021 at 04:47PM -08, Sean Whitton wrote: A more precise definition of the feature would be: a new defcustom which changes the behaviour of M-RET across Sly, so that it inserts a backreference to the object at point, instead of causing '*' to refer to that object. If the point in the REPL is somewhere within the current input, the backreference is inserted there; otherwise, the backreference is inserted at the end of the current REPL input. I would indeed like to try adding this.

Ah, in order to ensure these two new features can be used together, and to simplify the above a little: A more precise definition of the feature would be: a new defcustom which changes the behaviour of M-RET across Sly, so that it inserts a backreference to the object at point, instead of causing '*' to refer to that object. The backreference is inserted at point in the REPL, unless point is within read-only text, in which case the backreference is inserted at the end of the current REPL input.

…

-- Sean Whitton