bug#27397: [PATCH] New commands for bulk tracing of elisp functions

[Phil Sainty <psainty@orcon.net.nz>]

On 19/06/17 21:56, Michael Albinus wrote:
> Ahh, my error. I thought that `trace-package' takes a package name
> (or symbol), and traces only all functions which have been loaded by
> this package.

I concede that the name may cause some confusion, but I chose it
for consistency with `elp-instrument-package' which uses the same
function-name-prefix meaning, so the name makes sense from that
perspective. Obviously ELP pre-dates package.el. YMMV.

Maybe `elp-instrument-package' and `trace-package' should become
`elp-instrument-prefix' and `trace-prefix' ? (I'm not against that
idea.)


>> some kind of `eval-after-load' tracing behaviour
>
> Yes, that's the idea. If `trace-package' uses as argument a package
> name as proposed above, the instrumentation shall happen in an
> `eval-after-load' form for that package.

I think `trace-library' would be the appropriate name?

(If `trace-package' were about ELPA packages, then we have multi-file
packages to consider, which expands the scope further.)

Of course we can't guarantee that library foo.el adheres to a foo-*
naming scheme for all its functions (or that other libraries don't
define any foo-* functions). Would we just ignore this and trace
everything starting with foo- on the assumption that this is good
enough? Or would we parse the library in order to trace that library's
functions precisely?


> `trace-regexp', on the other hand, shall instrument the functions in
> a form added to `after-load-functions', additonally to the functions
> already loaded.

Which could also apply to (the current meaning of) `trace-package'.

I suppose this could potentially be an additional y-or-n-p prompt for
the extended interactive argument input (after BUFFER and CONTEXT)
when using a prefix arg.

I think that the equivalent `untrace-*' commands would need to remove
such `after-load-functions' entries by default, but perhaps a prefix
argument to those would allow users to choose.

I can see potential for users to end up with unwanted remnant entries
in after-load-functions (e.g. trace-regexp "A\\|B", then untrace-regexp
"A" and "B" separately), so I think there could be some fiddly aspects
to all of this; although one could argue that anyone using these
features in the first place is likely to know what they're doing, and
would be able to cope with such situations easily enough; especially
if `untrace-all' takes care of the after-load cases.


-Phil