for those of you who don't follow c.l.l (which is probaly a good idea) i commited William Bland's patch[1]. see the ChangeLog for details.
1 - http://groups.google.com/group/comp.lang.lisp/browse_thread/thread/e1d0b7bf0...
This is cool, but it would be even cooler if it could store a list of all changes since last compile. That way, I could say "M-x slime-show-diffs" or some equivalent, and get something like a grep buffer of all changes, with the overlays turned on.
Anybody else think so? I'm going to start something like this, but I'm at work right now, and my elisp is weak, so I don't know how long it will take.
Marco Baringer writes:
for those of you who don't follow c.l.l (which is probaly a good idea) i commited William Bland's patch[1]. see the ChangeLog for details.
Yeah, that's pretty cool, but there are two major annoyances with it: * It tries to do it's thing even in the REPL. This seems insane; you only want to do this in source files, IMHO
* It incessantly nags you by displaying "Setting up face" in the echo area. If I've turned on this feature, I can SEE that it's highlighting, I don't really need it to TELL me as well. ;-)
* the default color of the overlay, "yellow", is pretty awful on a "dark" background (I use color-mode-robin-hood, if you want to see what that's like). I notice that both dark and light are currently set to yellow, so maybe you guys just haven't made up your mind yet. I set the face of SLIME-DISPLAY-EDIT-FACE to "sienna", in my setup. YMMV.
* If you can detect that the minor mode highlight-changes-mode is active, you might be better off simply using the faces used therein; (which are highlight-changes-1 highlight-changes-2 etc.)
Great work, guys!
--ap
Alain.Picard@memetrics.com writes:
Marco Baringer writes:
for those of you who don't follow c.l.l (which is probaly a good idea) i commited William Bland's patch[1]. see the ChangeLog for details.
Yeah, that's pretty cool, but there are two major annoyances with it:
- It tries to do it's thing even in the REPL. This seems insane; you only want to do this in source files, IMHO
nikodemus fixed this yesterday..
- It incessantly nags you by displaying "Setting up face" in the echo area. If I've turned on this feature, I can SEE that it's highlighting, I don't really need it to TELL me as well. ;-)
i don't see this.
- the default color of the overlay, "yellow", is pretty awful on a "dark" background (I use color-mode-robin-hood, if you want to see what that's like). I notice that both dark and light are currently set to yellow, so maybe you guys just haven't made up your mind yet. I set the face of SLIME-DISPLAY-EDIT-FACE to "sienna", in my setup. YMMV.
personally i use gray30 :), but i understand your point.
- If you can detect that the minor mode highlight-changes-mode is active, you might be better off simply using the faces used therein; (which are highlight-changes-1 highlight-changes-2 etc.)
good idea.
"Marco Baringer" mb@bese.it writes:
Alain.Picard@memetrics.com writes:
Marco Baringer writes:
for those of you who don't follow c.l.l (which is probaly a good idea) i commited William Bland's patch[1]. see the ChangeLog for details.
Yeah, that's pretty cool, but there are two major annoyances with it:
- It tries to do it's thing even in the REPL. This seems insane; you only want to do this in source files, IMHO
nikodemus fixed this yesterday..
Hmmm. I see his entry in the ChangeLog but I still get the highlighting in the REPL.
-Peter
Peter Seibel peter@gigamonkeys.com writes:
"Marco Baringer" mb@bese.it writes:
Alain.Picard@memetrics.com writes:
Marco Baringer writes:
for those of you who don't follow c.l.l (which is probaly a good idea) i commited William Bland's patch[1]. see the ChangeLog for details.
Yeah, that's pretty cool, but there are two major annoyances with it:
- It tries to do it's thing even in the REPL. This seems insane; you only want to do this in source files, IMHO
nikodemus fixed this yesterday..
Hmmm. I see his entry in the ChangeLog but I still get the highlighting in the REPL.
Meanwhile, here's a patch to turn off hilighting when in a comment.
-Peter
Index: ChangeLog =================================================================== RCS file: /project/slime/cvsroot/slime/ChangeLog,v retrieving revision 1.821 diff -u -r1.821 ChangeLog --- ChangeLog 18 Dec 2005 17:24:36 -0000 1.821 +++ ChangeLog 19 Dec 2005 23:29:56 -0000 @@ -1,3 +1,8 @@ +2005-12-19 Peter Seibel peter@gigamonkeys.com + + * slime.el (slime-self-insert-command): Got rid of message about + setting up face and skipping edit-hilights when in a comment. + 2005-12-18 Nikodemus Siivola nikodemus@random-state.net
* slime.el (slime-mode-hook): Bind simple characters to Index: slime.el =================================================================== RCS file: /project/slime/cvsroot/slime/slime.el,v retrieving revision 1.571 diff -u -r1.571 slime.el --- slime.el 18 Dec 2005 17:24:36 -0000 1.571 +++ slime.el 19 Dec 2005 23:30:05 -0000 @@ -9888,8 +9888,9 @@ (defun slime-self-insert-command () (interactive) (self-insert-command 1) - (when (and slime-display-edit-hilights (slime-connected-p)) - (message "Setting up face.") + (when (and slime-display-edit-hilights + (slime-connected-p) + (not (member 'font-lock-comment-face (text-properties-at (point))))) (let ((overlay (make-overlay (- (point) 1) (point)))) (flet ((putp (name value) (overlay-put overlay name value))) (putp 'face 'slime-display-edit-face)
Peter Seibel peter@gigamonkeys.com writes:
Peter Seibel peter@gigamonkeys.com writes:
"Marco Baringer" mb@bese.it writes:
Alain.Picard@memetrics.com writes:
Marco Baringer writes:
for those of you who don't follow c.l.l (which is probaly a good idea) i commited William Bland's patch[1]. see the ChangeLog for details.
Yeah, that's pretty cool, but there are two major annoyances with it:
- It tries to do it's thing even in the REPL. This seems insane; you only want to do this in source files, IMHO
nikodemus fixed this yesterday..
Hmmm. I see his entry in the ChangeLog but I still get the highlighting in the REPL.
Meanwhile, here's a patch to turn off hilighting when in a comment.
And here's a potentially better one, thanks to kreuter on #lisp. Only tested on CVS emacs.
-Peter
Index: ChangeLog =================================================================== RCS file: /project/slime/cvsroot/slime/ChangeLog,v retrieving revision 1.821 diff -u -r1.821 ChangeLog --- ChangeLog 18 Dec 2005 17:24:36 -0000 1.821 +++ ChangeLog 19 Dec 2005 23:46:04 -0000 @@ -1,3 +1,8 @@ +2005-12-19 Peter Seibel peter@gigamonkeys.com + + * slime.el (slime-self-insert-command): Got rid of message about + setting up face and skipping edit-hilights when in a comment. + 2005-12-18 Nikodemus Siivola nikodemus@random-state.net
* slime.el (slime-mode-hook): Bind simple characters to Index: slime.el =================================================================== RCS file: /project/slime/cvsroot/slime/slime.el,v retrieving revision 1.571 diff -u -r1.571 slime.el --- slime.el 18 Dec 2005 17:24:36 -0000 1.571 +++ slime.el 19 Dec 2005 23:46:14 -0000 @@ -9888,12 +9888,16 @@ (defun slime-self-insert-command () (interactive) (self-insert-command 1) - (when (and slime-display-edit-hilights (slime-connected-p)) - (message "Setting up face.") + (when (and slime-display-edit-hilights + (slime-connected-p) + (not (in-comment-p))) (let ((overlay (make-overlay (- (point) 1) (point)))) (flet ((putp (name value) (overlay-put overlay name value))) (putp 'face 'slime-display-edit-face) (putp 'slime-edit t))))) + +(defun in-comment-p () + (nth 4 (syntax-ppss (point))))
(add-hook 'slime-mode-hook (lambda ()
Peter Seibel peter@gigamonkeys.com writes:
"Marco Baringer" mb@bese.it writes:
Alain.Picard@memetrics.com writes:
Marco Baringer writes:
for those of you who don't follow c.l.l (which is probaly a good idea) i commited William Bland's patch[1]. see the ChangeLog for details.
Yeah, that's pretty cool, but there are two major annoyances with it:
- It tries to do it's thing even in the REPL. This seems insane; you only want to do this in source files, IMHO
nikodemus fixed this yesterday..
Hmmm. I see his entry in the ChangeLog but I still get the highlighting in the REPL.
Okay, one more restart of Emacs fixed it. I'm not sure why but don't really care.
-Peter
Hi,
Von: Peter Seibel peter@gigamonkeys.com
"Marco Baringer" mb@bese.it writes:
nikodemus fixed this yesterday..
Hmmm. I see his entry in the ChangeLog but I still get the highlighting in the REPL.
I think a problem that occurred this morning after updateting slime is connected to this. I found a log message from Marco stating:
Got rid of message about setting up face and skipping edit-hilights when in a comment.
In the CVS mail archives. I think for that you introduced the defun in-comment-p. First of all I think it should be renamed to slime-in-comment-p and second it doesn't work on my XEmacs which has no syntax-ppss-function.
I tried to come up with a portable solution but I know too little of syntax-tables and a little web research on the origins of syntax-ppss yielded no result for me other than that I can't find it even in the source of xemacs-21.5.24.
For todays work I will remove the in-comment-p call in self-insert-function and I hope for some help of you guys.
Thanks and regards, Stefan Kamphausen
"Stefan Kamphausen" skampi@gmx.net writes:
Hi,
Von: Peter Seibel peter@gigamonkeys.com
"Marco Baringer" mb@bese.it writes:
nikodemus fixed this yesterday..
Hmmm. I see his entry in the ChangeLog but I still get the highlighting in the REPL.
I think a problem that occurred this morning after updateting slime is connected to this. I found a log message from Marco stating:
Got rid of message about setting up face and skipping edit-hilights when in a comment.
In the CVS mail archives. I think for that you introduced the defun in-comment-p. First of all I think it should be renamed to slime-in-comment-p and second it doesn't work on my XEmacs which has no syntax-ppss-function.
I tried to come up with a portable solution but I know too little of syntax-tables and a little web research on the origins of syntax-ppss yielded no result for me other than that I can't find it even in the source of xemacs-21.5.24.
I got this message this morning from someone who noticed the use of syntax-ppss:
Recent FSF Emacsen offer a function `expand-in-literal' (in expand.el) which shows how to use `parse-partial-sexp' directly instead, and that code is much more portable (even to XEmacs).
I'll try and take a look at that but I don't have XEmacs to test against so maybe you'll want to take a crack at it yourself. Or at least look for my forthcoming patch and test it in XEmacs and let us know how it works.
For todays work I will remove the in-comment-p call in self-insert-function and I hope for some help of you guys.
Should be coming soon.
-Peter
Peter Seibel peter@gigamonkeys.com writes:
"Stefan Kamphausen" skampi@gmx.net writes:
For todays work I will remove the in-comment-p call in self-insert-function and I hope for some help of you guys.
Should be coming soon.
Try this patch. This also provides a kludgy but, I think, real fix to turn off edited-code hilighting in the REPL (the old fix seems to get undone after you load a lisp buffer. See the comment below for my understanding as to why.
-Peter
Index: ChangeLog =================================================================== RCS file: /project/slime/cvsroot/slime/ChangeLog,v retrieving revision 1.823 diff -u -r1.823 ChangeLog --- ChangeLog 20 Dec 2005 00:25:58 -0000 1.823 +++ ChangeLog 20 Dec 2005 17:27:45 -0000 @@ -1,3 +1,8 @@ +2005-12-20 Peter Seibel peter@gigamonkeys.com + + * slime.el (slime-in-comment-p): Renamed from in-comment-p and + made perhaps more portable. + 2005-12-20 Marco Baringer mb@bese.it
When inspecting classes, methods and generic functions show all Index: slime.el =================================================================== RCS file: /project/slime/cvsroot/slime/slime.el,v retrieving revision 1.572 diff -u -r1.572 slime.el --- slime.el 20 Dec 2005 00:13:24 -0000 1.572 +++ slime.el 20 Dec 2005 17:27:55 -0000 @@ -9890,17 +9890,29 @@ (self-insert-command 1) (when (and slime-display-edit-hilights (slime-connected-p) - (not (in-comment-p))) + (not (eq 'slime-repl-mode major-mode)) + (not (slime-in-comment-p))) (let ((overlay (make-overlay (- (point) 1) (point)))) (flet ((putp (name value) (overlay-put overlay name value))) (putp 'face 'slime-display-edit-face) (putp 'slime-edit t)))))
-(defun in-comment-p () - (nth 4 (syntax-ppss (point)))) +(defun slime-in-comment-p () + (let ((lim (or (save-excursion + (beginning-of-defun) + (point)) + (point-min)))) + (nth 4 (parse-partial-sexp lim (point)))))
(add-hook 'slime-mode-hook (lambda () + ;; This is a nice idea but there's apparently some level + ;; of sharing of keymaps between slime-repl-mode and + ;; lisp-mode. Consequently after you load a lisp buffer + ;; these changes show through to the REPL. I've moved the + ;; test for slime-repl-mode to slime-self-insert-command + ;; above for the moment but there's probably a more classy + ;; way to fix this. --Peter Seibel (unless (eq 'slime-repl-mode major-mode) (dotimes (i 127) (when (> i 31)
Hi Peter, and hi slime-devel,
Peter Seibel peter@gigamonkeys.com writes:
Try this patch.
Easier said, than done. How do I apply such patches using the patch program? I tried patch -p0 <patchfile after saving that snippet to patchfile and some parts where rejected.
Anyway, afterwards I applied the patch manually (shame on me ;-) and it works. Well, at least a quick glance in the morning indicates that. I will use it during the day and if anything comes up will send another comment.
In any case: thanks :-)
This also provides a kludgy but, I think, real fix to turn off edited-code hilighting in the REPL
Seems to work, too.
Regards, Stefan
FWIW, I'm running GNU Emacs 21.4.1, and I don't have syntax-ppss either. This is the current emacs for Fedora Core 4.
On Tue, 20 Dec 2005 12:16:21 -0500, Peter Seibel peter@gigamonkeys.com wrote:
"Stefan Kamphausen" skampi@gmx.net writes:
Hi,
Von: Peter Seibel peter@gigamonkeys.com
"Marco Baringer" mb@bese.it writes:
nikodemus fixed this yesterday..
Hmmm. I see his entry in the ChangeLog but I still get the highlighting in the REPL.
I think a problem that occurred this morning after updateting slime is connected to this. I found a log message from Marco stating:
Got rid of message about setting up face and skipping edit-hilights when in a comment.
In the CVS mail archives. I think for that you introduced the defun in-comment-p. First of all I think it should be renamed to slime-in-comment-p and second it doesn't work on my XEmacs which has no syntax-ppss-function.
I tried to come up with a portable solution but I know too little of syntax-tables and a little web research on the origins of syntax-ppss yielded no result for me other than that I can't find it even in the source of xemacs-21.5.24.
I got this message this morning from someone who noticed the use of syntax-ppss:
Recent FSF Emacsen offer a function `expand-in-literal' (in expand.el) which shows how to use `parse-partial-sexp' directly instead, and that code is much more portable (even to XEmacs).
I'll try and take a look at that but I don't have XEmacs to test against so maybe you'll want to take a crack at it yourself. Or at least look for my forthcoming patch and test it in XEmacs and let us know how it works.
For todays work I will remove the in-comment-p call in self-insert-function and I hope for some help of you guys.
Should be coming soon.
-Peter
"Paul Weiss" pgweiss@itasoftware.com writes:
FWIW, I'm running GNU Emacs 21.4.1, and I don't have syntax-ppss either. This is the current emacs for Fedora Core 4.
Did you see my later patch? Does that work in 21.4.1?
-Peter
On Wed, 21 Dec 2005 00:02:06 -0500, Peter Seibel peter@gigamonkeys.com wrote:
"Paul Weiss" pgweiss@itasoftware.com writes:
FWIW, I'm running GNU Emacs 21.4.1, and I don't have syntax-ppss either. This is the current emacs for Fedora Core 4.
Did you see my later patch? Does that work in 21.4.1?
-Peter
No, but I'll look for it in the archives? -P
On Thu, 22 Dec 2005 08:56:06 -0500, Paul Weiss pgweiss@itasoftware.com wrote:
On Wed, 21 Dec 2005 00:02:06 -0500, Peter Seibel peter@gigamonkeys.com wrote:
"Paul Weiss" pgweiss@itasoftware.com writes:
FWIW, I'm running GNU Emacs 21.4.1, and I don't have syntax-ppss either. This is the current emacs for Fedora Core 4.
Did you see my later patch? Does that work in 21.4.1?
-Peter
No, but I'll look for it in the archives? -P
I must be missing something. The only patch I see from you is one that introduces the use of syntax-ppss, which indeed has been committed to CVS. This was the second of two patches you posted on 19DEC -- was there one after this?
-P
"Paul Weiss" pgweiss@itasoftware.com writes:
On Thu, 22 Dec 2005 08:56:06 -0500, Paul Weiss pgweiss@itasoftware.com wrote:
On Wed, 21 Dec 2005 00:02:06 -0500, Peter Seibel peter@gigamonkeys.com wrote:
"Paul Weiss" pgweiss@itasoftware.com writes:
FWIW, I'm running GNU Emacs 21.4.1, and I don't have syntax-ppss either. This is the current emacs for Fedora Core 4.
Did you see my later patch? Does that work in 21.4.1?
-Peter
No, but I'll look for it in the archives? -P
I must be missing something. The only patch I see from you is one that introduces the use of syntax-ppss, which indeed has been committed to CVS. This was the second of two patches you posted on 19DEC -- was there one after this?
http://common-lisp.net/pipermail/slime-devel/2005-December/004408.html%3E
-Peter
Hi,
I recently had a significant memory leak, where Lisp + slime behaved badly while Lisp + terminal (or Emacs inferior-lisp mode) behaved unsurprisingly. I traced it to what I call the "clickable value history" in SLIME. E.g. old values in your *SLIME repl* buffer are still available and kept in the Lisp image. You can reach them via right mouse button (RMB) -> copy to input.
It is as if SLIME had infinite(?) * ** *** **** ***** ****** ... variables that remember ancient values (or rather / // /// //// ///// ...) Outside of SLIME, the old data would have been reclaimed by GC long time ago.
In my particular case, huge data structures would have been ready to free if SLIME had not kept that link. How can I clear this value cache, or control the cache policy?
Thanks for your help, Jorg Hohle
"Hoehle, Joerg-Cyril" Joerg-Cyril.Hoehle@t-systems.com writes:
In my particular case, huge data structures would have been ready to free if SLIME had not kept that link. How can I clear this value cache, or control the cache policy?
you can disable it completly by setting swank::*record-repl-results* to nil. you can clear the current set of values by clearing the repl buffer (M-x slime-repl-clear-buffer or C-c C-t).
Marco Baringer mb@bese.it writes:
"Hoehle, Joerg-Cyril" Joerg-Cyril.Hoehle@t-systems.com writes:
In my particular case, huge data structures would have been ready to free if SLIME had not kept that link. How can I clear this value cache, or control the cache policy?
you can disable it completly by setting swank::*record-repl-results* to nil. you can clear the current set of values by clearing the repl buffer (M-x slime-repl-clear-buffer or C-c C-t).
I would like to add that the history is meant to be implemented by a _weak_ hash table, using the SLIME backend functions MAKE-WEAK-KEY-HASH-TABLE and MAKE-WEAK-VALUE-HASH-TABLE. If those are implemented properly for a CL implementation that supports weak hashtables, the REPL history items (and other presentations) do not cause any memory leak.
The functions are implemented both for Allegro CL and SBCL, but not for CLISP (which Jörg might be using), which I think has excellent support for weak hash tables.
Matthias Koeppe mkoeppe+slime@mail.math.uni-magdeburg.de writes:
Marco Baringer mb@bese.it writes:
"Hoehle, Joerg-Cyril" Joerg-Cyril.Hoehle@t-systems.com writes:
In my particular case, huge data structures would have been ready to free if SLIME had not kept that link. How can I clear this value cache, or control the cache policy?
you can disable it completly by setting swank::*record-repl-results* to nil. you can clear the current set of values by clearing the repl buffer (M-x slime-repl-clear-buffer or C-c C-t).
I would like to add that the history is meant to be implemented by a _weak_ hash table, using the SLIME backend functions MAKE-WEAK-KEY-HASH-TABLE and MAKE-WEAK-VALUE-HASH-TABLE. If those are implemented properly for a CL implementation that supports weak hashtables, the REPL history items (and other presentations) do not cause any memory leak.
The functions are implemented both for Allegro CL and SBCL, but not for CLISP (which Jörg might be using), which I think has excellent support for weak hash tables.
An update: I have now provided these functions for CLISP.
-
Alain.Picard＠memetrics.com -
Dan McCarthy -
Hoehle, Joerg-Cyril -
Marco Baringer -
Matthias Koeppe -
Paul Weiss -
Peter Seibel -
Stefan Kamphausen