Re: Enhancement suggestion: prin1 extension mechanism

[Stefan Monnier]

>   I've used some hacks to override edebug's prin1 to replace these
> objects with syntax like #<semanticdb-table foo.c (100 tags)>, or
> #<FIND RESULTS (5 tags)> where the actual printed representation from
> prin1 might take a minute or so to generate.  (Or, at least, longer
> than I've been willing to wait during a debug session tonight.)
> Fortunately, M-: prints a short form with large parts replaced with
> "..."

There are 2 issues:
- the time to print the object
- the size and shape of the output
The first problem is probably a reflection of the naive way we handle
cycles (i.e. by scanning a singly-linked-list of already seen objects):
if someone were to fix this code to use a hash-table rather than a list,
the minute would probably come down to an acceptable time.  There are
already some places where we disable print-circle to avoid this slowdown
(but in your case, it's not an option since you data is circular).

Of course, you may still want to have an ad-hoc output that hides the
internal representation, even if the internal representation can be
printed in an acceptable amount of time.

Maybe we should introduce a notion of "object" (in the OO sense) in
Emacs's internal representation, so EIEIO (and CL's defstruct) could
then provide its own printer code.

The simplest way to do that might be to simply introduce a new array
type called `object', which would work just like array, except that when
it's printed, it's passed through
(run-hook-with-args-until-success 'object-print-functions obj), so EIEIO
and CL could hook into object-print-functions.  Or we could even stuff
a "class ID" small integer inside the array's size info, so we could
lookup an object-printer-table.


        Stefan