There is a minor annoyance that I haven't seen any of you mention. Sometimes when a debugger or compilation notes buffer pops up the first key pressed generates a 'buffer is readonly' message. From the second keypress on everything works fine.
This is with a very recent slime and emacs 21.3 from Debian Sarge.
Oh, and one more thing. I was trying to get slime work with a non-unicode aware sbcl and iso-8859-2 encoded files. I figured that setting (setq slime-net-coding-system 'binary) was the way to go. Unfortunately, when compiling a simple thing like:
(defparameter *xxx* "sdffdséfdsdf")
that contains a non ascii char slime hangs and gets disconnected if I press C-g. SBCL runs on and it possible to reconnect. This is the message from *inferior-lisp*:
;; Connection to Emacs lost. ;; [junk in string "emacs-"]
Cheers, Gábor
On Fri, 10 Dec 2004 08:55:23 +0100, Gabor Melis mega@hotpop.com wrote:
There is a minor annoyance that I haven't seen any of you mention. Sometimes when a debugger or compilation notes buffer pops up the first key pressed generates a 'buffer is readonly' message. From the second keypress on everything works fine.
I've also seen this.
Gabor Melis mega@hotpop.com writes:
There is a minor annoyance that I haven't seen any of you mention. Sometimes when a debugger or compilation notes buffer pops up the first key pressed generates a 'buffer is readonly' message. From the second keypress on everything works fine.
This is with a very recent slime and emacs 21.3 from Debian Sarge.
I don't see this in Emacs 20 and it seems to be very hard to reproduce in Emacs 21.
We had similar symptoms when we changed the buffer in a timer function and the true cause was probably a bug in Emacs' C code.
I'm not sure whether this has something to do with timer functions. Usually we don't run code in timer functions, but it can happen if a process filter aborts prematurely due to an error. The timer is then started to process remaining requests later. Maybe you can see some error message in the *Messages* buffer.
Anyway, I can't reproduce the bug so it's hard to say what should be fixed.
Oh, and one more thing. I was trying to get slime work with a non-unicode aware sbcl and iso-8859-2 encoded files. I figured that setting (setq slime-net-coding-system 'binary) was the way to go. Unfortunately, when compiling a simple thing like:
'binary only works if you set default-enable-multibyte-characters to nil.
Helmut.