Rant on ...

Rant on ...

[Alan Mackenzie]

Hello, Emacs.

I'm trying to investigate bug #16184 (where on attempting C-u C-M-x on
certain elisp macros, edebug throws the error "Wrong type argument:
consp, nil").

I set debug-on-error to t, then repeat the procedure to get a backtrace.
The information looks useful, especially when I set truncate-lines to
nil.  Which is a pain in the posterior to have to do EVERY TIME.  What
is the thinking behind using truncate-lines to hide information from the
user?  This is a minor niggle, but it happens so often that it all adds
up to a significant nuisance.  Are there really hackers who prefer to
see only some of the relevant debugging information?

But this is nothing compared with the practice of only printing some of
the backtrace.  Much of the info I want to see has been omitted and
replaced by "...".  For example, in the middle of one of the backtrace's
lines appears:

    (edebug-after (edebug-before 0) 5 (let ((foo ...))))

.  This makes me angry.  What patronisingly insulting piece of Emacs has
decided I don't really want to see what "..." is hiding?  Does it think
the full output might overtax my brain?  Does it think I'm only
interested in seeing a rough outline rather than the full details?  How
dare it!

I would really like to spend the rest of the evening investigating bug
#16184.  Instead I'm forced, once again, to spend valuable time trying
to identify which arcane settings I need to set to non-default to stop
Emacs hiding the truth from me.  (Just for information, I set
print-le\(ngth\|vel\) to nil many years ago, and I've just tried setting
edebug-print-le\(ngth\|vel\) to nil, to no avail).

If anybody knows offhand what settings I need to make, please tell me.

Would anybody object to my getting rid of this obfuscation in Emacs, and
setting the appropriate defaults (whatever they are) not arbitrarily to
truncate backtraces and other info users have requested?

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: Rant on ...

[Lars Ingebrigtsen]

Alan Mackenzie <acm@muc.de> writes:

> Are there really hackers who prefer to see only some of the relevant
> debugging information?

I prefer the truncated lines in the debugging buffer.  It allows me to
scan the stack trace faster.  I can expand the lines I'm interested in
after finding them.

> If anybody knows offhand what settings I need to make, please tell me.

I think there's something binding print-length somewhere annoying, but I
forget the details.  Or was it eval-expression-print-length?

> Would anybody object to my getting rid of this obfuscation in Emacs, and
> setting the appropriate defaults (whatever they are) not arbitrarily to
> truncate backtraces and other info users have requested?

Data forms can be arbitrarily long.  Not truncating them when printing
them can result in printing an expression taking a long time.  (I've
experience something like half-minute pauses when dealing with extreme
data structures.)

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: Rant on ...

[Clément Pit--Claudel]

[-- Attachment #1.1: Type: text/plain, Size: 383 bytes --]

On 2016-11-17 15:54, Lars Ingebrigtsen wrote:
> Alan Mackenzie <acm@muc.de> writes:
> 
>> > Are there really hackers who prefer to see only some of the relevant
>> > debugging information?
> I prefer the truncated lines in the debugging buffer.  It allows me to
> scan the stack trace faster.  I can expand the lines I'm interested in
> after finding them.

Same here :)


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: Rant on ...

[Lars Ingebrigtsen]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> I prefer the truncated lines in the debugging buffer.  It allows me to
> scan the stack trace faster.  I can expand the lines I'm interested in
> after finding them.

But perhaps there should be a command toggle pretty-printint the line
under point?  The pretty-printed version of the line could be "expanded"
under the line.  That would be nice...

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: Rant on ...

[Clément Pit--Claudel]

