GNU bug report logs - #25295
26.0.50; Represent eieio objects using object-print in backtraces and edebug

Previous Next

Full log

View this message in rfc822 format

From: npostavs <at> users.sourceforge.net
To: Eric Abrahamsen <eric <at> ericabrahamsen.net>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 25295 <at> debbugs.gnu.org
Subject: bug#25295: Acknowledgement (26.0.50; Represent eieio objects using object-print in backtraces and edebug)
Date: Sat, 31 Dec 2016 00:48:51 -0500

Eric Abrahamsen <eric <at> ericabrahamsen.net> writes:
> On 12/30/16 09:51 AM, Eli Zaretskii wrote:
>>> From: Eric Abrahamsen <eric <at> 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.
>

I think the only way to integrate `object-print' with the existing
`print' functions, would be to make it follow the same protocol.  That
is, currently `object-print' is really `object-to-string', it should be
changed (or perhaps a new function (e.g., `print-object') would be a
better idea, so as not to break existing code too much) to accept a
PRINTCHARFUN argument, and print to it.

> 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.
>

That's easier, of course, but a non-customized representation would be
pretty uninformative.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.