On 2016-09-23 03:51, Vasilij Schneidermann wrote:
>> This looks great! I love it.  And the patch looks very clean, too.
> 
> Thanks!  I've updated the patch after a bit more testing.  The extra 
> debug line happened because the search in debug.el did actually
> search for a `debug' call, so `(search-forward "\  (debug")` would
> match a call to `debug-foo` as well. Assuming there will always be
> extra args, this can be solved by appending a space to the search
> string.

Could it just search for the first occurence only?

>> But it scares me a bit.  Some tools do depend on e.g. trimming a 
>> backtrace after printing it.  Does edebug work with your patch,
>> for example?
> 
> Yes, it does.  …  The only thing other than `debug.el` 
> manipulating them is `edebug-backtrace' which I've never heard of 
> before. 

This is the one I was scared about. You can get a backtrace while edebugging by pressing t IIRC.  I have a faint memory of this code doing nasty things to remove edebug instrumentation from the backtrace before displaying it.

>> I'm not sure what the right way to transition is.  Maybe Emacs
>> should let Lisp programs access the backtraces in a structured way,
>> and then backtrace printing would only be a user-facing facility
>> (programs wouldn't use the textual representation).
> 
> There is actually a way to do this, simply use `backtrace-frame' with
> an increasing integer argument until it returns nil:
> 
> (let ((frame t) ; dummy value to kick-start the loop (i 0)) (while
> frame (setq frame (backtrace-frame i)) (message "%S" frame) (setq i
> (1+ i))))

Neat! Didn't know about this.  I think it would be great to add a pointer to this in the documentation of `backtrace'.

Great work :)
Clément.