Hello. I've discovered a problem with swank-listener-hooks (rendering REPL unusable), which is needed for CLG. The trivial patch that restores it's functionality is attached. Another patch attached to this message makes SLIME REPL usable in Paredit mode by using the part of input between its start and (point) as history search pattern. I've sent a patch doing that long time ago, it was applied but later accidentally (as I understood it after asking on #lisp) reverted. I forgot about it for a while and just kept changes in my copy of SLIME, but now I decided to share them again.
Thanks. Ivan
* Ivan Shvedunov [2008-10-26 15:56+0100] writes:
Hello. I've discovered a problem with swank-listener-hooks (rendering REPL unusable), which is needed for CLG. The trivial patch that restores it's functionality is attached.
Patch applied.
Another patch attached to this message makes SLIME REPL usable in Paredit mode by using the part of input between its start and (point) as history search pattern. I've sent a patch doing that long time ago, it was applied but later accidentally (as I understood it after asking on #lisp) reverted. I forgot about it for a while and just kept changes in my copy of SLIME, but now I decided to share them again.
I committed this with some modifications. It's still a mystery to me how this patch can affect paredit mode.
Helmut.
On Thu, Oct 30, 2008 at 11:02 AM, Helmut Eller heller@common-lisp.net wrote:
Patch applied.
Thanks.
Another patch attached to this message makes SLIME REPL usable in Paredit mode by using the part of input between its start and (point) as history search pattern. I've sent a patch doing that long time ago, it was applied but later accidentally (as I understood it after asking on #lisp) reverted. I forgot about it for a while and just kept changes in my copy of SLIME, but now I decided to share them again.
I committed this with some modifications. It's still a mystery to me how this patch can affect paredit mode.
Well, it affects paredit mode in REPL buffer. Paredit automagically inserts ')' after you type '('. So if you typed '(lo' you will have '(lo)' at your REPL prompt with point before the closing paren and when you press M-p to find previous '(loop ...)' expression you typed before, nothing will be found unless the portion between start of input and point is used, unless of course you typed exactly '(lo)' before.
Ivan
Ivan Shvedunov wrote:
On Thu, Oct 30, 2008 at 11:02 AM, Helmut Eller heller@common-lisp.net wrote:
Patch applied.
Thanks.
Another patch attached to this message makes SLIME REPL usable in Paredit mode by using the part of input between its start and (point) as history search pattern. I've sent a patch doing that long time ago, it was applied but later accidentally (as I understood it after asking on #lisp) reverted. I forgot about it for a while and just kept changes in my copy of SLIME, but now I decided to share them again.
I committed this with some modifications. It's still a mystery to me how this patch can affect paredit mode.
Well, it affects paredit mode in REPL buffer. Paredit automagically inserts ')' after you type '('. So if you typed '(lo' you will have '(lo)' at your REPL prompt with point before the closing paren and when you press M-p to find previous '(loop ...)' expression you typed before, nothing will be found unless the portion between start of input and point is used, unless of course you typed exactly '(lo)' before.
How I fixed that in my slime.el is that I added t to slime-repl-current-input
=================================== file: slime.el
(defun slime-repl-history-pattern (&optional use-current-input) "Return the regexp for the navigation commands." (cond ((slime-repl-history-search-in-progress-p) slime-repl-history-pattern) (use-current-input - (let ((str (slime-repl-current-input))) + (let ((str (slime-repl-current-input t))) (cond ((string-match "^[ \n]*$" str) nil) (t (concat "^" (regexp-quote str)))))) (t nil)))
On Oct 31, 2008, at 10:01 , Knut Olav Bøhmer wrote:
How I fixed that in my slime.el is that I added t to slime-repl- current-input
(let ((str (slime-repl-current-input)))
(let ((str (slime-repl-current-input t)))
Same here, works for me since quite a while now.
Michael Weber wrote:
On Oct 31, 2008, at 10:01 , Knut Olav Bøhmer wrote:
How I fixed that in my slime.el is that I added t to slime-repl- current-input
(let ((str (slime-repl-current-input)))
(let ((str (slime-repl-current-input t)))Same here, works for me since quite a while now.
it does not work for me in in slime-current-2008-11-09 It is becauce of slime-presentations.el
Here is the fix:
(defun slime-presentation-current-input (&optional until-point-p) "Return the current input as string. The input is the region from after the last prompt to the end of buffer. Presentations of old results are expanded into code." (slime-buffer-substring-with-reified-output slime-repl-input-start-mark - (point-max))) + (if until-point-p + (point) + (point-max))))
I have another paredit improvment. When tab-completing files I get an extra " on the end of the filename.
(defun slime-maybe-complete-as-filename () "If point is at a string starting with ", complete it as filename. Return nil iff if point is not at filename." (if (save-excursion (re-search-backward ""[^ \t\n]+\=" nil t)) - (let ((comint-completion-addsuffix '("/" . """))) + (let ((comint-completion-addsuffix '("/" . ""))) (if slime-when-complete-filename-expand (comint-replace-by-expanded-filename) (comint-dynamic-complete-as-filename)) t) nil))
But this time I realy think it should be dependent on if you have paredit or not. It removes the anoying extra " when you tab-complete filenames.
Knut Olav Bøhmer wrote:
Michael Weber wrote:
On Oct 31, 2008, at 10:01 , Knut Olav Bøhmer wrote:
How I fixed that in my slime.el is that I added t to slime-repl- current-input
(let ((str (slime-repl-current-input)))
(let ((str (slime-repl-current-input t)))Same here, works for me since quite a while now.
it does not work for me in in slime-current-2008-11-09 It is becauce of slime-presentations.el
[-snipped-]
But this time I realy think it should be dependent on if you have paredit or not. It removes the anoying extra " when you tab-complete filenames.
But you probably want a patch. This patch checks if paredit is enabled. Maybe we should have something like slime-completion-addsuffix instead of comint-completion-addsuffix. or, comint-completion-addsuffix could be made local in every slime buffer.
The best would be if the function forward-char would be called, so that you skip past the last "
Helmut Eller wrote:
- Knut Olav Bøhmer [2008-10-31 10:01+0100] writes:
How I fixed that in my slime.el is that I added t to slime-repl-current-input
Yes, that's nicer.
Helmut.
That should be configurabe. And a hook could be made when paredid is enabled, so that it sets this option right.
On Nov 4, 2008, at 10:29 , Knut Olav Bøhmer wrote:
How I fixed that in my slime.el is that I added t to slime-repl- current-input
Yes, that's nicer.
That should be configurabe. And a hook could be made when paredid is enabled, so that it sets this option right.
Does that add much? You can always go to the end of the REPL input first, which should give you the old behavior. I even doubt most users would notice...
Michael Weber wrote:
On Nov 4, 2008, at 10:29 , Knut Olav Bøhmer wrote:
How I fixed that in my slime.el is that I added t to slime-repl- current-input
Yes, that's nicer.
That should be configurabe. And a hook could be made when paredid is enabled, so that it sets this option right.
Does that add much?
No.
You can always go to the end of the REPL input first, which should give you the old behavior.
yes
I even doubt most users would notice...
agree.
-
Helmut Eller -
Ivan Shvedunov -
Knut Olav Bøhmer -
Michael Weber