From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Josh Newsgroups: gmane.emacs.devel Subject: Re: [PATCH] frame.c: focus hooks Date: Tue, 14 Jan 2014 09:30:40 -0800 Message-ID: References: <528C65F3.9080502@gmx.at> <52D11C17.8040508@gmx.at> <52D26662.4050508@gmx.at> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 X-Trace: ger.gmane.org 1389720680 11507 80.91.229.3 (14 Jan 2014 17:31:20 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 14 Jan 2014 17:31:20 +0000 (UTC) Cc: Brian Jenkins , emacs-devel , Stefan Monnier , Bozhidar Batsov , rms@gnu.org To: martin rudalics Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Jan 14 18:31:26 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 1W37pk-0005g6-OV for ged-emacs-devel@m.gmane.org; Tue, 14 Jan 2014 18:31:24 +0100 Original-Received: from localhost ([::1]:49715 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W37pk-0000zp-BS for ged-emacs-devel@m.gmane.org; Tue, 14 Jan 2014 12:31:24 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:53366) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W37pd-0000zA-Dp for emacs-devel@gnu.org; Tue, 14 Jan 2014 12:31:22 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1W37pY-0008Nh-AH for emacs-devel@gnu.org; Tue, 14 Jan 2014 12:31:17 -0500 Original-Received: from mail-wg0-f48.google.com ([74.125.82.48]:54922) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W37pY-0008Kt-1i for emacs-devel@gnu.org; Tue, 14 Jan 2014 12:31:12 -0500 Original-Received: by mail-wg0-f48.google.com with SMTP id x13so692429wgg.3 for ; Tue, 14 Jan 2014 09:31:10 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc:content-type; bh=r5LCaSJ5afrfMM7nSqpz6kKV51RxhXQ69z0+K9Vc2uM=; b=UA0heglmeIs9yFw0zbVbPeYZ86YQ2HI7SZ5+c+hGOR5zD076xZs5zYVyOyINKmsDuh 2/dNhX+u3V04SxlRJKZ3CW/T9kG3QpMehjx7KdYPuhzQk7GooepL735bKpJhxgv/qP3J XxVmKusH89Rx2TJPI8FYA4Ma9+fYQVB61Cd7KM9smrsOk4J3wi+axgzVVfd4XwqgE5EI GJdJ5ugxeJJkxepKZTWbVjEbv7Cjws2HEq7y1VXLyD9iY9pI3WqQCRYfcIg0Nz+Hv6nl nP98dyQsXJBCndhXuV+5L/t+uxdGDZ1+RFe9EAMfls+TWSzuT+ypFHsn8CVeTRzrna+8 ZmLw== X-Gm-Message-State: ALoCoQk+jxlCyPI1w9HGR5pDqhgJc7eyFn9p6oHQ2et2/loJsCp4FUnOlCD3ubglb66egRSUJXEu X-Received: by 10.195.13.17 with SMTP id eu17mr2540512wjd.24.1389720670741; Tue, 14 Jan 2014 09:31:10 -0800 (PST) Original-Received: by 10.194.165.226 with HTTP; Tue, 14 Jan 2014 09:30:40 -0800 (PST) In-Reply-To: <52D26662.4050508@gmx.at> X-Google-Sender-Auth: D0aZHfKCkzz85aO6BG4LDNkq8Ws X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] [fuzzy] X-Received-From: 74.125.82.48 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:168366 Archived-At: On Sun, Jan 12, 2014 at 1:54 AM, martin rudalics wrote: >> 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'. I'm not sure I understand. I see that near the end of select_window we now call record_buffer, which in turn runs `buffer-list-update-hook'; are you suggesting that if we went down this path then record_buffer would run a new `record-buffer-hook' (and no longer run `buffer-list-update-hook')? >> 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. Sure, it was just an experiment intended to help me understand how often that hook is run and under what conditions. > 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. Thanks for explanation and suggestion. I'll experiment some more to see if there's a reasonable way to obtain the desired behavior with the existing machinery, which I agree would be better than introducing a new hook. Incidentally, I just noticed that though record_buffer runs `buffer-list-update-hook' it's not mentioned in the docstring: Functions running this hook are `get-buffer-create', `make-indirect-buffer', `rename-buffer', `kill-buffer', and `bury-buffer-internal'. Perhaps this is intentional because record_buffer is not exposed at the Lisp level, though? Thanks, Josh > > martin