Re: Improving representation of EIEIO objects in backtraces/error messages

[Eric Abrahamsen <eric@ericabrahamsen.net>]

Eric Ludlam <eric@siege-engine.com> writes:

> On 12/31/2016 03:48 PM, Eric Abrahamsen wrote:
>> Eric Ludlam <eric@siege-engine.com> writes:
>>
>>> On 12/29/2016 02:02 PM, Eric Abrahamsen wrote:
> ...
>>> CEDET includes a 'data-debug' package.  If you enable that it provides a
>>> way to navigate giant data structures as you might get with EIEIO.  It
>>> is also a part of Emacs now, though I'm not that familiar with how it
>>> all was merged.
>>>
>>> I have this in my .emacs file to take advantage of it:
>>>
>>> (require 'data-debug)
>>> (global-set-key "\M-:" 'data-debug-eval-expression)
>>
>> That's interesting, thanks! I'll play with it a bit, it might be nice to
>> add the slot names in with the values.
>
> The slot names should be included in the display.  At least they are
> for me in my older Emacs.  It may be that the eieio-support doesn't
> work quite right after the EIEIO change in Emacs?
>
> In CEDET, eieio-datadebug is separate, but with EIEIO as a piece of
> core emacs with Data Debug, maybe the current tenuous load should be
> replaced by merging eieio-datadebug into data-debug.

My mistake, I'd only loaded data-debug, not eieio-datadebug. The slots
are showing now.

> ...
>>> In the CEDET repository, you can get cedet-edebug.el.  It includes
>>> these two snippets that bind "A" to data debug.
>>>
>>> ;;;###autoload
>>> (add-hook 'edebug-setup-hook
> [...]
>
>> These are all good for me as a developer, but I would also like to
>> protect users from backtraces that might, ahem, arise from my code. Do
>> you have any opinion on the discussion in
>> https://debbugs.gnu.org/cgi/bugreport.cgi?bug=25295 ? Anything would be
>> welcome.
>
> I'm not familiar with Emacs C level expression printing.  That's why I
> just stopped using built ins and added my own top level commands to
> get things done.
>
> The ideas represented in the thread where some special vector-form
> could fork off to a special printer sounds like a pretty nice idea
> though. That way more than just EIEIO objects could be simplified.
>
> In the above thread, someone mentioned giving up an object's ability
> to customize it's print output.  This is a super handy feature where
> you can take some key differentiator of your object that is short to
> put into the short form print output.  Taking advantage of that
> feature makes using the short print output even better.  Of course,
> the developer needs to implement the method to make it work.  I
> usually go add a new print-object method when I'm debugging so I can
> figure out what's going on.

That was me saying that -- I just meant that, if I had to choose between
customizable object representation in *some* places, and
non-customizable representation in *all* places, I would go with the
latter. But with any luck we'll be able to get both. I agree that a
customizable object-print is a very nice thing.

Eric