bug#25295: Acknowledgement (26.0.50; Represent eieio objects using object-print in backtraces and edebug)

[Eric Abrahamsen]

On 12/29/16 22:42 PM, npostavs@users.sourceforge.net wrote:

> You mean print_object?  I thought the idea would be to change edebug and
> backtrace code to (optionally?) use object-print instead of print.

I do mean print_object, sorry. (And sorry I keep replying to you only!)

On 12/30/16 09:51 AM, Eli Zaretskii wrote:
>> From: Eric Abrahamsen <eric@ericabrahamsen.net>
>> Date: Thu, 29 Dec 2016 13:50:09 -0800
>> 
>> I guess this would require going into print.c and adding another branch
>> under the Lisp_Vectorlike case statement of object_print.
>> 
>> Is this sort of C code allowed to call back up to the lisp object-print
>> function?
>
> If that Lisp function will then call print.c again, that's not a good
> idea, since print.c internally uses a buffer by a certain fixed name.

`object-print' ends up using `format', which looks like it calls print.c
functions, so I guess that's out.

I don't know the right level at which to intervene. All other lisp
objects get a hard-coded #<obj representation from print_object in
print.c, only eieio objects "fake it" with a user-overrideable lisp
function. I suspect eieio objects won't be considered "fundamental" on
the same level as markers, buffers, etc., so maybe they don't belong in
print_object (plus the above problem of calling lisp-c-lisp-c).

I don't see how we could hijack at the lisp level, though. Functions
like `eval-expression' and `backtrace--print-frame' simply toss whole
lisp structures to prin1, there's no way to know that there's an eieio
object somewhere in that structure.

Personally, I'd be willing to lose the ability to customize object
representations with `object-print', if it meant that print_object could
produce a #<obj notation for eieio objects. That would mean writing a 
C test like INSTANCEP or what have you.

I don't know what the right solution is!

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.