Replies: 8 comments 6 replies
-
|
SLY is almost 10 years old and the read-only prompt is found very early on in much older SLIME. As to So the SLY REPL uses IME these people don't care particularly about Emacs itself, they care about their Common Lisp programs. Should we break years -- maybe decades -- of muscle memory of existing users to cure the annoyances of a relative newcomer? Wouldn't that be the a very "opinionated" thing? I'm sure you can trivially change these things with one-liners in your customization. One day -- when that doesn't cut it -- just fork SLY to PHLY and continue the legacy. Good luck! As to the |
Beta Was this translation helpful? Give feedback.
-
|
As to the `sly-mrepl`, just use `display-actions-alist` & friends.
I think what Philip is saying is that `sly-mrepl` should probably rely
on `pop-to-buffer` (or some other function calling `display-buffer`) to
do the "use existing window". As the code stands, you can't use
`display-actions-alist` to force `sly-mrepl` to use a new window, nor
can you use it for the other case unless you first customize
`switch-to-buffer-obey-display-actions` to t.
Sample 100% untested patch attached.
|
Beta Was this translation helpful? Give feedback.
-
|
Here's the patch: |
Beta Was this translation helpful? Give feedback.
-
OK. It's the "untested" part I'm worried about, but OK I'll have a look. |
Beta Was this translation helpful? Give feedback.
-
|
monnier ***@***.***> writes:
Here's the patch:
```
diff --git a/contrib/sly-mrepl.el b/contrib/sly-mrepl.el
index 25d49fe1cf..88aa3559c7 100644
--- a/contrib/sly-mrepl.el
+++ b/contrib/sly-mrepl.el
@@ -972,17 +972,19 @@ arglist for the most recently enclosed macro or function."
;;;###autoload
(defun sly-mrepl (&optional display-action)
"Find or create the first useful REPL for the default connection.
-If supplied, DISPLAY-ACTION is called on the
-buffer. Interactively, DISPLAY-ACTION defaults to using
-`switch-to-buffer' unless the intended buffer is already visible
-in some window, in which case that window is selected."
- (interactive (list (lambda (buf)
- (let ((w (get-buffer-window buf)))
- (if w (select-window w) (switch-to-buffer buf))))))
+If supplied, buffer is displayed (and selected) using DISPLAY-ACTION.
+It can either be a function (called with buffer) or an \"action\"
+to pass to `pop-to-buffer'.
+Interactively, DISPLAY-ACTION defaults to using either an
+existing window that already displays the buffer, or the current window."
+ (interactive
+ (list '((display-buffer-reuse-window display-buffer-same-window)
+ (inhibit-same-window . nil))))
(let* ((buffer
(sly-mrepl--find-create (sly-current-connection))))
- (when display-action
- (funcall display-action buffer))
+ (cond
+ ((functionp display-action) (funcall display-action buffer))
+ (display-action (pop-to-buffer buffer display-action)))
buffer))
(defun sly-mrepl-on-connection ()
```
I still do not get why the argument should be a display action though?
If we want to distinguish between interactive and non-interactive calls.
…--
Philip Kaludercic
|
Beta Was this translation helpful? Give feedback.
-
Because it's part of the interface. It's called with that argument in other places in SLY and in user's configs. |
Beta Was this translation helpful? Give feedback.
-
|
> Sample 100% untested patch attached.
OK. It's the "untested" part I'm worried about,
Yes, it's nasty especially because there can be so many different
circumstances. Even if I didn't mess up, there is absolutely no doubt
that the patch will change the default behavior in some corner cases.
The upside is that some of those changes will be for the better, and
(more importantly) that it should be easier for users to fix it when
it's not.
|
Beta Was this translation helpful? Give feedback.
-
I didn't notice this myself from my cursory reading. Can you state one of these corner cases? |
Beta Was this translation helpful? Give feedback.
-
|
I still do not get why the argument should be a display action though?
What would you use instead?
If we want to distinguish between interactive and non-interactive calls.
... ? You stopped mid-sentence and I'm having a hard time guessing how
you intended it to end.
|
Beta Was this translation helpful? Give feedback.
-
|
> that the patch will change the default behavior in some corner cases.
I didn't notice this myself from my cursory reading. Can you state one
of these corner cases?
I'm sure there are many cases I can't even imagine, but here are some
I do know:
- if the user has a matching entry in `display-buffer-alist`.
- if the command is used from a minibuffer-only frame or a dedicated
window (in which case `switch-to-buffer` signals an error whereas
`pop-to-buffer` may do various things such as create a new window or
frame).
- I suspect my code might reuse an existing window showing the buffer
in another frame, whereas the existing code only looks at windows
in the selected frame.
|
Beta Was this translation helpful? Give feedback.
-
|
monnier ***@***.***> writes:
> I still do not get why the argument should be a display action though?
What would you use instead?
A user option/variable that could be bound dynamically. That way it
would be easy to set a default behaviour.
> If we want to distinguish between interactive and non-interactive calls.
... ? You stopped mid-sentence and I'm having a hard time guessing how
you intended it to end.
I got distracted and sent the massage off too early, I am not sure what
I was going at.
…--
Philip Kaludercic
|
Beta Was this translation helpful? Give feedback.
-
If you want to bind things dinamically, I presume you're willing to write code. So why not write Anyway, I just wanted to note that this is the first time I've heard this request. Most people I know switch to the REPL with That said, I find the drawbacks that Stefan listed not serious at all, and I'll merge a pull request of that patch, especially if someone gives it some minor testing. Don't hold your breath for the user option/variable though. |
Beta Was this translation helpful? Give feedback.
-
|
I don't want to bind things dynamically, I'm saying the other functions might do so, to override a user option. But sure, that would be fix as well, though I am not a fan of these small wrapper functions.
I use C-c C-z and coming from SLIME I found it intuitive that the REPL buffer would pop up instead of replace current buffer (as I belive it is common for a lot of REPLs to do).
So it does not create the buffer, eg. after I have previously killed it (context, I kill the REPL buffer from time to time, especially when I cannot clear it using |
Beta Was this translation helpful? Give feedback.
-
The way I (and most people) clear the REPL buffer is with You can call it with
|
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
-
Hi, I would like to question some of the defaults in
sly-mrelpl.el, specifically in thesly-mrepl-modedefinitions. Specifically the modified values ofcomint-history-isearchandcomint-prompt-read-onlyare annoying to me, and should be opted in by the user (just as they have to be by default). Another annoyance is that thesly-mreplcommand has a custom display action as an argument, instead of providing a user option to configure how it repl should be displayed (e.g. I prefer a pop-up in a new window if the buffer isn't being displayed yet).Are points like these up to debate, or is there some reason for these decisions?
Beta Was this translation helpful? Give feedback.
All reactions