[slime-devel] Inspector doc

Madhu enometh at meer.net
Wed Jan 14 13:19:49 UTC 2009


* Helmut Eller <m2ej3qyky9.fsf at common-lisp.net> :
Wrote on Thu, 11 Sep 2008 13:35:10 +0200:

| * Madhu [2008-09-04 08:47+0200] writes:
|> Helu, I'm having trouble using the inspector effectively: some objects
|> are truncated, some lists are truncated etc.  These boil down to
|> bindings of printer variables [the debug state, etc]
|>
|> Can the inspector related variables be documented, and the rationale
|> spelt out as to which output is being truncated, why, and under what
|> circumstances?
|
| Some inspect methods call the pretty printer.  By default the inspector
| sets *print-lines* to 1 and *print-right-margin* to 75.  Inspect methods
| can rebind those.  The length of the "title" is limited to 200 chars.

It is not clear how you expect this to be rebound.  All these are
hardcoded in the EMACS-INSPECT/PRINTER-BINDINGS which is used in
INSPECT-OBJECT at the time the content is prepared.

Am I right in stating this inspector design makes it impossible to
navigate objects which have different viewing [i.e. printer bindings]
requirements and also precludes having multiple inspectors open.

|> Could the hardcoded constants be documented as being
|> hardcoded?
|
| That's easy.  slime-inspector-limit is customizable, everything else is
| hardcoded.

What would be helpful is a listing (in the docs) enumerating the
"everything else" items and the value chosen.

|> I suspect this is not too much to ask if the new inspector is a
|> "better thought out" replacement, the design could be explained in a
|> few paragraphs in comments in the code or in a separate doc.  I think
|> it is an important enough component of SLIME to define the behaviour
|> outside of the code which implements it. 
|
| The final behavior is defined by the inspect methods, which are, in
| general, backend specific.

FWICT the backend specific methods do not rebind the printer variables
so the effects seen are those of decisions made in swank.lisp

--
Madhu





More information about the slime-devel mailing list