[slime-devel] Inspector doc
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? Could the hardcoded constants be documented as being hardcoded? 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. -- Madhu
Madhu <enometh@meer.net> 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]
On a related note, I don't like the overly aggressive truncating in backtraces that was introduced recently, and is probably related to the how it's done in the inspector. OTOH, previously I sometimes cursed about the verbosity of backtraces, and now I'm cursing for the lack of details. So I think this needs some thought. Perhaps some way to increase the level of detail? -T.
On Sep 8, 2008, at 22:56 , Tobias C. Rittweiler wrote:
Madhu <enometh@meer.net> 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]
On a related note, I don't like the overly aggressive truncating in backtraces that was introduced recently, and is probably related to the how it's done in the inspector.
On a related note, inspecting strings with embedded newlines is not that useful anymore, I can choose between immediate truncation and seeing them character by character. Example: (list (format nil "~%long string")) Cheers, M/
* Michael Weber [2008-09-08 23:03+0200] writes:
On a related note, inspecting strings with embedded newlines is not that useful anymore, I can choose between immediate truncation and seeing them character by character.
... or pressing p or d. Helmut.
* Tobias C. Rittweiler [2008-09-08 22:56+0200] writes:
Madhu <enometh@meer.net> 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]
On a related note, I don't like the overly aggressive truncating in backtraces that was introduced recently, and is probably related to the how it's done in the inspector.
OTOH, previously I sometimes cursed about the verbosity of backtraces, and now I'm cursing for the lack of details. So I think this needs some thought. Perhaps some way to increase the level of detail?
*backtrace-printer-bindings* is intended for this purpose. Perhaps call/truncated-output-to-string should be called with (* *print-lines* *print-right-margin*) as argument instead of the hardcoded 100. Helmut.
* 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.
Could the hardcoded constants be documented as being hardcoded?
That's easy. slime-inspector-limit is customizable, everything else is hardcoded.
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. Helmut.
* Helmut Eller <m2ej3qyky9.fsf@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
* Madhu [2009-01-14 14:19+0100] writes:
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.
Yes. As I said, almost everything is hardcoded. Helmut.
* Helmut Eller <m2y6xbgtor.fsf@common-lisp.net> : Wrote on Fri, 16 Jan 2009 16:24:36 +0100: | * Madhu [2009-01-14 14:19+0100] writes: | |> 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. | | Yes. As I said, almost everything is hardcoded. Which brings me back to my original post <URL:http://permalink.gmane.org/gmane.lisp.slime.devel/7690> "Could the hardcoded constants be documented as being hardcoded?" [from the message you replied to] | 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. -- Thanks Madhu
participants (4)
-
Helmut Eller -
Madhu -
Michael Weber -
Tobias C. Rittweiler