[slime-devel] comma shortcut doesn't work always
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:
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?
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. -- "I conjecture that there is no good algorithm for the traveling salesman problem. My reasons are the same as for any mathematical cojecture: (1) It is a legitimate mathematical possiblity, and (2) I do not know." --Jack Edmonds, 1966
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:
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?
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))))))))
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 at lavos dot net>
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 -- *** Brian Downing <bdowning at lavos dot net>
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
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. -- Luís Oliveira luismbo (@) gmail (.) com Equipa Portuguesa do Translation Project http://www.iro.umontreal.ca/translation/registry.cgi?team=pt
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 -- Mark Triggs <mst@dishevelled.net>
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. -- PD Dr. Nicolas Neuss IWR, INF 368, D-69120 Heidelberg Email: Nicolas.Neuss@IWR.Uni-Heidelberg.De WWW: <http://www.iwr.uni-heidelberg.de/~Nicolas.Neuss>
participants (10)
-
Brian Downing -
Edi Weitz -
Frank Goenninger - PRION Consulting -
Helmut Eller -
Ivan Toshkov -
Luke Gorrie -
Luís Oliveira -
Mark Triggs -
Nicolas Neuss -
Tiago Maduro-Dias