Hi Dmitry, Dmitry Gutov writes: > Thanks for pinging me, but the patch does little to the problem I'm seeing. > > Specifically, edebug-step-in doesn't work to step into a function call > that's calling a generic method. > Thanks for the more specific steps to reproduce your problem. I've had a go at fixing it and have come up with the attached patch. It works by finding and instrumenting all the methods belonging to the generic function you are about to step into, before the call is made. Some limitations: - All the methods get debug instrumentation and temporary breakpoints, not just the one that's about to be executed. But given the potential complexity of method dispatch, it seems that fixing that would require some deep intertwining of Edebug and cl-generic. - If you use edebug-step-in twice on the same generic function it will reinstrument the methods, as opposed to using edebug-step-in twice on a regular function where Edebug can figure out that the function is already instrumented. Fixing that would require some way to include dynamic elements in the :name construct of an Edebug spec so that each method could get a unique deterministic symbol as opposed to an anonymous generated symbol. Or it could be fixed by the "future" described in edebug-form-data's docstring. This automates the steps to reproduce bug#24753, so apply that patch before you try this one.