Another minor glitch that I encountered is that the comma shortcut in the REPL doesn't always work. I can consistently reproduce it (GNU Emacs 21.3.50 and also 21.3 release) like this:
1. Make sure point is at the beginning of a REPL input line.
2. Split Emacs frame into two windows, one of them being the REPL the other one containing something else.
3. Hide REPL window with C-x 0.
4. Now type M-x slime.
5. Type the comma.
At this point I'm not asked for a shortcut command in the minibuffer but the comma is simply entered into the REPL instead.
Anybody else seeing this?
Cheers, Edi.
On Wed, 2004-04-21 at 01:40, Edi Weitz wrote:
Now type M-x slime.
Type the comma.
At this point I'm not asked for a shortcut command in the minibuffer but the comma is simply entered into the REPL instead.
Anybody else seeing this?
Actually, I think all you need are these two steps :). Whenever I start SLIME, the first character will always be entered into the REPL, even if it is a comma. If I try pressing backspace first, for instance, pressing comma afterwards will have the expected behaviour.
Tiago.
On Wed, 21 Apr 2004 01:48:55 +0200, Tiago Maduro-Dias tcmd@rnl.ist.utl.pt wrote:
On Wed, 2004-04-21 at 01:40, Edi Weitz wrote:
Now type M-x slime.
Type the comma.
At this point I'm not asked for a shortcut command in the minibuffer but the comma is simply entered into the REPL instead.
Anybody else seeing this?
Actually, I think all you need are these two steps :).
Yes, in most cases. But not always. I can see no pattern here.
Whenever I start SLIME, the first character will always be entered into the REPL, even if it is a comma. If I try pressing backspace first, for instance, pressing comma afterwards will have the expected behaviour.
I tried to debug this but I'm stuck. From my playing around I gather that when this happens slime-repl-mode-map isn't used at all[1] but I have no idea why this should be the case.
Hmmm, Edi.
[1] Try adding something like (message "FOOOO") to slime-space and press SPC instead of comma in the example above. No message. Press any other key and now you'll see "FOOOO" each time you press SPC.
Edi Weitz edi@agharta.de writes:
I tried to debug this but I'm stuck. From my playing around I gather that when this happens slime-repl-mode-map isn't used at all[1] but I have no idea why this should be the case.
I suspect this has something to do with funny property inheritance near the prompt. Do the symptoms go a away if you try this?
(defun slime-repl-insert-prompt (result &optional time) "Goto to point max, insert RESULT and the prompt. Set slime-output-end to start of the inserted text slime-input-start to end end." (slime-flush-output) (goto-char (point-max)) (let ((start (point))) (unless (bolp) (insert "\n")) (slime-insert-propertized '(face slime-repl-result-face) result) (unless (bolp) (insert "\n")) (let ((prompt-start (point))) (slime-propertize-region '(face slime-repl-prompt-face read-only t intangible t slime-repl-prompt t ;; emacs stuff rear-nonsticky t ;; xemacs stuff start-open t end-open t) (insert (slime-lisp-package) "> ")) (set-marker slime-output-end start) (set-marker slime-repl-prompt-start-mark prompt-start) (slime-mark-input-start) (let ((time (or time 0.2))) (cond ((zerop time) (slime-repl-move-output-mark-before-prompt (current-buffer))) (t (run-at-time time nil 'slime-repl-move-output-mark-before-prompt (current-buffer))))))))
On Thu, 22 Apr 2004 14:51:48 +0200, Helmut Eller e9626484@stud3.tuwien.ac.at wrote:
I suspect this has something to do with funny property inheritance near the prompt. Do the symptoms go a away if you try this?
No, unfortunately not.
Edi Weitz edi@agharta.de writes:
I suspect this has something to do with funny property inheritance near the prompt. Do the symptoms go a away if you try this?
No, unfortunately not.
I think I found the cause of the problem. Apparently an Emacs bug/particularity related to timers. The first command after the execution of a timer function seems to be looked up in the buffer in which the timer was started and not in the current buffer, e.g., the form
(run-at-time 2 nil (lambda () (with-current-buffer (generate-new-buffer "x.x") (emacs-lisp-mode) (insert "(+ 1 2)") (pop-to-buffer (current-buffer)) (setq unread-command-events (append (listify-key-sequence "\C-j") unread-command-events)))))
creates a buffer with contents
(+ 1 2) 3
when executed from the Emacs *scratch* buffer. The binding of C-j in the *scratch* buffer is used and not the one in the x.x buffer. Subsequent commands work correctly. As a workaround, I generate a synthetic C-l event, which only performs redisplay.
Helmut.
On Thu, Apr 22, 2004 at 10:15:17PM +0200, Helmut Eller wrote:
As a workaround, I generate a synthetic C-l event, which only performs redisplay.
I'm not sure what you mean by a synthetic C-l event here, but I for one rebind C-l, making C-l C-l be recenter and opening up a lot of other useful bindings for me. So if slime is going to be generating C-l (as opposed to recenter) automatically somehow it will probably screw me up. :-/
-bcd
Brian Downing bdowning@lavos.net writes:
I'm not sure what you mean by a synthetic C-l event here, but I for one rebind C-l, making C-l C-l be recenter and opening up a lot of other useful bindings for me. So if slime is going to be generating C-l (as opposed to recenter) automatically somehow it will probably screw me up. :-/
Yes your right. Do you see any problems with this:
(setq unread-command-events (append (listify-key-sequence (car (where-is-internal 'recenter overriding-local-map nil nil))) unread-command-events))
If 'recenter' isn't bound, no event is generated. Or do you know a nicer solution?
On Thu, Apr 22, 2004 at 10:58:35PM +0200, Helmut Eller wrote:
Yes your right. Do you see any problems with this:
(setq unread-command-events (append (listify-key-sequence (car (where-is-internal 'recenter overriding-local-map nil nil))) unread-command-events))
If 'recenter' isn't bound, no event is generated. Or do you know a nicer solution?
I don't know a nicer solution, my emacs-fu is almost non-existent.
I just tested CVS HEAD with the above lines and it worked fine with my strange bindings, so it works for me.
For which I'm glad, because it'd suck to live without C-l C-k (kill-sexp-up-tree). :)
Thanks! -bcd
Just wanted to note that the comma shortcut now works fine for me.
Thanks for the quick fix, Edi.
BTW, I'm not trying to nitpick. For me at least it is rather important that the shortcut works immediately because usually the first thing that I do in a new Lisp session is to load a package or to change the working directory, so it'd be cool if this could be fixed before I've made a habit out of sending a junk form like (+) to appease SLIME... :)
Let me know if/how I can help to debug this.
Thanks, Edi.
This old bug (see subject line) seems to have re-surfaced, kind of. If I start SLIME from a newly started Emacs and the first character I type is a comma it's inserted verbatim into the REPL. This is (for me, at least) annoying because I usually start a SLIME session with commands like ,l or ,+p.
Cheers, Edi.
Edi Weitz edi@agharta.de writes:
This old bug (see subject line) seems to have re-surfaced, kind of. If I start SLIME from a newly started Emacs and the first character I type is a comma it's inserted verbatim into the REPL. This is (for me, at least) annoying because I usually start a SLIME session with commands like ,l or ,+p.
I get this too. I looked into this a long time ago and have no idea what could possibly be causing it. :-)
On Mon, 19 Jul 2004 16:57:51 +0200, Luke Gorrie luke@bluetail.com wrote:
I get this too. I looked into this a long time ago and have no idea what could possibly be causing it. :-)
Me neither. But this was introduced in the last days. I updated from CVS today and it was there. My last update was probably on friday or thurday.
Edi.
Edi Weitz edi@agharta.de writes:
On Mon, 19 Jul 2004 16:57:51 +0200, Luke Gorrie luke@bluetail.com wrote:
I get this too. I looked into this a long time ago and have no idea what could possibly be causing it. :-)
Me neither. But this was introduced in the last days. I updated from CVS today and it was there. My last update was probably on friday or thurday.
Fixed now. Thank god for detailed revision history.
-Luke
On Tue, 20 Jul 2004 02:54:16 +0200, Luke Gorrie luke@bluetail.com wrote:
Fixed now. Thank god for detailed revision history.
Yo, works now. Thanks again for another super-quick fix.
Cheers, Edi.
This old problem resurfaced somehow. I /sometimes/ see it on Linux with LispWorks, but I wasn't able to create a reproducible test case. It happened on and off for the last couple of weeks or so. Any idea?
Thanks, Edi.
On Mon, 14 Nov 2005 21:33:12 +0100, Edi Weitz edi@agharta.de wrote:
This old problem resurfaced somehow. I /sometimes/ see it on Linux with LispWorks, but I wasn't able to create a reproducible test case. It happened on and off for the last couple of weeks or so. Any idea?
Hmm, am I really the only one? I also encounter this with CMUCL, BTW.
Recap: You start SLIME and if the very first character you type in the REPL buffer is a comma it is not recognized as a SLIME shortcut.
We had this problem last spring (see beginning of this thread) and Helmut fixed it. But it resurfaced this autumn/winter and I still have it - see above.
Thanks, Edi.
Hi Edi!
Am 29.01.2006 um 15:48 schrieb Edi Weitz:
On Mon, 14 Nov 2005 21:33:12 +0100, Edi Weitz edi@agharta.de wrote:
This old problem resurfaced somehow. I /sometimes/ see it on Linux with LispWorks, but I wasn't able to create a reproducible test case. It happened on and off for the last couple of weeks or so. Any idea?
Hmm, am I really the only one? I also encounter this with CMUCL, BTW.
Recap: You start SLIME and if the very first character you type in the REPL buffer is a comma it is not recognized as a SLIME shortcut.
Works for me as expected (recognized immediately) on SLIME 2006-01-20, Emacs 22.0.50.1, ACL8.0 Enterprise Edition, OS X 10.4.4 !
Gruss, Frank
On 1/29/06, Edi Weitz edi@agharta.de wrote:
Hmm, am I really the only one? I also encounter this with CMUCL, BTW.
It works fine here (Gentoo GNU/Linux, Emacs 22.0.50, SLIME CVS, SBCL 0.9.9), but I've updated from CVS after your post.
-- All languages are equal, but Lisp is more equal than others.
Edi Weitz edi@agharta.de writes:
Hmm, am I really the only one? I also encounter this with CMUCL, BTW.
Recap: You start SLIME and if the very first character you type in the REPL buffer is a comma it is not recognized as a SLIME shortcut.
FWIW, I get this sometimes (with SBCL, as that's what I use most of the times) though not in a reproducible way like yours.
On Mon, 30 Jan 2006 04:48:42 +0000, Luís Oliveira luismbo@gmail.com wrote:
FWIW, I get this sometimes (with SBCL, as that's what I use most of the times) though not in a reproducible way like yours.
Thanks, I'm relieved... :)
No, I also can't reproduce it reliably. Otherwise I would have filed a better bug report.
On 1/30/06, Luís Oliveira luismbo@gmail.com wrote:
FWIW, I get this sometimes (with SBCL, as that's what I use most of the times) though not in a reproducible way like yours.
I had that one time since my previous email. Cannot reproduce it.
-- All languages are equal, but Lisp is more equal than others.
Ivan Toshkov ivan@toshkov.org writes:
On 1/30/06, Luís Oliveira luismbo@gmail.com wrote:
FWIW, I get this sometimes (with SBCL, as that's what I use most of the times) though not in a reproducible way like yours.
I had that one time since my previous email. Cannot reproduce it.
I seem to be able to reproduce this reliably, but it only occurs when I first start a new inferior lisp process. To reproduce it I make sure there are no REPL or inferior-lisp buffers still around, then run `M-x slime' to start everything up. When the REPL buffer appears (after the animation plays), typing "," inserts a literal comma. If I backspace that comma and type another, `slime-handle-repl-shortcut' runs correctly. Does anyone else see this?
I notice `slime-init-connection-state' has a comment that reads:
;; We do the rest of our initialization asynchronously. The current ;; function may be called from a timer, and if we setup the REPL ;; from a timer then it mysteriously uses the wrong keymap for the ;; first command.
which would seem to explain what I'm seeing.
I'm using SLIME from yesterday's CVS, GNU Emacs from CVS (checked out about two months ago), and CMUCL 19a (although I can reproduce this problem with CLISP 2.34 too).
Cheers,
Mark
On Tue, 31 Jan 2006 12:33:11 +1100, Mark Triggs mark@dishevelled.net wrote:
I seem to be able to reproduce this reliably, but it only occurs when I first start a new inferior lisp process. To reproduce it I make sure there are no REPL or inferior-lisp buffers still around, then run `M-x slime' to start everything up. When the REPL buffer appears (after the animation plays), typing "," inserts a literal comma. If I backspace that comma and type another, `slime-handle-repl-shortcut' runs correctly. Does anyone else see this?
I can't reproduce it like this, unfortunately. As I said, for me it only happens sometimes and I haven't seen a pattern yet.
I notice `slime-init-connection-state' has a comment that reads:
;; We do the rest of our initialization asynchronously. The current ;; function may be called from a timer, and if we setup the REPL ;; from a timer then it mysteriously uses the wrong keymap for the ;; first command.
which would seem to explain what I'm seeing.
If timers are involved then maybe it depends on how fast you type the comma or something like that?
Cheers, Edi.
Edi Weitz edi@agharta.de writes:
Hmm, am I really the only one? I also encounter this with CMUCL, BTW.
Recap: You start SLIME and if the very first character you type in the REPL buffer is a comma it is not recognized as a SLIME shortcut.
We had this problem last spring (see beginning of this thread) and Helmut fixed it. But it resurfaced this autumn/winter and I still have it - see above.
Thanks, Edi.
I did encounter it ten minutes ago on Debian with SLIME-2005-11-22 and CMUCL and then (after updating) also with SLIME 2006-01-20. After that, the problem disappeared, i.e. I cannot reproduce it anymore.
Nicolas.
-
Brian Downing -
Edi Weitz -
Frank Goenninger - PRION Consulting -
Helmut Eller -
Ivan Toshkov -
Luke Gorrie -
Luís Oliveira -
Mark Triggs -
Nicolas Neuss -
Tiago Maduro-Dias