After updating slime to the CVS slime version of 2005-05-16 to get the GC message changes, I notice that M-p/M-n no longer seems to move the the previous/next compiler note when in the Lisp buffer. The compiler notes seem to be highlighted correctly, but M-p/M-n always say no next note.
This is with cmucl 2005-05 snapshot, and xemacs 21.5-b20. This combination with slime from Feb or so was working just fine.
I can look into this if someone gives a few pointers on where to look.
Thanks,
Ray
Raymond Toy rtoy@earthlink.net writes:
After updating slime to the CVS slime version of 2005-05-16 to get the GC message changes, I notice that M-p/M-n no longer seems to move the the previous/next compiler note when in the Lisp buffer. The compiler notes seem to be highlighted correctly, but M-p/M-n always say no next note.
With "highlighted correctly" you mean that you can do `M-x slime-list-compiler-notes' and then type RET on some note and the source gets highlighted?
One possible cause is that the file is a symlink or in a directory that is a symlink. The compiler notes contain absolute filenames and XEmacs somehow opens a second buffer even if an open buffer exists but only for the symlinked file. So the notes are only inserted in the other buffer and M-n/M-p can't find them. Maybe there's a way to customize this symlink stuff in XEmacs.
I can look into this if someone gives a few pointers on where to look.
slime-find-next-note is the relevant function, but it wasn't changed since a long time. slime-remove-old-overlays was changed recently, but it is hard to see how that could influence M-n/M-p. Also have look at the *slime-events* buffer to see what the actual filename is: search for swank:compiler-notes-for-emacs.
Helmut.
Helmut Eller wrote:
Raymond Toy rtoy@earthlink.net writes:
After updating slime to the CVS slime version of 2005-05-16 to get the GC message changes, I notice that M-p/M-n no longer seems to move the the previous/next compiler note when in the Lisp buffer. The compiler notes seem to be highlighted correctly, but M-p/M-n always say no next note.
With "highlighted correctly" you mean that you can do `M-x slime-list-compiler-notes' and then type RET on some note and the source gets highlighted?
Hmm. Let me try it with this simple function, in a new file, no symlinks:
(defun foo (x) (let ((y x)) (bar x y z)))
C-c C-c produces 4 notes in compiler-notes.
-+ Warnings (4) |-- Undefined function BAR |-- Undefined variable Z |-- This variable is undefined: | Z `-- This function is undefined: BAR
Hitting enter on the first warning, causes the parens around (bar x y z) to be highlighted. The entire form is underlined.
Hitting enter on the next line does nothing. Hitting enter on the third line says no error location available.
Some relevant parts of *slime-events*:
(:emacs-rex (swank:compiler-notes-for-emacs) nil t 3) (:return (:ok ((:message "Undefined function BAR " :severity :warning :location (:location (:buffer "notes.lisp") (:position 35) nil) :references nil :short-message "Undefined function BAR ") (:message "Undefined variable Z" :severity :warning :location (:location (:buffer "notes.lisp") (:position 35) nil) :references nil :short-message "Undefined variable Z") (:message "This variable is undefined:\n Z" :severity :warning :location (:error "No error location available.") :references nil :short-message "This variable is undefined:\n Z") (:message "This function is undefined:\n BAR" :severity :warning :location (:error "No error location available.") :references nil :short-message "This function is undefined:\n BAR"))) 3)
Moving to the file, hitting M-n/M-p just says no next note.
I'll poke around some more.
Ray
On Wed, May 18, 2005 at 12:43:30PM +0200, Helmut Eller wrote:
One possible cause is that the file is a symlink or in a directory that is a symlink. The compiler notes contain absolute filenames and XEmacs somehow opens a second buffer even if an open buffer exists but only for the symlinked file. So the notes are only inserted in the other buffer and M-n/M-p can't find them. Maybe there's a way to customize this symlink stuff in XEmacs.
In GNU Emacs the variable to frob to control this behavior I believe is 'find-file-existing-other-name'. I had lots of trouble with that and tags search at work, as I have "/build/foo" linked to "/mnt/build1/foo".
-bcd
Helmut Eller wrote:
slime-find-next-note is the relevant function, but it wasn't changed since a long time. slime-remove-old-overlays was changed recently, but it is hard to see how that could influence M-n/M-p. Also have
I played a bit more. Using my simple foo example, I trace slime-find-next-note into slime-find-note. What I see is that (funcall next-candidate-fn (point) 'slime) returns an index at the end of the buffer.
So perhaps slime-remove-old-overlays is broken on xemacs?
I'll look around some more.
Ray
Raymond Toy raymond.toy@ericsson.com writes:
So perhaps slime-remove-old-overlays is broken on xemacs?
Hmm.. slime-remove-old-overlays is very simple. I'd be surprised if there it is broken.
We have some compatibility workarounds for {next,previous}-single-char-property-change. Maybe those are bogus.
Helmut.
Helmut Eller wrote:
Raymond Toy raymond.toy@ericsson.com writes:
So perhaps slime-remove-old-overlays is broken on xemacs?
Hmm.. slime-remove-old-overlays is very simple. I'd be surprised if there it is broken.
We have some compatibility workarounds for {next,previous}-single-char-property-change. Maybe those are bogus.
You are right. It's not slime that's broken, but xemacs 21.5.20. With my little example:
(defun foo (x) (let ((y x)) (bar x y z)))
in 21.5.18, (next-single-property-change 2 'slime) returns 7, but in 21.5.20, that returns nil.
I guess I'll have to take this up with the xemacs folks.
Thanks for your patience,
Ray
Raymond Toy wrote:
Helmut Eller wrote:
Raymond Toy raymond.toy@ericsson.com writes:
So perhaps slime-remove-old-overlays is broken on xemacs?
Hmm.. slime-remove-old-overlays is very simple. I'd be surprised if there it is broken. We have some compatibility workarounds for {next,previous}-single-char-property-change. Maybe those are bogus.
You are right. It's not slime that's broken, but xemacs 21.5.20. With my little example:
(defun foo (x) (let ((y x)) (bar x y z)))
in 21.5.18, (next-single-property-change 2 'slime) returns 7, but in 21.5.20, that returns nil.
Oops. I just noticed that xemacs 21.5.20 has it's own next-single-char-property-change. And this one actually works, when I remove the definitions for them in slime.el.
I don't know enough about slime implemenation, but for xemacs 21.5.20, slime shouldn't define it's own next-single-char-property-change. Well, except that it returns NIL and not point-max if there is no property change.
Ray
Raymond Toy wrote:
Oops. I just noticed that xemacs 21.5.20 has it's own next-single-char-property-change. And this one actually works, when I remove the definitions for them in slime.el.
FWIW, here's what I did. Patch available, but it will almost surely break on other versions of xemacs/emacs.
I renamed next-single-char-property-change to be slime-next-single-char-property-change. Then I used the following definitions for xemacs. (Could conditionalize this to use these if it's xemacs and next-single-char-property-change is already defined. Otherwise, use the old definitions.)
(defun slime-next-single-char-property-change (&rest args) (or (apply 'next-single-char-property-change args) (point-max))) (defun slime-previous-single-char-property-change (&rest args) (or (apply 'previous-single-char-property-change args) (point-min)))
Ray
Raymond Toy raymond.toy@ericsson.com writes:
(Could conditionalize this to use these ifit's xemacs and next-single-char-property-change is already defined. Otherwise, use the old definitions.)
I did that now and it seems to work with XEmacs 21.4.17. Could you try it with your setup?
Helmut Eller wrote:
Raymond Toy raymond.toy@ericsson.com writes:
(Could conditionalize this to use these ifit's xemacs and next-single-char-property-change is already defined. Otherwise, use the old definitions.)
I did that now and it seems to work with XEmacs 21.4.17. Could you try it with your setup?
This works very nicely for me. Now, why didn't I think of that?
Thanks!
Ray
Helmut Eller wrote:
slime-find-next-note is the relevant function, but it wasn't changed since a long time. slime-remove-old-overlays was changed recently, but it is hard to see how that could influence M-n/M-p. Also have look at the *slime-events* buffer to see what the actual filename is: search for swank:compiler-notes-for-emacs.
I've looked into this a bit more, finally. I stepped through slime-find-next-note and friends and what I see is that in slime-find-note, funcall of next-candicate-fn returns a value pointing to the end of the buffer. Hence, no more notes.
next-candidate-fn is next-single-char-property-change so perhaps the overlay changes are causing this failure.
I'll poke around some more.
Ray
-
Brian Downing -
Helmut Eller -
Raymond Toy -
Raymond Toy