GNU bug report logs - #27397
[PATCH] New commands for bulk tracing of elisp functions

Previous Next

Full log

View this message in rfc822 format

From: Michael Albinus <michael.albinus <at> gmx.de>
To: Phil Sainty <psainty <at> orcon.net.nz>
Cc: 27397 <at> debbugs.gnu.org, Dmitry Gutov <dgutov <at> yandex.ru>
Subject: bug#27397: [PATCH] New commands for bulk tracing of elisp functions
Date: Mon, 19 Jun 2017 14:05:43 +0200

Phil Sainty <psainty <at> orcon.net.nz> writes:

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

As usual, I don't care too much about function names :-)

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

We cannot assume that library 'foo prefixes all its functions with
"foo-". Even Tramp libraries have functions which do not fit this
scheme, for historical reasons.

So we shall parse indead every function for the library it belongs to. It
shouldn't be too hard, based on `autoloadp', `find-lisp-object-file-name'
and friends, see the implementation in `describe-function-1'. Something
like this is a very rudimentary implementation:

(defun my-find-library (fun)
  "Find library FUN is defined in.
In case of subroutines, return t"
  (when (fboundp fun)
    (let ((def (symbol-function fun)))
      (cond
       ((autoloadp def) (cadr def))
       ((subrp def) t)
       (t (file-name-base (find-lisp-object-file-name fun nil)))))))

> -Phil

Best regards, Michael.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.