[-- Attachment #1.1: Type: text/plain, Size: 504 bytes --]

On 2016-11-17 16:09, Lars Ingebrigtsen wrote:
> Lars Ingebrigtsen <larsi@gnus.org> writes:
> 
>> I prefer the truncated lines in the debugging buffer.  It allows me to
>> scan the stack trace faster.  I can expand the lines I'm interested in
>> after finding them.
> 
> But perhaps there should be a command toggle pretty-printint the line
> under point?  The pretty-printed version of the line could be "expanded"
> under the line.  That would be nice...

Maybe TAB? just like in Magit?



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

RE: Rant on ...

[Drew Adams]

> But perhaps there should be a command toggle pretty-printint the
> line under point?  The pretty-printed version of the line could be
> "expanded" under the line.  That would be nice...

1. Yes.

2. And another key to toggle expansion of `...' everywhere.

3. And explanation in `C-h m' help of how to configure Emacs to
show all by default (so toggling changes to `...').

4. And toggling expansion/contraction everywhere in the buffer
should not toggle it everywhere else.  IOW, debug mode should
have its own variable for this, and not just reuse a global
*-print-length-* or whatever setting.

5. FWIW, I too am annoyed by the `...'.  But I am even more
annoyed by the byte code that is still in backtraces:
https://debbugs.gnu.org/cgi/bugreport.cgi?bug=6991

RE: Rant on ...

[Drew Adams]

> 2. And another key to toggle expansion of `...' everywhere.

(Throughout the backtrace, I meant.)

Re: Rant on ...

[Lars Ingebrigtsen]

Drew Adams <drew.adams@oracle.com> writes:

> 2. And another key to toggle expansion of `...' everywhere.

Yes, that would be very nice.  And a command to expand the `...' under
point.  If we had those commands, I think we'd cover most of the
complaints and confusion tied to the *print-le* variables.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: Rant on ...

[Michael Heerdegen]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> Yes, that would be very nice.  And a command to expand the `...' under
> point.  If we had those commands, I think we'd cover most of the
> complaints and confusion tied to the *print-le* variables.

FWIW, I chose this different solution for my init file: when I hit a
certain key at any line in the debugger buffer, I get a popup window
that shows the according (clicked) frame as pretty printed lisp
expression in emacs-lisp-mode.  Having a separate buffer has its
advantages, since this expression can be really huge.  The tricky part
is to get the correct frame number to pass to `backtrace-frame'.

Another command pops up a buffer containing the whole backtrace as a
list of lisp expressions.  I chose to bind print-circle -> t for this,
because the frames can share large structures.  With print-circle ->
nil, the individual frame are better readable, but the whole thing gets
even huger.


Michael.

RE: Rant on ...

[Drew Adams]

> FWIW, I chose this different solution for my init file: when I hit a
> certain key at any line in the debugger buffer, I get a popup window
> that shows the according (clicked) frame as pretty printed lisp
> expression in emacs-lisp-mode.  Having a separate buffer has its
> advantages, since this expression can be really huge.  The tricky
> part is to get the correct frame number to pass to `backtrace-frame'.
> 
> Another command pops up a buffer containing the whole backtrace as a
> list of lisp expressions.  I chose to bind print-circle -> t for
> this, because the frames can share large structures.  With print-circle -> nil, the individual frame are better readable, but the whole thing
> gets even huger.

That too sounds good.

Lots of room for improvement in *Backtrace* buffers.  For me,
the most important improvements would be (1) getting rid of the
bytecode and (2) being able to toggle expansion/contraction of
`...'.  But all the other suggestions made so far sound good too.

Getting rid of the bytecode is important for communicating by
copying/pasting backtrace text.  You cannot copy/paste it all
when some of it is bytecode - you only get the first part of it
- up to some binary character - and the rest is truncated away.

So you have to grab separate bits of it that are not bytecode,
and try to piece those together again, to be able to communicate
the backtrace to someone.

Re: Rant on ...

[Noam Postavsky]

On Thu, Nov 17, 2016 at 9:56 PM, Drew Adams <drew.adams@oracle.com> wrote:
>> FWIW, I chose this different solution for my init file: when I hit a
>> certain key at any line in the debugger buffer, I get a popup window
>> that shows the according (clicked) frame as pretty printed lisp
>> expression in emacs-lisp-mode.  Having a separate buffer has its
>> advantages, since this expression can be really huge.  The tricky
>> part is to get the correct frame number to pass to `backtrace-frame'.
>>
>> Another command pops up a buffer containing the whole backtrace as a
>> list of lisp expressions.  I chose to bind print-circle -> t for
>> this, because the frames can share large structures.  With print-circle -> nil, the individual frame are better readable, but the whole thing
>> gets even huger.
>
> That too sounds good.

Yes, actually I've been wanting something like that, could you post
this somewhere?

>
> Lots of room for improvement in *Backtrace* buffers.  For me,
> the most important improvements would be (1) getting rid of the
> bytecode and (2) being able to toggle expansion/contraction of
> `...'.  But all the other suggestions made so far sound good too.
>
> Getting rid of the bytecode is important for communicating by
> copying/pasting backtrace text.  You cannot copy/paste it all
> when some of it is bytecode - you only get the first part of it
> - up to some binary character - and the rest is truncated away.

I've been thinking we could keep the bytecode, but just print it with
the non-text characters escaped. I'll reopen and follow up on the bug
thread tomorrow.

RE: Rant on ...

[Drew Adams]

> > Getting rid of the bytecode is important for communicating by
> > copying/pasting backtrace text.  You cannot copy/paste it all
> > when some of it is bytecode - you only get the first part of it
> > - up to some binary character - and the rest is truncated away.
> 
> I've been thinking we could keep the bytecode, but just print it
> with the non-text characters escaped.

That would be OK too.  But better might be to (1) remove/elide the
stuff that is meaningless and (2) keep the embedded readable chars.
There is little sense, I think, in escaping junk that is unreadable,
just to (presumably) avoid any loss of info.

For me, it's just about communicating a human-readable backtrace,
but perhaps (?) there is also a need, for some people, to be able
to communicate the whole, real deal, and enable someone else to
restore the escaped byte code from it.  I don't need that.

> I'll reopen and follow up on the bug thread tomorrow.

Good to hear.  Thx.

Re: Rant on ...

[Michael Heerdegen]

[-- Attachment #1: Type: text/plain, Size: 500 bytes --]

Noam Postavsky <npostavs@users.sourceforge.net> writes:

> Yes, actually I've been wanting something like that, could you post
> this somewhere?

Here is what I use, more or less, I hope I succeeded to dissolve it from
all dependencies from my personal stuff.

Could be you must compile it to get backtrace frame counting working
correctly.  The implemented commands are those bound in the
debugger-mode-map at the file's end.

This is just for trying.  Would it be worth it to make this a package?


[-- Attachment #2: bt.el --]
[-- Type: application/emacs-lisp, Size: 3301 bytes --]

[-- Attachment #3: Type: text/plain, Size: 21 bytes --]



Regards,

Michael.

Re: Rant on ...

[Clément Pit--Claudel]

[-- Attachment #1.1: Type: text/plain, Size: 737 bytes --]

On 2016-11-17 17:29, Lars Ingebrigtsen wrote:
> Drew Adams <drew.adams@oracle.com> writes:
> 
>> > 2. And another key to toggle expansion of `...' everywhere.
> Yes, that would be very nice.  And a command to expand the `...' under
> point.  If we had those commands, I think we'd cover most of the
> complaints and confusion tied to the *print-le* variables.

Would this cover performance issues, too? When a large string (like buffer-string) is passed down a bunch of functions, printing a stack trace can take in the tens of seconds.  A really awesome implementation would abbreviate this to a button that would print the string once clicked (instead of just having an 'invisible region of pre-printed text) :)

Clément.


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]