[slime-devel] 3 todo's
Hi! I've recently started using slime again and I was pleasantly surprised with the obvious evolution! There were a few things that caught my eye though: 1. In APROPOS, multi-line documentation strings don't show properly (only the first line is shown). 2. I really miss a function which would be able to restore the previous window state after using apropos and such. This is a bit more difficult to specify. I was hoping for something like: "whenever a certain type of buffer comes into play due to a function call (e.g., slime-apropos brings up the *SLIME Apropos* buffer), the window state is saved and is retrievable by a call to slime-recover-window-state (or something of the sort). While such class of buffers are shown, no window state is saved again." This is annoying because I spend some time organizing my buffers and then a call to apropos just messes everything up. 3. I'm using Allegro CL 6.2. One thing allegro does is provide a reference character near the place where a given error/warning occurred. Isn't it possible to use this information in the compilation notes buffer? So that one can access the place of the error via a single click as is possible with sbcl for instance? I hope my english was clear enough :). Thank you for your time, Tiago Maduro-Dias.
Tiago Maduro-Dias <tcmd@rnl.ist.utl.pt> writes:
2. I really miss a function which would be able to restore the previous window state after using apropos and such.
Have you looked here: http://www.emacswiki.org/cgi-bin/wiki/CategoryWindows and especially here: http://www.emacswiki.org/cgi-bin/wiki/WinnerMode ? They may be of some assistence. Regards, Dirk Gerrits
Tiago Maduro-Dias <tcmd@rnl.ist.utl.pt> writes:
1. In APROPOS, multi-line documentation strings don't show properly (only the first line is shown).
This is intentional. We follow Emacs conventions and one of them says: The first line of the documentation string should consist of one or two complete sentences that stand on their own as a summary. `M-x apropos' displays just the first line, and if that line's contents don't stand on their own, the result looks bad. In particular, start the first line with a capital letter and end with a period. We are not going to change that.
2. I really miss a function which would be able to restore the previous window state after using apropos and such. This is a bit more difficult to specify. I was hoping for something like: "whenever a certain type of buffer comes into play due to a function call (e.g., slime-apropos brings up the *SLIME Apropos* buffer), the window state is saved and is retrievable by a call to slime-recover-window-state (or something of the sort). While such class of buffers are shown, no window state is saved again." This is annoying because I spend some time organizing my buffers and then a call to apropos just messes everything up.
slime-apropos already saves the window configuration and the configuration can be restored with q (slime-temp-buffer-quit) in the apropos buffer. q works (modulo bugs) the same way in all such "temporary" buffers. Is that not good enough?
3. I'm using Allegro CL 6.2. One thing allegro does is provide a reference character near the place where a given error/warning occurred. Isn't it possible to use this information in the compilation notes buffer? So that one can access the place of the error via a single click as is possible with sbcl for instance?
If you mean by "reference character" the character position included in some compiler warnings then I'd say yes. We already do that. If you mean something else: patches welcome :) Helmut.
Hi! I wasn't aware of the Emacs convention you mention, but it does sound like a useful convention I'll try to follow. I didn't know of q either, but that is exactly what I was going for, so 2 out of 2. Regarding the last note, I have only noticed the problem in Allegro CL 6.2. An example follows: -code- -+ Warnings (1) `-- While compiling these undefined functions were referenced: LALR-PARSER from position 19149 in /Users/tcmd/Desktop/Lisp Development/lalr.lisp -/code- The position is provided by the compiler, so is the source file, but pressing enter on the warning itself won't take me to it. I'm not quite sure how to tackle this one myself, but after what you said and my own experience, I'm assuming this might be an implementation specific bug more than anything else. TMD. On Sep 28, 2004, at 0:04, Helmut Eller wrote:
Tiago Maduro-Dias <tcmd@rnl.ist.utl.pt> writes:
1. In APROPOS, multi-line documentation strings don't show properly (only the first line is shown).
This is intentional. We follow Emacs conventions and one of them says:
The first line of the documentation string should consist of one or two complete sentences that stand on their own as a summary. `M-x apropos' displays just the first line, and if that line's contents don't stand on their own, the result looks bad. In particular, start the first line with a capital letter and end with a period.
We are not going to change that.
2. I really miss a function which would be able to restore the previous window state after using apropos and such. This is a bit more difficult to specify. I was hoping for something like: "whenever a certain type of buffer comes into play due to a function call (e.g., slime-apropos brings up the *SLIME Apropos* buffer), the window state is saved and is retrievable by a call to slime-recover-window-state (or something of the sort). While such class of buffers are shown, no window state is saved again." This is annoying because I spend some time organizing my buffers and then a call to apropos just messes everything up.
slime-apropos already saves the window configuration and the configuration can be restored with q (slime-temp-buffer-quit) in the apropos buffer. q works (modulo bugs) the same way in all such "temporary" buffers. Is that not good enough?
3. I'm using Allegro CL 6.2. One thing allegro does is provide a reference character near the place where a given error/warning occurred. Isn't it possible to use this information in the compilation notes buffer? So that one can access the place of the error via a single click as is possible with sbcl for instance?
If you mean by "reference character" the character position included in some compiler warnings then I'd say yes. We already do that. If you mean something else: patches welcome :)
Helmut.
participants (3)
-
Dirk Gerrits -
Helmut Eller -
Tiago Maduro-Dias