I finally got back to trying the latest slime (today's CVS) with xemacs and cmucl today.
One long standing bug is that xemacs' goto-char doesn't like nil. This shows up with C-x C-k and there are no warnings or errors. I get an error about nil not being an integer or marker. It comes from slime-find-note, in the loop that runs (goto-char (funcall next-candidate-fn (point) 'slime-note). I changed that so goto-char isn't called if funcall returns nil. This gets rid of the warning.
I also noticed that slime-autodoc makes post-command-hook a buffer-local hook. It might be a bug in xemacs but the post-command-hook becomes (slime-post-command-hook t). I think that "t" causes problems. Manually removing it makes it work much better.
However, my default post-command-hook value is '(paren-highlight), so when it's made buffer-local, I lose the paren-highlighting. This used to work fine with slime from 2008-11-23 or so.
Is there something I can do to make paren-highlight still used? I really miss the paren highlighting.
Thanks,
Ray
* Raymond Toy [2009-08-14 03:27+0200] writes:
One long standing bug is that xemacs' goto-char doesn't like nil. This shows up with C-x C-k and there are no warnings or errors. I get an error about nil not being an integer or marker. It comes from slime-find-note, in the loop that runs (goto-char (funcall next-candidate-fn (point) 'slime-note). I changed that so goto-char isn't called if funcall returns nil. This gets rid of the warning.
goto-char wouldn't work with nil in Emacs either. It could be that our emulation for next-single-char-property-change returns nil but judging from the code that doesn't seem possible. Can you give a recipe to reproduce the bug? C-c C-k without warnings seems to work here.
[There is some problem with M-n/M-p because XEmacs seems to forget to sync buffer point and window point when temporarily selecting a different window.]
I also noticed that slime-autodoc makes post-command-hook a buffer-local hook. It might be a bug in xemacs but the post-command-hook becomes (slime-post-command-hook t). I think that "t" causes problems. Manually removing it makes it work much better.
However, my default post-command-hook value is '(paren-highlight), so when it's made buffer-local, I lose the paren-highlighting. This used to work fine with slime from 2008-11-23 or so.
Is there something I can do to make paren-highlight still used? I really miss the paren highlighting.
Does slime-autodoc anything sensible in XEmacs? Here in XEmacs 21.4 it only prints messages about Elisp functions.
Helmut
Helmut Eller wrote:
- Raymond Toy [2009-08-14 03:27+0200] writes:
One long standing bug is that xemacs' goto-char doesn't like nil. This shows up with C-x C-k and there are no warnings or errors. I get an error about nil not being an integer or marker. It comes from slime-find-note, in the loop that runs (goto-char (funcall next-candidate-fn (point) 'slime-note). I changed that so goto-char isn't called if funcall returns nil. This gets rid of the warning.
goto-char wouldn't work with nil in Emacs either. It could be that our emulation for next-single-char-property-change returns nil but judging from the code that doesn't seem possible. Can you give a recipe to reproduce the bug? C-c C-k without warnings seems to work here.
I'll take a look at next-single-char-property-change. And I'm currently using xemacs 21.5.29.
Here is one example where C-c C-k causes an error. Just put this defun into a file, load it up and C-c C-k.
(defun load-or-compile (path) (unless (load (compile-file-pathname path) :if-does-not-exist nil) (compile-file path :load t)))
[There is some problem with M-n/M-p because XEmacs seems to forget to sync buffer point and window point when temporarily selecting a different window.]
I also noticed that slime-autodoc makes post-command-hook a buffer-local hook. It might be a bug in xemacs but the post-command-hook becomes (slime-post-command-hook t). I think that "t" causes problems. Manually removing it makes it work much better.
I'm sorry, but my analysis was not complete. With slime 2008-12-11, the post-command-hook contains t (but no slime-post-command-hook). This works fine.
with current slime, however, there must be some other problem. What I see is when I do C-x C-f and take too long, I get an error about (natnump t). The backtrace says something about an internal error and XEmacs bug? or something.
However, my default post-command-hook value is '(paren-highlight), so when it's made buffer-local, I lose the paren-highlighting. This used to work fine with slime from 2008-11-23 or so.
Is there something I can do to make paren-highlight still used? I really miss the paren highlighting.
Does slime-autodoc anything sensible in XEmacs? Here in XEmacs 21.4 it only prints messages about Elisp functions.
You're right. I thought it was working, but, in fact, it prints messages about Elisp functions.
The slime typeout window, however, does print the correct thing. It's kind of funny. If I type "(push " in the repl, the minibuffer gives the elisp definition, but the typeout window has the Lisp (cmucl) definition.
I'll have to poke around some more....
Ray
Raymond Toy wrote:
Helmut Eller wrote:
- Raymond Toy [2009-08-14 03:27+0200] writes:
One long standing bug is that xemacs' goto-char doesn't like nil. This shows up with C-x C-k and there are no warnings or errors. I get an error about nil not being an integer or marker. It comes from slime-find-note, in the loop that runs (goto-char (funcall next-candidate-fn (point) 'slime-note). I changed that so goto-char isn't called if funcall returns nil. This gets rid of the warning.
goto-char wouldn't work with nil in Emacs either. It could be that our emulation for next-single-char-property-change returns nil but judging from the code that doesn't seem possible. Can you give a recipe to reproduce the bug? C-c C-k without warnings seems to work here.
I'll take a look at next-single-char-property-change. And I'm currently using xemacs 21.5.29.
Not sure what the issue is, but if I just change slime-DEFUN-if-undefined to plain defun, then I don't get an error.
Perhaps a bug in xemacs in handling slime-DEFUN-if-undefined?
(Oh, if it matters, I don't compile any of the slime el files.)
Ray
Raymond Toy wrote:
Raymond Toy wrote:
Helmut Eller wrote:
- Raymond Toy [2009-08-14 03:27+0200] writes:
One long standing bug is that xemacs' goto-char doesn't like nil. This shows up with C-x C-k and there are no warnings or errors. I get an error about nil not being an integer or marker. It comes from slime-find-note, in the loop that runs (goto-char (funcall next-candidate-fn (point) 'slime-note). I changed that so goto-char isn't called if funcall returns nil. This gets rid of the warning.
goto-char wouldn't work with nil in Emacs either. It could be that our emulation for next-single-char-property-change returns nil but judging from the code that doesn't seem possible. Can you give a recipe to reproduce the bug? C-c C-k without warnings seems to work here.
I'll take a look at next-single-char-property-change. And I'm currently using xemacs 21.5.29.
Not sure what the issue is, but if I just change slime-DEFUN-if-undefined to plain defun, then I don't get an error.
Perhaps a bug in xemacs in handling slime-DEFUN-if-undefined?
Or because xemacs already has the function so slime-DEFUN-if-undefined does nothing.
The docstring says it returns NIL if the property is constant all the way to the end of the object.
I hacked slime-find-note to say (goto-char (or (funcall ...) (point-max)) and that makes things work.
And the problem with post-command-hook appears to be a bug in xemacs' fsf compatibility function for timer-set-idle-time. It was calling set-itimer-restart with a second arg of t instead of the number secs.
So it looks like things are working now, except eldoc displays the elisp function info, but slime typeout displays the correct thing.
Sorry for all trouble and messages.
Ray
* Raymond Toy [2009-08-15 04:42+0200] writes:
I'll take a look at next-single-char-property-change. And I'm currently using xemacs 21.5.29.
I there an easy way to build XEmacs from source? I mean a way that doesn't require me to mess around with the f'ing package system and that makes the .el files accessible?
You're right. I thought it was working, but, in fact, it prints messages about Elisp functions.
The slime typeout window, however, does print the correct thing. It's kind of funny. If I type "(push " in the repl, the minibuffer gives the elisp definition, but the typeout window has the Lisp (cmucl) definition.
Space triggers the Slime command that displays the correct arglist. eldoc runs from a timer or post-command-hook.
I'll disable slime-autodoc for XEmacs as it is based and eldoc and the eldoc in XEmacs is from 2003 which doesn't have the hooks needed for slime-autodoc.
Helmut
Helmut Eller wrote:
- Raymond Toy [2009-08-15 04:42+0200] writes:
I'll take a look at next-single-char-property-change. And I'm currently using xemacs 21.5.29.
I there an easy way to build XEmacs from source? I mean a way that doesn't require me to mess around with the f'ing package system and that makes the .el files accessible?
I grab the source tarball, then grab the xemacs-sumo packages tarball and the xemacs-mule-sumo packages tarball (if you enable mule/unicode). Pick a directory where you want to install the xemacs binary, and extract the sumo tarballs in lib/xemacs. I never play around with the package system.
Are there no binaries for your platform?
You're right. I thought it was working, but, in fact, it prints messages about Elisp functions.
The slime typeout window, however, does print the correct thing. It's kind of funny. If I type "(push " in the repl, the minibuffer gives the elisp definition, but the typeout window has the Lisp (cmucl) definition.
Space triggers the Slime command that displays the correct arglist. eldoc runs from a timer or post-command-hook.
I'll disable slime-autodoc for XEmacs as it is based and eldoc and the eldoc in XEmacs is from 2003 which doesn't have the hooks needed for slime-autodoc.
Ok, but I hope that doesn't disable the display to slime-typeout. If it does, I'll sorely miss that feature.
However, I'll look into getting an updated eldoc into xemacs (or for myself, at least).
Ray
* Raymond Toy [2009-08-15 21:16+0200] writes:
Helmut Eller wrote:
I there an easy way to build XEmacs from source? I mean a way that doesn't require me to mess around with the f'ing package system and that makes the .el files accessible?
I grab the source tarball, then grab the xemacs-sumo packages tarball and the xemacs-mule-sumo packages tarball (if you enable mule/unicode). Pick a directory where you want to install the xemacs binary, and extract the sumo tarballs in lib/xemacs. I never play around with the package system.
The sumo tarballs don't contain the source, AFAICT.
Are there no binaries for your platform?
At least in Debian stable is only 21.4 (without source).
Don't you miss the source? In Emacs C-h f displays the source file as a clickable link and I couldn't live without that.
I'll disable slime-autodoc for XEmacs as it is based and eldoc and the eldoc in XEmacs is from 2003 which doesn't have the hooks needed for slime-autodoc.
Ok, but I hope that doesn't disable the display to slime-typeout. If it does, I'll sorely miss that feature.
No that doesn't disable slime-typeout. But yes, slime-autodoc would be one of the better uses for the typeout frame.
Helmut
Helmut Eller wrote:
- Raymond Toy [2009-08-15 21:16+0200] writes:
Helmut Eller wrote:
I there an easy way to build XEmacs from source? I mean a way that doesn't require me to mess around with the f'ing package system and that makes the .el files accessible?
I grab the source tarball, then grab the xemacs-sumo packages tarball and the xemacs-mule-sumo packages tarball (if you enable mule/unicode). Pick a directory where you want to install the xemacs binary, and extract the sumo tarballs in lib/xemacs. I never play around with the package system.
The sumo tarballs don't contain the source, AFAICT.
That's odd. My xemacs-sumo-2007-04-27.tar.bz2 contains source. I didn't check everything, but for every elc I checked, I have an el file.
I'll disable slime-autodoc for XEmacs as it is based and eldoc and the eldoc in XEmacs is from 2003 which doesn't have the hooks needed for slime-autodoc.
Ok, but I hope that doesn't disable the display to slime-typeout. If it does, I'll sorely miss that feature.
No that doesn't disable slime-typeout. But yes, slime-autodoc would be one of the better uses for the typeout frame.
Oh, that's cool then.
I did try the latest eldoc from emacs 22.3. With a few tweaks, it seems to work with xemacs. But I haven't really tried it with slime yet.
Ray
Raymond Toy wrote:
I did try the latest eldoc from emacs 22.3. With a few tweaks, it seems to work with xemacs. But I haven't really tried it with slime yet.
Oops. I meant emacs 23. This version of eldoc can't be used with xemacs because xemacs is not GPLv3. But I think emacs 22 can be used, and I tried it with xemacs. One minor tweak seems to allow it to work with xemacs, and I tried it with slime. Slime autodoc appears to work now and the minibuffer shows the Lisp definition of functions instead of the elisp definition.
Cool.
Ray
-
Helmut Eller -
Raymond Toy