hi all,
I have found a few things that I miss in the SLIME repl:
* a key binding to erase all input before point; much like comint's C-c C-u. alternatively, * a key binding to jump to just after the input marker; and
* slightly different RET handling.
currently, SLIME will insert the RET at (point) and then send the line if I am inside a complete sexp. this can lead to badness like:
ZY> (un trace my-function)
or just ugly cmdlines in the history when I use M-(
I think inserting the \n only when (point) is at the end of the finished sexp would work better.
Thanks,
Andreas Fuchs asf@boinkor.net writes:
I have found a few things that I miss in the SLIME repl:
- a key binding to erase all input before point; much like comint's C-c C-u. alternatively,
C-c C-o will clear the output of the last expression, and C-c C-t will clear the whole buffer.
- a key binding to jump to just after the input marker; and
You mean like C-a but working from any line? Maybe a job for C-M-u (backward-up-list)?
- slightly different RET handling.
currently, SLIME will insert the RET at (point) and then send the line if I am inside a complete sexp. this can lead to badness like:
ZY> (un trace my-function)
IIUC this behaviour is recently improved. If you press RET and have a complete sexp, we don't insert a newline anymore. Can you try the latest and see if it's right for you?
-Luke
Today, Luke Gorrie luke@bluetail.com wrote:
Andreas Fuchs asf@boinkor.net writes:
I have found a few things that I miss in the SLIME repl:
- a key binding to erase all input before point; much like comint's C-c C-u. alternatively,
C-c C-o will clear the output of the last expression, and C-c C-t will clear the whole buffer.
Hm, that's cool; though I was thinking about something that can wipe out the entire input line, not the output.
- a key binding to jump to just after the input marker; and
You mean like C-a but working from any line? Maybe a job for C-M-u (backward-up-list)?
Something like that; anything that takes (point) to the true beginning of the input and not to the beginning of the line would be fine. I'd just like to have a way to navigate large expressions easily (-:
- slightly different RET handling.
currently, SLIME will insert the RET at (point) and then send the line if I am inside a complete sexp. this can lead to badness like:
ZY> (un trace my-function)
IIUC this behaviour is recently improved. If you press RET and have a complete sexp, we don't insert a newline anymore. Can you try the latest and see if it's right for you?
Ooh, I didn't upgrade before complaining. The newest version doesn't do the annoying \n insertion thing anymore.
Thanks!
Andreas Fuchs asf@boinkor.net wrote:
Today, Luke Gorrie luke@bluetail.com wrote:
You mean like C-a but working from any line? Maybe a job for C-M-u (backward-up-list)?
Something like that; anything that takes (point) to the true beginning of the input and not to the beginning of the line would be fine. I'd just like to have a way to navigate large expressions easily (-:
Comint mode has C-c C-p to go to previous prompt. This is taken in the slime-repl by slime-pprint-eval-last-expression, which is not really needed in the repl I think. Unbind that and bind to comint-previous-prompt, and you're partway there. My problem is then: if what comes between the prompts is only OUTPUT, comint-previous-prompt will not work because it is looking for the start of the previous input. This is not a problem in the normal comint modes, because you always have some input before you get any output. With lisp, which can be provoked to do output either from a running thread or something coming in on the slime connection, this is not good enough. I suggest removing :inferior t from the \C-p the 'slime-keys' variable, and adding something like (tested for 5 minutes):
(defun slime-repl-previous-prompt (n) "Move to end of Nth previous prompt in the buffer. Unlike comint mode `comint-use-prompt-regexp-instead-of-fields' has no effect, and we look for a read-only (i.e. prompt ) field rather than an input field. " ;; cribbed and hacked from comint-previous-prompt (interactive "p") (slime-repl-next-prompt (- n)))
(defun slime-repl-next-prompt (n) "Move to end of Nth next prompt in the buffer. Unlike comint mode `comint-use-prompt-regexp-instead-of-fields' has no effect, and we look for a read-only (i.e. prompt ) field rather than an input field. " ;; cribbed and hacked from comint-next-prompt ;; the 'read-only' thing is really not nice, but what else but a prompt ;; would ever be read only? (interactive "p") (let ((pos (point)) (input-pos nil) prev-pos) (while (/= n 0) (setq prev-pos pos) (setq pos (if (> n 0) (next-single-char-property-change pos 'read-only) (previous-single-char-property-change pos 'read-only))) (cond ((or (null pos) (= pos prev-pos)) ;; Ran off the end of the buffer. (when (> n 0) ;; There's always an input field at the end of the ;; buffer, but it has a `field' property of nil. (setq input-pos (point-max))) ;; stop iterating (setq n 0)) ((eq (get-char-property pos 'read-only) nil) (setq n (if (< n 0) (1+ n) (1- n))) (setq input-pos pos)))) (when input-pos (goto-char input-pos))))
(define-key slime-repl-mode-map "\C-c\C-n" 'slime-repl-next-prompt) (define-key slime-repl-mode-map "\C-c\C-p" 'slime-repl-previous-prompt)
The reason this has only been tested for 5 minutes is that I had an even grosser hack bound on C-a. This will move to column 0 if we're already at the prompt, and then to the previous prompt if we're already at col 0. This hack will henceforth be abandoned.
(defun slime-repl-bol () "Go to the beginning of line or the prompt." (interactive) (let ((point (point))) (if (and (>= (point) slime-repl-input-start-mark) (slime-same-line-p (point) slime-repl-input-start-mark)) (goto-char slime-repl-input-start-mark) (beginning-of-line 1)) (if (eql point (point)) ; go to very beginning of line (forward-line 0)) (if (eql point (point)) ; go to end of previous field (goto-char (previous-single-char-property-change (point) 'read-only)))))
"Håkon Alstadheim" haalst@online.no writes:
I suggest removing :inferior t from the \C-p the'slime-keys' variable, and adding something like (tested for 5 minutes):
Done in the the cvs version. Thanks for the suggestion!
Helmut.
Andreas Fuchs asf@boinkor.net writes:
Something like that; anything that takes (point) to the true beginning of the input and not to the beginning of the line would be fine. I'd just like to have a way to navigate large expressions easily (-:
I've added a binding for C-M-a and C-M-e that moves point to the beginning resp. the end of the input region.
Helmut.
-
Andreas Fuchs -
Helmut Eller -
Håkon Alstadheim -
Luke Gorrie