On 07.05.2017 23:28, Gemini Lasswell wrote:

> Actually the arguments are not known because they have not yet been
> evaluated when edebug-step-in is invoked. So it would have to set a
> breakpoint after argument evaluation, run the code under debugging
> until it gets to that breakpoint, look at the evaluated arguments,
> figure out what method to instrument, instrument the method and set a
> breakpoint in it, and then run again.

Very good point, it sounds like a pain.

Fixing the edebug name for cl-defmethod seems like it should be a 
smaller effort.

I've tried to do that via a new edebug spec for method arguments, see 
the attached variation of your patch (only partially tested).

Unfortunately, this code fails when instrumenting a generic method (e.g. 
using C-u C-M-x) with something like:

Unknown specializer foo@setf\ \(v\ \(_y\ \(eql\ 4\)\)\ z\)

Any thoughts? edebug-match-method-args is definitely at fault there, but 
I'm not sure how to improve it.

> I have started writing tests for
> Edebug, as a step towards making it possible to improve it without
> worrying about breaking things that are working. Probably it will help
> me understand the code in there better too.

Sounds great.

> Here's a revised patch. Thanks for letting me know about pcase-dolist
> as it looks very useful. It's not documented and I didn't know it
> existed.

I usually find those via normal introspection.

Try typing 'C-h f pcase- TAB' and looking at the "public" names (without 
the double-dash in their name).