From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Phil Sainty Newsgroups: gmane.emacs.bugs Subject: bug#38173: describe-variable: Also tell user *where* variable was changed Date: Wed, 13 Nov 2019 22:19:25 +1300 Message-ID: <69ffb0e3-4616-4147-4888-cc2889694bb5@orcon.net.nz> References: <87pnhxyjxp.8.fsf@jidanni.org> <878solyfr2.8.fsf@jidanni.org> <9a2ece93c5474cdd68e6f7253408dba8@webmail.orcon.net.nz> <87pnhwsmii.5.fsf@jidanni.org> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="86428"; mail-complaints-to="usenet@blaine.gmane.org" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.0 Cc: Katsumi Yamaoka , 38173@debbugs.gnu.org To: =?UTF-8?Q?=E7=A9=8D=E4=B8=B9=E5=B0=BC?= Dan Jacobson Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Wed Nov 13 10:21:17 2019 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([209.51.188.17]) by blaine.gmane.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from ) id 1iUopw-000MIv-PD for geb-bug-gnu-emacs@m.gmane.org; Wed, 13 Nov 2019 10:21:16 +0100 Original-Received: from localhost ([::1]:42378 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1iUopv-00023g-IV for geb-bug-gnu-emacs@m.gmane.org; Wed, 13 Nov 2019 04:21:15 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:44234) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1iUooq-00013E-0y for bug-gnu-emacs@gnu.org; Wed, 13 Nov 2019 04:20:09 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1iUool-0000Hd-0R for bug-gnu-emacs@gnu.org; Wed, 13 Nov 2019 04:20:07 -0500 Original-Received: from debbugs.gnu.org ([209.51.188.43]:50015) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1iUook-0000HM-Tq for bug-gnu-emacs@gnu.org; Wed, 13 Nov 2019 04:20:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1iUook-0007Cl-Ln for bug-gnu-emacs@gnu.org; Wed, 13 Nov 2019 04:20:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Phil Sainty Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 13 Nov 2019 09:20:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 38173 X-GNU-PR-Package: emacs Original-Received: via spool by 38173-submit@debbugs.gnu.org id=B38173.157363677727658 (code B ref 38173); Wed, 13 Nov 2019 09:20:02 +0000 Original-Received: (at 38173) by debbugs.gnu.org; 13 Nov 2019 09:19:37 +0000 Original-Received: from localhost ([127.0.0.1]:58836 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1iUooL-0007C2-7K for submit@debbugs.gnu.org; Wed, 13 Nov 2019 04:19:37 -0500 Original-Received: from smtp-1.orcon.net.nz ([60.234.4.34]:51129) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1iUooI-0007Bs-Fa for 38173@debbugs.gnu.org; Wed, 13 Nov 2019 04:19:35 -0500 Original-Received: from [116.251.203.175] (port=64384 helo=[192.168.20.103]) by smtp-1.orcon.net.nz with esmtpa (Exim 4.90_1) (envelope-from ) id 1iUoo9-0001yu-Ok; Wed, 13 Nov 2019 22:19:25 +1300 In-Reply-To: <87pnhwsmii.5.fsf@jidanni.org> Content-Language: en-GB X-GeoIP: NZ X-Spam_score: -2.9 X-Spam_score_int: -28 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: 209.51.188.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:171486 Archived-At: On 13/11/19 12:28 PM, 積丹尼 Dan Jacobson wrote: > Gasp, that var-watcher stuff is so complicated. Which bit? If you've unfamiliar with elisp then it possibly seems complicated, but if/when you learn some more about the language then I think you'll find that it's a very straightforward piece of code. The only bit that wasn't directly derived from the documentation at C-h f add-variable-watcher was the use of `backtrace-frames' (and pretty-printing that with `pp-to-string'). And the M-x debug-on-variable-change command isn't complicated at all, and would quite likely show you what you want to see. You just need to know debugger command 'c' to continue, 'q' to quit, and the M-x cancel-debug-on-variable-change command when you're all done. > How about: > At the beginning of the user's .emacs: > (setq tracked-variables LIST_OF_TRACKED_VARIABLES) Well for specific lists you could do something along the lines that I suggested, just for all variables in your list. I'm somewhat inclined to suggest that IF something like this was done, a global switch would make more sense. It still might not have the effect you wanted, though -- it's possible to change the apparent / user-facing value of some variables without changing the *actual* value of the variable at all. This is because of the internal structure of lists in lisp. A list variable points at a cons cell, and so long as it remains pointing at a given cons the variable has the same value; but this doesn't prevent the list (which is a chain of cons cells) from being altered. e.g. (defvar foo '(a b c)) => foo foo => (a b c) (debug-on-variable-change 'foo) => nil (setcar foo 'd) => d [no debugger was invoked] foo => (d b c) (setq foo (cdr foo)) Debugger entered--setting foo to (b c): (debug--implement-debug-watch foo (b c) set nil) (setq foo (cdr foo)) ... If you have some reference (maybe even a different variable) pointing into that list, you can change the list without Emacs ever seeing a change to the original variable. (This doesn't always happen, but it certainly *can* happen, and it might lead to you thinking that the proposed feature wasn't working, even if it was working as well as it could be expected to.) I think it's an interesting idea, which would be pretty neat if it could be made to work; but I don't know if it's practical, and I'm dubious that it could be comprehensive enough for your liking. -Phil