all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
* Rant on ...
@ 2016-11-17 20:47 Alan Mackenzie
  2016-11-17 20:54 ` Lars Ingebrigtsen
  0 siblings, 1 reply; 14+ messages in thread
From: Alan Mackenzie @ 2016-11-17 20:47 UTC (permalink / raw)
  To: emacs-devel

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



^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: Rant on ...
  2016-11-17 20:47 Rant on Alan Mackenzie
@ 2016-11-17 20:54 ` Lars Ingebrigtsen
  2016-11-17 21:04   ` Clément Pit--Claudel
  2016-11-17 21:09   ` Lars Ingebrigtsen
  0 siblings, 2 replies; 14+ messages in thread
From: Lars Ingebrigtsen @ 2016-11-17 20:54 UTC (permalink / raw)
  To: Alan Mackenzie; +Cc: emacs-devel

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



^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: Rant on ...
  2016-11-17 20:54 ` Lars Ingebrigtsen
@ 2016-11-17 21:04   ` Clément Pit--Claudel
  2016-11-17 21:09   ` Lars Ingebrigtsen
  1 sibling, 0 replies; 14+ messages in thread
From: Clément Pit--Claudel @ 2016-11-17 21:04 UTC (permalink / raw)
  To: emacs-devel


[-- 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 --]

^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: Rant on ...
  2016-11-17 20:54 ` Lars Ingebrigtsen
  2016-11-17 21:04   ` Clément Pit--Claudel
@ 2016-11-17 21:09   ` Lars Ingebrigtsen
  2016-11-17 21:20     ` Clément Pit--Claudel
  2016-11-17 21:31     ` Drew Adams
  1 sibling, 2 replies; 14+ messages in thread
From: Lars Ingebrigtsen @ 2016-11-17 21:09 UTC (permalink / raw)
  To: emacs-devel

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



^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: Rant on ...
  2016-11-17 21:09   ` Lars Ingebrigtsen
@ 2016-11-17 21:20     ` Clément Pit--Claudel
  2016-11-17 21:31     ` Drew Adams
  1 sibling, 0 replies; 14+ messages in thread
From: Clément Pit--Claudel @ 2016-11-17 21:20 UTC (permalink / raw)
  To: emacs-devel


[-- 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 --]

^ permalink raw reply	[flat|nested] 14+ messages in thread

* RE: Rant on ...
  2016-11-17 21:09   ` Lars Ingebrigtsen
  2016-11-17 21:20     ` Clément Pit--Claudel
@ 2016-11-17 21:31     ` Drew Adams
  2016-11-17 21:33       ` Drew Adams
  2016-11-17 22:29       ` Lars Ingebrigtsen
  1 sibling, 2 replies; 14+ messages in thread
From: Drew Adams @ 2016-11-17 21:31 UTC (permalink / raw)
  To: Lars Ingebrigtsen, emacs-devel

> 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



^ permalink raw reply	[flat|nested] 14+ messages in thread

* RE: Rant on ...
  2016-11-17 21:31     ` Drew Adams
@ 2016-11-17 21:33       ` Drew Adams
  2016-11-17 22:29       ` Lars Ingebrigtsen
  1 sibling, 0 replies; 14+ messages in thread
From: Drew Adams @ 2016-11-17 21:33 UTC (permalink / raw)
  To: Drew Adams, Lars Ingebrigtsen, emacs-devel

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

(Throughout the backtrace, I meant.)



^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: Rant on ...
  2016-11-17 21:31     ` Drew Adams
  2016-11-17 21:33       ` Drew Adams
@ 2016-11-17 22:29       ` Lars Ingebrigtsen
  2016-11-18  2:17         ` Michael Heerdegen
  2016-11-18  2:25         ` Clément Pit--Claudel
  1 sibling, 2 replies; 14+ messages in thread
From: Lars Ingebrigtsen @ 2016-11-17 22:29 UTC (permalink / raw)
  To: Drew Adams; +Cc: emacs-devel

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



