Hello João,
If you recall, I mentioned some error messages that occurred in the slime *messages* buffer when I tried to load log4cl:
error in process filter: ad-Orig-slime-repl-emit: Text is read-only error in process filter: Text is read-only
Well, this afternoon I was trying to track down a problem related to some work I was doing and I went to the *inferior-lisp* buffer and entered (sb-ext:describe-compiler-policy). That produced the following error message in the *messages* buffer:
error in process filter: slime-repl-emit: Text is read-only error in process filter: Text is read-only
If I enter (sb-ext:describe-compiler-policy) in the repl, I get normal output in the repl.
Do I have some configuration issues, or is there some reason I can no longer use the *inferior-lisp* buffer for direct entry of lisp commands?
I'm using emacs 23.4.1 and sbcl-1.13 if that's important.
Paul Bowyer
Paul Bowyer pbowyer@olynet.com writes:
Do I have some configuration issues, or is there some reason I can no longer use the *inferior-lisp* buffer for direct entry of lisp commands?
Hi Paul,
I still can't reproduce. To be sure, let's agree on the test case
(setq inferior-lisp-program "sbcl") (add-to-list 'load-path "/path/to/slime") (require 'slime-autoloads) (setq slime-contribs '(slime-fancy)) ;; or do you have slime-repl? M-x slime switch to *inferior lisp* buffer type (sb-ext:describe-compiler-policy) and RET
I'm doing this with emacs 23 and everything works as expected. Are you using the very latest slime? Some days ago I fixed some failing repl tests.
That said, my best bet is that some strange interaction might be trying to overwrite the REPL prompt in slime-repl.el, which has been recently marked as read-only.
Maybe this fix is in order, It simply binds inhibit-read-only to nil around slime-repl-emit's activities.
But I would like to reproduce before I push it.
diff --git a/contrib/slime-repl.el b/contrib/slime-repl.el index 2d74e94..77bc0eb 100644 --- a/contrib/slime-repl.el +++ b/contrib/slime-repl.el @@ -262,22 +262,23 @@ This is set to nil after displaying the buffer.")
(defun slime-repl-emit (string) ;; insert the string STRING in the output buffer - (with-current-buffer (slime-output-buffer) - (save-excursion - (goto-char slime-output-end) - (slime-save-marker slime-output-start - (slime-propertize-region '(face slime-repl-output-face - slime-repl-output t - rear-nonsticky (face)) - (insert-before-markers string) - (when (and (= (point) slime-repl-prompt-start-mark) - (not (bolp))) - (insert-before-markers "\n") - (set-marker slime-output-end (1- (point))))))) - (when slime-repl-popup-on-output - (setq slime-repl-popup-on-output nil) - (display-buffer (current-buffer))) - (slime-repl-show-maximum-output))) + (let ((inhibit-read-only t)) + (with-current-buffer (slime-output-buffer) + (save-excursion + (goto-char slime-output-end) + (slime-save-marker slime-output-start + (slime-propertize-region '(face slime-repl-output-face + slime-repl-output t + rear-nonsticky (face)) + (insert-before-markers string) + (when (and (= (point) slime-repl-prompt-start-mark) + (not (bolp))) + (insert-before-markers "\n") + (set-marker slime-output-end (1- (point))))))) + (when slime-repl-popup-on-output + (setq slime-repl-popup-on-output nil) + (display-buffer (current-buffer))) + (slime-repl-show-maximum-output))))
(defun slime-repl-emit-result (string &optional bol) ;; insert STRING and mark it as evaluation result
On 01/26/2014 03:19 PM, João Távora wrote:
Paul Bowyer pbowyer@olynet.com writes:
Do I have some configuration issues, or is there some reason I can no longer use the *inferior-lisp* buffer for direct entry of lisp commands?
Hi Paul,
I still can't reproduce. To be sure, let's agree on the test case
(setq inferior-lisp-program "sbcl") (add-to-list 'load-path "/path/to/slime") (require 'slime-autoloads) (setq slime-contribs '(slime-fancy)) ;; or do you have slime-repl? M-x slime switch to *inferior lisp* buffer type (sb-ext:describe-compiler-policy) and RETI'm doing this with emacs 23 and everything works as expected. Are you using the very latest slime? Some days ago I fixed some failing repl tests.
That said, my best bet is that some strange interaction might be trying to overwrite the REPL prompt in slime-repl.el, which has been recently marked as read-only.
Maybe this fix is in order, It simply binds inhibit-read-only to nil around slime-repl-emit's activities.
But I would like to reproduce before I push it.
diff --git a/contrib/slime-repl.el b/contrib/slime-repl.el index 2d74e94..77bc0eb 100644 --- a/contrib/slime-repl.el +++ b/contrib/slime-repl.el @@ -262,22 +262,23 @@ This is set to nil after displaying the buffer.")
(defun slime-repl-emit (string) ;; insert the string STRING in the output buffer
- (with-current-buffer (slime-output-buffer)
- (save-excursion
(goto-char slime-output-end)(slime-save-marker slime-output-start(slime-propertize-region '(face slime-repl-output-faceslime-repl-output trear-nonsticky (face))(insert-before-markers string)(when (and (= (point) slime-repl-prompt-start-mark)(not (bolp)))(insert-before-markers "\n")(set-marker slime-output-end (1- (point)))))))- (when slime-repl-popup-on-output
(setq slime-repl-popup-on-output nil)(display-buffer (current-buffer)))- (slime-repl-show-maximum-output)))
(let ((inhibit-read-only t))
(with-current-buffer (slime-output-buffer)
(save-excursion(goto-char slime-output-end)
(slime-save-marker slime-output-start
(slime-propertize-region '(face slime-repl-output-faceslime-repl-output trear-nonsticky (face))(insert-before-markers string)(when (and (= (point) slime-repl-prompt-start-mark)(not (bolp)))(insert-before-markers "\n")(set-marker slime-output-end (1- (point)))))))(when slime-repl-popup-on-output(setq slime-repl-popup-on-output nil)
(display-buffer (current-buffer)))
(slime-repl-show-maximum-output))))(defun slime-repl-emit-result (string &optional bol) ;; insert STRING and mark it as evaluation result
Hi João,
I tried exactly what you said and when I entered (sb-ext:describe-compiler-policy) in the *inferior lisp* buffer, the output from that command showed up in the REPL, not in the *inferior lisp* buffer where I thought it should go. Also, I can no longer clear the *inferior lisp* buffer by selecting everything and pressing the Delete key, which I was able to do with my original .emacs file.
My Emacs is a package that comes with Linux Mint 14 and looks like it originated with Debian. The startup page shows: "This is GNU Emacs 23.4.1 (x86_64-pc-linux-gnu, GTK+ Version 2.24.12) of 2012-09-22 on allspice, modified by Debian" There might be something non-standard about my Emacs-23 package... I also have Emacs-24-something available, but I'm semi-familiar with Emacs-23 so I stay with it rather than relearning the idiosyncrasies of Emacs-24.
There must be something going on with my original .emacs file that was causing the problem with the error messages. Rather than having you look at it, I'll fiddle with it using what you sent as the starting point and add things a little at a time to see where the error occurs.
Thanks,
Paul Bowyer
Paul Bowyer pbowyer@olynet.com writes:
I tried exactly what you said and when I entered (sb-ext:describe-compiler-policy) in the *inferior lisp* buffer, the output from that command showed up in the REPL, not in the *inferior lisp* buffer where I thought it should go. Also, I can no longer clear the *inferior lisp* buffer by selecting everything and pressing the Delete key, which I was able to do with my original .emacs file.
This I can't reproduce, at least not with emacs -Q.
That is the thing: can you or can you not reproduce the issue with a clean "emacs -Q" run? Either that or moving your .emacs to the side should do the trick.
The fix I just pushed fixes *a* "error in process filter" bug in slime-repl-emit, in the situation I describe in the commit message, but I still cannot reproduce the behaviour you describe. Commands issues in the *inferior lisp* buffer output to that buffer, output does not go to the REPL buffer that the slime-repl.el contrib creates.
My Emacs is a package that comes with Linux Mint 14 and looks like it originated with Debian. The startup page shows: "This is GNU Emacs 23.4.1 (x86_64-pc-linux-gnu, GTK+ Version 2.24.12) of 2012-09-22 on allspice, modified by Debian" There might be something non-standard about my Emacs-23 package...
I don't think so, I'm using Debian at home as well, as it also says "modified by Debian"
There must be something going on with my original .emacs file that was causing the problem with the error messages. Rather than having you look at it, I'll fiddle with it using what you sent as the starting point and add things a little at a time to see where the error occurs.
I'd have no problems if you send me the file.
João
On 01/27/2014 10:48 AM, João Távora wrote:
Paul Bowyer pbowyer@olynet.com writes:
I tried exactly what you said and when I entered (sb-ext:describe-compiler-policy) in the *inferior lisp* buffer, the output from that command showed up in the REPL, not in the *inferior lisp* buffer where I thought it should go.
I did C-x 2 to get two buffers and then in the lower buffer I did C-x C-left-arrow to change it to *inferior lisp*. Then I entered (sb-ext:describe-compiler-policy) and all of the output from that command went to the upper buffer *slime-repl sbcl*. This is with the .emacs you sent.
Also, I can no longer clear the *inferior lisp* buffer by selecting everything and pressing the Delete key, which I was able to do with my original .emacs file.
More on this: If I select everything in the *inferior lisp* buffer and use the edit>cut menu selection, then it deletes everything in the *inferior lisp* buffer, but I cannot do it with the delete key. This is with the .emacs you sent.
This I can't reproduce, at least not with emacs -Q.
When I do emacs -Q from a command prompt, Emacs opens with only 2 buffers, *scratch* and *Messages*. I cannot do M-x slime because it comes back with [no match]. This is with the .emacs you sent.
That is the thing: can you or can you not reproduce the issue with a clean "emacs -Q" run? Either that or moving your .emacs to the side should do the trick.
Can't use emacs -Q to test anything with slime...
The fix I just pushed fixes *a* "error in process filter" bug in slime-repl-emit, in the situation I describe in the commit message, but I still cannot reproduce the behaviour you describe. Commands issues in the *inferior lisp* buffer output to that buffer, output does not go to the REPL buffer that the slime-repl.el contrib creates.
I'll upgrade my slime to see how it acts...
My Emacs is a package that comes with Linux Mint 14 and looks like it originated with Debian. The startup page shows: "This is GNU Emacs 23.4.1 (x86_64-pc-linux-gnu, GTK+ Version 2.24.12) of 2012-09-22 on allspice, modified by Debian" There might be something non-standard about my Emacs-23 package...
I don't think so, I'm using Debian at home as well, as it also says "modified by Debian"
There must be something going on with my original .emacs file that was causing the problem with the error messages. Rather than having you look at it, I'll fiddle with it using what you sent as the starting point and add things a little at a time to see where the error occurs.
I'd have no problems if you send me the file.
I'm attaching a copy of my original .emacs file (emacs.save)
João
By the way, yesterday I upgraded my sbcl to sbcl-1.1.14 which shouldn't matter to slime, but I'm just letting you know.
Thanks,
Paul Bowyer
Paul Bowyer pbowyer@olynet.com writes:
On 01/27/2014 10:48 AM, João Távora wrote:
Paul Bowyer pbowyer@olynet.com writes:
This is with the .emacs you sent.
Just a note: I didn not send any .emacs. I asked you to reproduce the bug but rule out any interference from your customizations, and this I call an "emacs -Q reproduction recipe". Of course since the bug report involves slime and not just emacs, you have to add a minimal amount of slime configuraiton to the recipe, which is what I sent you.
then it deletes everything in the *inferior lisp* buffer, but I cannot do it with the delete key.
That's not SLIME's problem, I believe. The delete key does not necessarily delete the region. Google for "delete-selection-mode"."
Can't use emacs -Q to test anything with slime...
Of course, explained above.
I'm attaching a copy of my original .emacs file (emacs.save)
OK, I'll have a look when I find the time.
João
Hello João,
After I upgraded slime to the most recent, I re-instated my original .emacs file (the one I sent to you as emacs.save) and started a new emacs/slime session using it.
I again did C-x 2, then in the lower frame I did C-x C-left-arrow to get to *inferior lisp* and then I did (sb-ext:describe-compiler-policy) in *inferior lisp* and all of the output went to the upper frame *slime-repl sbcl* the same as with the .emacs you sent.
I was also able to use the delete key to delete all selected text in the *inferior lisp* frame as I once did.
NOTE: I found a file I forgot I had set up. In my home directory I have ".swank.lisp" which contains, with some other stuff to redirect the location of .fasl files:
(declaim #+sbcl(sb-ext:muffle-conditions warning)) (setf swank:*globally-redirect-io* t) (declaim #+sbcl(sb-ext:unmuffle-conditions warning))
which is causing all the output from *inferior lisp* to be sent to the *slime-repl sbcl* frame. My only excuse for forgetting about this is, I'm kind of old and I lose track of things occasionally.
I apologize for my memory lapse and I hope I didn't put you through too much difficulty...
Thanks,
Paul Bowyer
Paul Bowyer pbowyer@olynet.com writes:
I again did C-x 2, then in the lower frame I did C-x C-left-arrow to get to *inferior lisp* and then I did (sb-ext:describe-compiler-policy) in *inferior lisp* and all of the output went to the upper frame *slime-repl sbcl* the same as with the .emacs you sent.
This is because of SWANK:*GLOBALLY-REDIRECT-IO* being T, as you found out.
I was also able to use the delete key to delete all selected text in the *inferior lisp* frame as I once did.
I haven't looked but you probably enable some kind of `delete-selection-mode' in your emacs, which explains this.
I apologize for my memory lapse and I hope I didn't put you through too much difficulty...
Don't apologize, your testing is valuable and there was indeed a bug in slime-repl-emit, which you helped catch.
Thanks, João
PS: May I suggest that in the future you report bugs to the bug tracker? It lives at http://github.com/slime/slime/issues
joaotavora@gmail.com (João Távora) writes:
Paul Bowyer pbowyer@olynet.com writes:
Do I have some configuration issues, or is there some reason I can no longer use the *inferior-lisp* buffer for direct entry of lisp commands?
Hi Paul,
I still can't reproduce. To be sure, let's agree on the test case
Hi again Paul,
I just reproduced the error. It happened to me, and rather brutally, when the REPL was reused after two consecutive `slime-connect' sessions. An newline in the REPL will fix things and ensure the error will not happen again, but I should have a fix ready later today or tomorrow.
João
-
joaotavora＠gmail.com -
Paul Bowyer