Hot from the ChangeLog:
2003-11-03 Luke Gorrie luke@bluetail.com
* slime.el (slime-display-buffer-region): Hacked to fix completely inexplicable XEmacs problems.
Thank you! I was about to ask whether SLIME is expected to work with XEmacs. I guess the question still stands -- should I report problems encountered with XEmacs, or is it a known fact that it acts, well, strange?
--J.
Jan Rychter jan@rychter.com writes:
Hot from the ChangeLog:
2003-11-03 Luke Gorrie luke@bluetail.com
- slime.el (slime-display-buffer-region): Hacked to fix completely
inexplicable XEmacs problems.
Thank you! I was about to ask whether SLIME is expected to work with XEmacs. I guess the question still stands -- should I report problems encountered with XEmacs, or is it a known fact that it acts, well, strange?
You're welcome :-). Definitely we're supposed to be XEmacs compatible. In practice it's not always quite right, because primarily I use GNU 21 and Helmut uses GNU 20. So, by all means, please report XEmacs problems to the list and we'll fix 'em up.
-Luke
"Luke" == Luke Gorrie luke@bluetail.com:
Luke> Jan Rychter jan@rychter.com writes:
Hot from the ChangeLog:
2003-11-03 Luke Gorrie luke@bluetail.com
- slime.el (slime-display-buffer-region): Hacked to fix completely
inexplicable XEmacs problems.
Thank you! I was about to ask whether SLIME is expected to work with XEmacs. I guess the question still stands -- should I report problems encountered with XEmacs, or is it a known fact that it acts, well, strange?
Luke> You're welcome :-). Definitely we're supposed to be XEmacs Luke> compatible. In practice it's not always quite right, because Luke> primarily I use GNU 21 and Helmut uses GNU 20. So, by all means, Luke> please report XEmacs problems to the list and we'll fix 'em up.
Ok -- first of all, it seems that after the latest commits XEmacs started working quite well. Many thanks for that. There are some people (like me) who do use XEmacs and intend to continue using it :-)
I've found one minor nit -- in my XEmacs when walking the compiler notes with M-n and M-p, the currently highlighted expression has its font changed to a smaller one. That results in fairly annoying behavior. The font only changes in the currently highlighted expression, it doesn't change before I press M-n to go to the first compiler note, and it changes back to normal after I stop walking the notes or after I switch to the next one.
Also, there is another problem which I've stumbled upon -- SLIME seems to have problems interpreting warnings related to the SERIES package (tested using CMUCL). It does notice that there is a problem (and highlights corresponding expressions correctly), but doesn't display any notes for it.
Here's a closer description of what SLIME sees, stolen from the *slime-events* buffer:
(:read-output "Warning 28 in series expression:\n") (:read-output "(SERIES:COLLECT-FN 'FLOAT\n") (:read-output " (CONSTANTLY 0.0)\n") (:read-output " (LAMBDA (V1 V2) (+ V1 (SIGNUM V2)))\n") (:read-output " RETURNS)\n") (:read-output "Non-series to series data flow from:\n") (:read-output "RETURNS\n") (:read-output "to:\n") (:read-output "(SERIES:COLLECT-FN 'FLOAT\n") (:read-output " (CONSTANTLY 0.0)\n") (:read-output " (LAMBDA (V1 V2) (+ V1 (SIGNUM V2)))\n") (:read-output " RETURNS)\n") (:read-output "\n") (:read-output "; \n") (:read-output "; \n")
I hope this helps...
--J.
Jan Rychter jan@rychter.com writes:
I've found one minor nit -- in my XEmacs when walking the compiler notes with M-n and M-p, the currently highlighted expression has its font changed to a smaller one. That results in fairly annoying behavior. The font only changes in the currently highlighted expression, it doesn't change before I press M-n to go to the first compiler note, and it changes back to normal after I stop walking the notes or after I switch to the next one.
As a workaround you could customize the slime-highlight-face and set its font to the default size. By default slime-highlight-face should look almost like your normal highlight face. Is the font of your normal highlight face also smaller? (Use list-faces-display to see all faces.)
Also, there is another problem which I've stumbled upon -- SLIME seems to have problems interpreting warnings related to the SERIES package (tested using CMUCL). It does notice that there is a problem (and highlights corresponding expressions correctly), but doesn't display any notes for it.
Hmm... it seems that these warnings are generated by the SERIES package and not by the compiler. I guess we should bind a handler for such warnings too. I'll look at that.
--helmut.
"Helmut" == Helmut Eller e9626484@stud3.tuwien.ac.at writes:
Helmut> Jan Rychter jan@rychter.com writes:
I've found one minor nit -- in my XEmacs when walking the compiler notes with M-n and M-p, the currently highlighted expression has its font changed to a smaller one. That results in fairly annoying behavior. The font only changes in the currently highlighted expression, it doesn't change before I press M-n to go to the first compiler note, and it changes back to normal after I stop walking the notes or after I switch to the next one.
Helmut> As a workaround you could customize the slime-highlight-face Helmut> and set its font to the default size. By default Helmut> slime-highlight-face should look almost like your normal Helmut> highlight face. Is the font of your normal highlight face also Helmut> smaller? (Use list-faces-display to see all faces.)
If you mean the "highlight" face, it's not. That one looks normal. Only slime-highlight-face is smaller.
Here's how they are defined:
highlight black darkseagreen2 -*-courier-medium-r-*-*-*-140-*-*-*-*-iso8859-* (Highlight face.)
slime-highlight-face black darkseagreen2 -*-courier-medium-r-*-*-*-120-*-*-*-*-iso8859-* (Face for compiler notes while selected.)
The bug seems to be that when defining slime faces, the size does not get copied.
Having looked at slime.el -- why not just use copy-face instead of defface when running under XEmacs? That does copy all font attributes in my XEmacs. Alas, it doesn't seem to exist in GNU Emacs.
--J.
Jan Rychter jan@rychter.com writes:
The bug seems to be that when defining slime faces, the size does not get copied.
I assumed that if you don't specify the size, Emacs will take a sensible default. But apparently that's not the case.
Having looked at slime.el -- why not just use copy-face instead of defface when running under XEmacs? That does copy all font attributes in my XEmacs. Alas, it doesn't seem to exist in GNU Emacs.
The (potentially) nice thing about defface is, that it is integrated with Emacs' customization machinery. So users can customize faces defined with defface in the customize menu and can save their settings.
Apparently the face copying stuff wasn't a good idea. I removed that and hardcoded the colors for slime-highlight-face. The size should be whatever is the default size is for your faces. If people don't like my colors, they can still customize them.
The problem with SERIES is that the compiler condition actually contains a message, but has length zero. The SERIES package prints the warning itself to *standard-output* and uses (warn "") to inform the compiler. I changed the slime code a bit, so you see at least 2 double quotes ("") in the echo area if the message is empty.
Helmut.
Helmut Eller wrote:
The problem with SERIES is that the compiler condition actually contains a message, but has length zero. The SERIES package prints the warning itself to *standard-output* and uses (warn "") to inform the compiler. I changed the slime code a bit, so you see at least 2 double quotes ("") in the echo area if the message is empty.
Would it be better if the message wasn't zero-length? I can look into changing that if it makes slime work better, and if the messages still make sense.
Ray
Raymond Toy rtoy@earthlink.net writes:
Helmut Eller wrote:
The problem with SERIES is that the compiler condition actually contains a message, but has length zero. The SERIES package prints the warning itself to *standard-output* and uses (warn "") to inform the compiler. I changed the slime code a bit, so you see at least 2 double quotes ("") in the echo area if the message is empty.
Would it be better if the message wasn't zero-length? I can look into changing that if it makes slime work better, and if the messages still make sense.
Is there a reason why series is emitting /warnings/ by emitting text to *standard-output* (why not *error-output*?) and then calling WARN with an empty string? It feels like a workaround for a long-dead bug somewhere.
Christophe
Christophe Rhodes wrote:
Is there a reason why series is emitting /warnings/ by emitting text to *standard-output* (why not *error-output*?) and then calling WARN with an empty string? It feels like a workaround for a long-dead bug somewhere.
History? That's the way it came, and I've never bothered with it.
Ray
Christophe Rhodes csr21@cam.ac.uk writes:
Raymond Toy rtoy@earthlink.net writes:
Would it be better if the message wasn't zero-length? I can look into changing that if it makes slime work better, and if the messages still make sense.
That would definitely be better. It should be enough to pass the message to WARN or ERROR and slime will pick it up and place an annotation somewhere near the macro call.
Is there a reason why series is emitting /warnings/ by emitting text to *standard-output* (why not *error-output*?) and then calling WARN with an empty string? It feels like a workaround for a long-dead bug somewhere.
Ups, it is actually *error-output*. But that's the same from a slime perspective.
Helmut.
"Helmut" == Helmut Eller e9626484@stud3.tuwien.ac.at:
Helmut> Christophe Rhodes csr21@cam.ac.uk writes:
Raymond Toy rtoy@earthlink.net writes:
Would it be better if the message wasn't zero-length? I can look into changing that if it makes slime work better, and if the messages still make sense.
Helmut> That would definitely be better. It should be enough to pass Helmut> the message to WARN or ERROR and slime will pick it up and Helmut> place an annotation somewhere near the macro call.
Well, SERIES warnings are rather important -- miss one and your code will probably be incorrect. Perhaps this should this be fixed in SERIES, then?
I'm afraid someone more knowledgeable than me would have to do it.
--J.
"Helmut" == Helmut Eller e9626484@stud3.tuwien.ac.at:
[...] Helmut> Apparently the face copying stuff wasn't a good idea. I Helmut> removed that and hardcoded the colors for slime-highlight-face. Helmut> The size should be whatever is the default size is for your Helmut> faces. If people don't like my colors, they can still Helmut> customize them.
This seems to work quite well -- I have no face problems with the current version. Thanks!
There is one more thing: I often get the message:
(11) (error/warning) Error in `post-command-hook' (setting hook to nil) (cl-assertion-failed slime-mode)
which comes from:
Signaling: (cl-assertion-failed slime-mode) signal(cl-assertion-failed (slime-mode)) (or slime-mode (signal (quote cl-assertion-failed) (list ...))) (progn (or slime-mode (signal ... ...)) nil) (assert slime-mode) slime-autodoc-post-command-hook() slime-post-command-hook()
The simplest way to get this is to do M-x slime from a non-lisp buffer.
--J.
Jan Rychter jan@rychter.com writes:
There is one more thing: I often get the message:
(11) (error/warning) Error in `post-command-hook' (setting hook to nil) (cl-assertion-failed slime-mode)
I think I've fixed this, but wasn't reproducing it 100% reliably so I'm not certain. Can you give it a try from CVS?
-Luke
"Luke" == Luke Gorrie luke@bluetail.com:
Luke> Jan Rychter jan@rychter.com writes:
There is one more thing: I often get the message:
(11) (error/warning) Error in `post-command-hook' (setting hook to nil) (cl-assertion-failed slime-mode)
Luke> I think I've fixed this, but wasn't reproducing it 100% reliably Luke> so I'm not certain. Can you give it a try from CVS?
Indeed you have. I can't bring the message up anymore. Nice!
--J.
-
Christophe Rhodes -
Helmut Eller -
Jan Rychter -
Luke Gorrie -
Raymond Toy