^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: Rant on ...
  2016-11-17 22:29       ` Lars Ingebrigtsen
@ 2016-11-18  2:17         ` Michael Heerdegen
  2016-11-18  2:56           ` Drew Adams
  2016-11-18  2:25         ` Clément Pit--Claudel
  1 sibling, 1 reply; 14+ messages in thread
From: Michael Heerdegen @ 2016-11-18  2:17 UTC (permalink / raw)
  To: Lars Ingebrigtsen; +Cc: Drew Adams, Emacs Development

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.



^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: Rant on ...
  2016-11-17 22:29       ` Lars Ingebrigtsen
  2016-11-18  2:17         ` Michael Heerdegen
@ 2016-11-18  2:25         ` Clément Pit--Claudel
  1 sibling, 0 replies; 14+ messages in thread
From: Clément Pit--Claudel @ 2016-11-18  2:25 UTC (permalink / raw)
  To: emacs-devel


[-- 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 --]

^ permalink raw reply	[flat|nested] 14+ messages in thread

* RE: Rant on ...
  2016-11-18  2:17         ` Michael Heerdegen
@ 2016-11-18  2:56           ` Drew Adams
  2016-11-18  3:27             ` Noam Postavsky
  0 siblings, 1 reply; 14+ messages in thread
From: Drew Adams @ 2016-11-18  2:56 UTC (permalink / raw)
  To: Michael Heerdegen, Lars Ingebrigtsen; +Cc: Emacs Development

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



^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: Rant on ...
  2016-11-18  2:56           ` Drew Adams
@ 2016-11-18  3:27             ` Noam Postavsky
  2016-11-18  3:50               ` Drew Adams
  2016-11-19  0:10               ` Michael Heerdegen
  0 siblings, 2 replies; 14+ messages in thread
From: Noam Postavsky @ 2016-11-18  3:27 UTC (permalink / raw)
  To: Drew Adams; +Cc: Michael Heerdegen, Lars Ingebrigtsen, Emacs Development

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.



^ permalink raw reply	[flat|nested] 14+ messages in thread

* RE: Rant on ...
  2016-11-18  3:27             ` Noam Postavsky
@ 2016-11-18  3:50               ` Drew Adams
  2016-11-19  0:10               ` Michael Heerdegen
  1 sibling, 0 replies; 14+ messages in thread
From: Drew Adams @ 2016-11-18  3:50 UTC (permalink / raw)
  To: Noam Postavsky; +Cc: Michael Heerdegen, Lars Ingebrigtsen, Emacs Development

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



^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: Rant on ...
  2016-11-18  3:27             ` Noam Postavsky
  2016-11-18  3:50               ` Drew Adams
@ 2016-11-19  0:10               ` Michael Heerdegen
  1 sibling, 0 replies; 14+ messages in thread
From: Michael Heerdegen @ 2016-11-19  0:10 UTC (permalink / raw)
  To: Noam Postavsky; +Cc: Emacs Development

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

^ permalink raw reply	[flat|nested] 14+ messages in thread

end of thread, other threads:[~2016-11-19  0:10 UTC | newest]

Thread overview: 14+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2016-11-17 20:47 Rant on Alan Mackenzie
2016-11-17 20:54 ` Lars Ingebrigtsen
2016-11-17 21:04   ` Clément Pit--Claudel
2016-11-17 21:09   ` Lars Ingebrigtsen
2016-11-17 21:20     ` Clément Pit--Claudel
2016-11-17 21:31     ` Drew Adams
2016-11-17 21:33       ` Drew Adams
2016-11-17 22:29       ` Lars Ingebrigtsen
2016-11-18  2:17         ` Michael Heerdegen
2016-11-18  2:56           ` Drew Adams
2016-11-18  3:27             ` Noam Postavsky
2016-11-18  3:50               ` Drew Adams
2016-11-19  0:10               ` Michael Heerdegen
2016-11-18  2:25         ` Clément Pit--Claudel

Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.