From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: martin rudalics Newsgroups: gmane.emacs.devel Subject: Re: [PATCH] frame.c: focus hooks Date: Sun, 12 Jan 2014 10:54:42 +0100 Message-ID: <52D26662.4050508@gmx.at> References: <528C65F3.9080502@gmx.at> <52D11C17.8040508@gmx.at> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1389520502 23898 80.91.229.3 (12 Jan 2014 09:55:02 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 12 Jan 2014 09:55:02 +0000 (UTC) Cc: Brian Jenkins , emacs-devel , Stefan Monnier , Bozhidar Batsov , rms@gnu.org To: Josh Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Jan 12 10:55:07 2014 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1W2Hl4-0006qc-QG for ged-emacs-devel@m.gmane.org; Sun, 12 Jan 2014 10:55:07 +0100 Original-Received: from localhost ([::1]:37023 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W2Hl4-0008TT-Df for ged-emacs-devel@m.gmane.org; Sun, 12 Jan 2014 04:55:06 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:50577) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W2Hkv-0008R4-FT for emacs-devel@gnu.org; Sun, 12 Jan 2014 04:55:04 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1W2Hkn-0001AN-4Z for emacs-devel@gnu.org; Sun, 12 Jan 2014 04:54:57 -0500 Original-Received: from mout.gmx.net ([212.227.17.20]:62741) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W2Hkm-0001AD-QA for emacs-devel@gnu.org; Sun, 12 Jan 2014 04:54:49 -0500 Original-Received: from [62.47.40.118] ([62.47.40.118]) by mail.gmx.com (mrgmx002) with ESMTPSA (Nemesis) id 0MDhba-1W9Q5Z1x1S-00H5Uy for ; Sun, 12 Jan 2014 10:54:47 +0100 In-Reply-To: X-Provags-ID: V03:K0:UnhzUm9GFktEezgk5dn6/yBLocTx39+WezOthCay+H8J4mwN3eW 1G3qp6nNdePyX8ZIRxil/XPodsZPf+FzVDSDupoJAvi1IC9bGVCM6c55Lx9ZYp/BakpJtvp bwQHmDKBuAvbvgg8VI6c/kJm+gnLZ8dI25PFwHRmRMg/IGJz40O05kQaXHLG/w0P0NP/H9c sUCynqbknPJxtu+OYJFXg== X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.4.x-2.6.x [generic] X-Received-From: 212.227.17.20 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:168164 Archived-At: > I originally interpreted your mention of it as additional evidence that > deciding whether or not to call a new select-window-hook from > Fselect_window based on its NORECORD argument would be a > reasonable approach. It sounds like I misunderstood, and that you > were suggesting simply using the existing b-l-u-h for code that should > run when the selected window changes non-ephemerally. Is that right? Both interpretations are valid: (1) The first interpretation means (implicitly) that we could replace the call to `buffer-list-update-hook' by calling instead something we could name `record-buffer-hook'. (2) The second interpretation means that your function would have to filter the calls of `buffer-list-update-hook' appropriately. > As an experiment, I just evaluated this form with `eval-expression': > > (progn > (setq bluh-hist nil) > (add-hook 'buffer-list-update-hook > (lambda (&rest args) > (push (format "%s: %s" (buffer-name) args) > bluh-hist)))) > > A few seconds later bluh-hist had grown to contain several hundred > elements, even though I did not interact with Emacs at all during the > interim. All of my open buffers appear to be represented in that list, > including ERC buffers, source code buffers, *scratch*, *Backtrace*, > etc. I have not yet tried this experiment with -q/-Q so it's possible > this behavior is being caused by some of my own code or a library, > but if this expected behavior then b-l-u-h doesn't seem well-suited > to the problem I'd like to solve. You didn't explain _what_ you want to solve. Adding the name of the current buffer whenever a hook is run doesn't sound very reasonable to me. Consider the following construct: (defvar my-window nil) (defun foo () (unless (eq (selected-window) my-window) (setq my-window (selected-window)) (ding))) (add-hook 'buffer-list-update-hook 'foo) Here it beeps whenever the selected window visibly changes. What more/less do you want/need? If you give me an example where you cannot apply (2), that is, filter the changes of which window is selected from the `buffer-list-update-hook'-run function we can always add a new hook as sketched in (1) above. But obviously not adding a new hook would be the cheaper solution. martin