From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Phil Sainty Newsgroups: gmane.emacs.bugs Subject: bug#27397: [PATCH] New commands for bulk tracing of elisp functions Date: Mon, 19 Jun 2017 23:00:07 +1200 Message-ID: <6282010c-b2ec-ebca-35b7-a382b30ea3f0@orcon.net.nz> References: <1348823a-7623-8146-8cc0-8c0eff13e458@orcon.net.nz> <34fcc090-6a8b-42de-b6c8-df182f8de938@yandex.ru> <8760fs5sjw.fsf@detlef> <871sqg5mig.fsf@detlef> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Trace: blaine.gmane.org 1497870231 2330 195.159.176.226 (19 Jun 2017 11:03:51 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Mon, 19 Jun 2017 11:03:51 +0000 (UTC) User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 Cc: 27397@debbugs.gnu.org, Dmitry Gutov To: Michael Albinus Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Mon Jun 19 13:03:38 2017 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dMuT4-0008BO-0J for geb-bug-gnu-emacs@m.gmane.org; Mon, 19 Jun 2017 13:03:38 +0200 Original-Received: from localhost ([::1]:41732 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dMuT7-0005f8-F2 for geb-bug-gnu-emacs@m.gmane.org; Mon, 19 Jun 2017 07:03:41 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:45158) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dMuQc-0002qU-Bq for bug-gnu-emacs@gnu.org; Mon, 19 Jun 2017 07:01:11 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1dMuQY-000527-CX for bug-gnu-emacs@gnu.org; Mon, 19 Jun 2017 07:01:06 -0400 Original-Received: from debbugs.gnu.org ([208.118.235.43]:52977) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1dMuQY-00051f-9r for bug-gnu-emacs@gnu.org; Mon, 19 Jun 2017 07:01:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1dMuQX-0003a4-Sn for bug-gnu-emacs@gnu.org; Mon, 19 Jun 2017 07:01:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Phil Sainty Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 19 Jun 2017 11:01:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 27397 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: patch Original-Received: via spool by 27397-submit@debbugs.gnu.org id=B27397.149787002113710 (code B ref 27397); Mon, 19 Jun 2017 11:01:01 +0000 Original-Received: (at 27397) by debbugs.gnu.org; 19 Jun 2017 11:00:21 +0000 Original-Received: from localhost ([127.0.0.1]:55654 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dMuPs-0003Z3-CD for submit@debbugs.gnu.org; Mon, 19 Jun 2017 07:00:21 -0400 Original-Received: from smtp-1.orcon.net.nz ([60.234.4.34]:56309) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dMuPp-0003Yp-NL for 27397@debbugs.gnu.org; Mon, 19 Jun 2017 07:00:19 -0400 Original-Received: from [150.107.172.99] (port=65482 helo=[192.168.20.102]) by smtp-1.orcon.net.nz with esmtpa (Exim 4.86_2) (envelope-from ) id 1dMuPf-000111-I1; Mon, 19 Jun 2017 23:00:07 +1200 In-Reply-To: <871sqg5mig.fsf@detlef> Content-Language: en-US X-GeoIP: NZ X-Spam_score: -1.0 X-Spam_score_int: -9 X-Spam_bar: - X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 208.118.235.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.org gmane.emacs.bugs:133750 Archived-At: 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