[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#25295: Acknowledgement (26.0.50; Represent eieio objects using objec
From: |
npostavs |
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 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/25.1 (gnu/linux) |
Eric Abrahamsen <eric@ericabrahamsen.net> writes:
> 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.
>
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.
- bug#25295: 26.0.50; Represent eieio objects using object-print in backtraces and edebug, Eric Abrahamsen, 2016/12/29
- Message not available
- bug#25295: Acknowledgement (26.0.50; Represent eieio objects using object-print in backtraces and edebug), Eric Abrahamsen, 2016/12/29
- bug#25295: Acknowledgement (26.0.50; Represent eieio objects using object-print in backtraces and edebug), npostavs, 2016/12/29
- bug#25295: Acknowledgement (26.0.50; Represent eieio objects using object-print in backtraces and edebug), Eric Abrahamsen, 2016/12/30
- bug#25295: Acknowledgement (26.0.50; Represent eieio objects using object-print in backtraces and edebug),
npostavs <=
- bug#25295: Acknowledgement (26.0.50; Represent eieio objects using object-print in backtraces and edebug), Eric Abrahamsen, 2016/12/31
- bug#25295: Acknowledgement (26.0.50; Represent eieio objects using object-print in backtraces and edebug), npostavs, 2016/12/31
- bug#25295: Acknowledgement (26.0.50; Represent eieio objects using object-print in backtraces and edebug), Eric Abrahamsen, 2016/12/31
- bug#25295: Acknowledgement (26.0.50; Represent eieio objects using object-print in backtraces and edebug), Eli Zaretskii, 2016/12/30