[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Improving representation of EIEIO objects in backtraces/error messag
Re: Improving representation of EIEIO objects in backtraces/error messages
Sun, 08 Jan 2017 09:24:38 -0800
Gnus/5.130014 (Ma Gnus v0.14) Emacs/26.0.50 (gnu/linux)
Eric Ludlam <address@hidden> writes:
> On 12/31/2016 03:48 PM, Eric Abrahamsen wrote:
>> Eric Ludlam <address@hidden> 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.
>>> (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
> 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.