[slime-devel] stuff

[Luke Gorrie]

Helmut Eller <e9626484 at stud3.tuwien.ac.at> writes:

> What do you think about the window for selecting a caller?  I had some
> trouble to figure out how to reuse the xref window,

My data structure is a bit funky. I'll change it to use a property
list and make the filename optional.

> so I came up with my own, and tried to imitate the w3m-select-buffer
> window.  Should I switch to the xref window?

Dunno - I think your window looks cool, but it doesn't fit my personal
window-management scheme (not enough frame width). For people who use
wider windows it might be ideal, so perhaps we could have a
configurable to use either scheme for both xref and list-callers.

> Would it be efficient enough to send the entire buffer as a string
> to Lisp and resolve the source path there?  Or should we drop source
> paths entirely and only send buffer offsets across the wire?  It's a
> bit difficult for compiler notes, because we don't want to slow down
> compilation, but we need the buffer offsets for the annotations
> immediately after the compilation.  Perhaps we could do the
> annotation and source path resolution lazily, only when M-n or M-p
> are pressed.

I have no real answers :-). It might even be hard to handle
source-paths correctly in Lisp code. We're using "(read-delimited-list
#\( ...)" currently and I don't think it will handle this awkwardness
with ,@ in backquotes. Really it seems you need to use a full READ and
then break out at a certain point in the call graph -- at least, I
think source-paths really are recording a point in the READ call graph
rather than something more "lexical".

> > Also hacked the batch-mode test suite a bit. There's a little
> > 'test.sh' in CVS for running it. I drive it with different lisp/emacs
> > versions with this script:
> 
> The script works great for Emacs.  XEmacs crashes in batch mode, but
> works fine interactively.

The workaround to test xemacs is batch-mode is to use -nw instead of
--batch. Since output goes to a file it runs non-interactively, but
the contents of the dribble file are pretty useless (lots of
screen-positioning codes :-)

I hacked the script to handle total crashes better.

Cheers,
Luke