[slime-devel] 3 todo's

[Tiago Maduro-Dias]

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 at 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.
>