[slime-devel] slime-typeout-frame vs autodoc timers
I finally upgraded to a recent version of slime (2009-07-01 or so) and found a couple of issues. First, I use slime-typeout-frame and it references slime-autodoc-start-timer (and other autodoc stuff). These don't seem to exist anymore. Second, I get the following error using xemacs 21.5.29. These issues prevent me from using the current version. And many thanks for making slime soooo useful, Ray Slime error: (slime,warning/warning) "s-code.lisp":8753:19 (pt=331319). Caught error during fontification while searching for forms that are suppressed by reader-conditionals. The error was: (cl-assertion-failed (<= (point) limit)). This is a bug in Slime itself. Please report this to the mailinglist slime-devel@common-lisp.net and include your Emacs version, the guilty Lisp source file, the header of this message, and the following backtrace. Backtrace: backtrace() (let ((standard-output standard-output)) (backtrace)) (let ((standard-output ...)) (let (...) (backtrace)) (with-current-buffer standard-output (prog1 ... ...))) (with-output-to-string (backtrace)) (slime-display-warning "%S:%d:%d (pt=%d).\n%s\n\nThis is a bug in Slime itself. Please report this to the\nmailinglist slime-devel@common-lisp.net and include your Emacs\nversion, the guilty Lisp source file, the header of this\nmessage, and the following backtrace.\n\nBacktrace:\n%s\n--------------------------------------------------------------\n" (buffer-name) (line-number-at-pos) (current-column) (point) (apply (function format) message args) (with-output-to-string (backtrace))) slime-bug("Caught error during fontification while searching for forms\nthat are suppressed by reader-conditionals. The error was: %S." (cl-assertion-failed (<= (point) limit))) byte-code("..." [condition result nil slime-bug "Caught error during fontification while searching for forms\nthat are suppressed by reader-conditionals. The error was: %S."] 3) slime-search-suppressed-forms(331141) font-lock-fontify-keywords-region(330036 331141 nil) font-lock-default-fontify-region(330036 331141 nil) font-lock-fontify-region(330036 331141) lazy-shot-fontify-internal(#<buffer "s-code.lisp"> 330036 331064 t "stealthy ") lazy-shot-lock-extent(#<destroyed extent> t) lazy-shot-stealth-lock(#<buffer "s-code.lisp">) apply(lazy-shot-stealth-lock #<buffer "s-code.lisp">) byte-code("..." [this-command inhibit-quit quit-flag match-data itimer current-itimer match-data ((store-match-data match-data)) nil itimer-uses-arguments apply itimer-function itimer-function-arguments last-event-time next-wakeup itimers time-elapsed] 5) itimer-run-expired-timers(0.001288) itimer-timer-driver(nil) ("execute_internal_event()" "[internal]") (dispatch-event "[internal]")
Raymond Toy <toy.raymond@gmail.com> writes:
I finally upgraded to a recent version of slime (2009-07-01 or so) and found a couple of issues.
First, I use slime-typeout-frame and it references slime-autodoc-start-timer (and other autodoc stuff). These don't seem to exist anymore.
Slime's Autodoc was rewritten to reuse Emacs' Eldoc. Unfortunately the latter does not provide any hook into how it displays its messages. If I send a patch to (X)Emacs upstream, and, let's say, it'll be applied, will you go and grab XEmacs CVS version?
Second, I get the following error using xemacs 21.5.29.
The same problem was reported by Stelian Ionescu yesterday. I'll look into it. -T.
Tobias C. Rittweiler wrote:
Raymond Toy <toy.raymond@gmail.com> writes:
I finally upgraded to a recent version of slime (2009-07-01 or so) and found a couple of issues.
First, I use slime-typeout-frame and it references slime-autodoc-start-timer (and other autodoc stuff). These don't seem to exist anymore.
Slime's Autodoc was rewritten to reuse Emacs' Eldoc. Unfortunately the latter does not provide any hook into how it displays its messages.
If I send a patch to (X)Emacs upstream, and, let's say, it'll be applied, will you go and grab XEmacs CVS version?
That's not a problem. I do that once in a while too, just like I upgrade slime once in a while. :-) Ray
Tobias C. Rittweiler wrote:
Raymond Toy <toy.raymond@gmail.com> writes:
I finally upgraded to a recent version of slime (2009-07-01 or so) and found a couple of issues.
First, I use slime-typeout-frame and it references slime-autodoc-start-timer (and other autodoc stuff). These don't seem to exist anymore.
Slime's Autodoc was rewritten to reuse Emacs' Eldoc. Unfortunately the latter does not provide any hook into how it displays its messages.
If I send a patch to (X)Emacs upstream, and, let's say, it'll be applied, will you go and grab XEmacs CVS version?
I finally got around to looking at this again. I have the same issue with today's CVS code, but I just commented out the calls to slime-autodoc-start-timer and slime-autodoc-stop-timer. This makes things work much better. There are other issues, but I'll put that in another message. Ray
* Raymond Toy [2009-07-03 04:09+0200] writes:
Second, I get the following error using xemacs 21.5.29.
Would switching to Emacs bother you a lot? For several years now, XEmacs is falling back behind Emacs and it seems to me that it only gets worse: XEmacs essentially has to implement the features that Emacs adds (in a bug compatible way). This gets rather boring and apparently the XEmacs project is running out of man power. In many aspects, the newest XEmacs is still where Emacs20 was. Emacs21 was released in 2001 and it seems about time to drop support for it. I'm also inclined to drop support for XEmacs. Helmut
On 2009-07-03 18:27 +0100, Helmut Eller wrote:
In many aspects, the newest XEmacs is still where Emacs20 was. Emacs21 was released in 2001 and it seems about time to drop support for it. I'm also inclined to drop support for XEmacs.
BTW, Emacs 23 is coming soon. ,----[ Yidong Chong ] | Next Wednesday, July 8, I will make the 23.0.96 pretest from the | EMACS_23_1_RC branch. Unless unexpected serious issues come to light, | this will be the final pretest; the 23.1 release will be made two weeks | afterwards, on July 29. `---- -- Emacs uptime: 3 hours, 6 minutes, 47 seconds
On Fri, Jul 3, 2009 at 10:27 AM, Helmut Eller <heller@common-lisp.net>wrote:
* Raymond Toy [2009-07-03 04:09+0200] writes:
Second, I get the following error using xemacs 21.5.29.
Would switching to Emacs bother you a lot?
It would bother me a lot. I don't care that much about new features. If you drop support for XEmacs, please at least keep around the last SLIME version that supports it, clearly marked and easy to find. -- Scott
Helmut Eller wrote:
* Raymond Toy [2009-07-03 04:09+0200] writes:
Second, I get the following error using xemacs 21.5.29.
Would switching to Emacs bother you a lot?
Well xemacs does everything I want, and I have decades (!?!?) of random configurations to make it work the way I want. I suppose they should be garbage collected sometime, but I'm just too old and lazy.
I'm also inclined to drop support for XEmacs.
I'll be disappointed, but that's life. Ray
Helmut Eller wrote:
* Raymond Toy [2009-07-03 04:09+0200] writes:
Second, I get the following error using xemacs 21.5.29.
Would switching to Emacs bother you a lot?
I too would be disappointed if XEmacs support were dropped. I've tried switching to gnu-emacs several times in the last 5 year, and invariably come crawling back to XEmacs, usually after spending fruitless hours trying to get fonts and other visual features to look acceptable in gnu-emacs (Linux). Have tried running both on the same system: bad mistake. But... very valid points about the time-consuming tedium of maintaining SLIME for the two divergent emacsen. I have several persistent problems with SLIME that seem to only afflict XEmacs, and I suspect there are more important goals for SLIME development. Overall, the desire for a stable and reliable SLIME outweighs my preference for XEmacs, so I'm willing to switch. Maybe there is a recovery group for XEmacs users? ~ farlies
On Sat, 04 Jul 2009 10:58:59 -0500 farlies <farlies@gmail.com> wrote:
I've tried switching to gnu-emacs several times in the last 5 year, and invariably come crawling back to XEmacs, usually after spending fruitless hours trying to get fonts and other visual features to look acceptable in gnu-emacs (Linux). Have tried running both on the same system: bad mistake.
Was this with the x11 option? If so, it's probably worthwile experimenting in console with a fancy terminal like gnome-terminal and antialiased ttf fonts like Bitstream Vera Sans Mono (even xterm does pretty well with ttf DejaVu Sans Mono and utf-8 nowadays). Of course, this is independent of fontification settings, however. I've never used its X11 mode personally but some screenshots suggest it is very crude. An example of a session in utf-8 xterm with DejaVu Sans Mono truetype font, customized colors in ~/.Xdefaults and minimal fontification modification (a script helps to make parens less visible) is at http://mmondor.pulsar-zone.net/img_gallery/screenshots/lisp-iolib-test5.png Thanks, -- Matt
On 2009-07-04 16:58 +0100, farlies wrote:
I've tried switching to gnu-emacs several times in the last 5 year, and invariably come crawling back to XEmacs, usually after spending fruitless hours trying to get fonts and other visual features to look acceptable in gnu-emacs (Linux). Have tried running both on the same system: bad mistake.
It might be worthwhile to look again when Emacs 23 comes out on 29 July. Then it will have proper unicode support (or mule 6.0, none of the other variants has this), xft font etc. Generally there are lots of people on gmane.emacs.help (including Emacs developers) that can help out. It is sad that XEmacs does not have enough man power. Otherwise a healthy competition is always good for both projects. -- Emacs uptime: 1 day, 1 hour, 23 minutes, 53 seconds
Raymond Toy <toy.raymond@gmail.com> writes:
Slime error:
(slime,warning/warning) "s-code.lisp":8753:19 (pt=331319). Caught error during fontification while searching for forms that are suppressed by reader-conditionals. The error was: (cl-assertion-failed (<= (point) limit)).
That should be fixed now. -T.
participants (7)
-
farlies -
Helmut Eller -
Leo -
Matthew Mondor -
Raymond Toy -
Scott L. Burson -
Tobias C. Rittweiler