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: Thu, 9 Jan 2014 09:01:24 -0800 Message-ID: References: <528C65F3.9080502@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 1389286924 25932 80.91.229.3 (9 Jan 2014 17:02:04 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 9 Jan 2014 17:02:04 +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 Thu Jan 09 18:02:11 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 1W1Izi-0006Er-8q for ged-emacs-devel@m.gmane.org; Thu, 09 Jan 2014 18:02:10 +0100 Original-Received: from localhost ([::1]:53153 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W1Izh-0006Bb-TP for ged-emacs-devel@m.gmane.org; Thu, 09 Jan 2014 12:02:09 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:58659) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W1IzZ-00066D-Tg for emacs-devel@gnu.org; Thu, 09 Jan 2014 12:02:06 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1W1IzV-0005uE-Jh for emacs-devel@gnu.org; Thu, 09 Jan 2014 12:02:01 -0500 Original-Received: from mail-we0-f177.google.com ([74.125.82.177]:39985) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W1IzV-0005u4-E9 for emacs-devel@gnu.org; Thu, 09 Jan 2014 12:01:57 -0500 Original-Received: by mail-we0-f177.google.com with SMTP id x55so754020wes.22 for ; Thu, 09 Jan 2014 09:01:56 -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=89Fb/KPFcPznzuenX5+DHH5TLww9Qo54Zp9RMyIBZbE=; b=GiTRxtB5gFIIxSIzLKfyHC1HIRw9Q1cUg04G4t5B8ZHSNzYFOYB/V9bvf3StIQWxEt DgexK2fXJxN5DkMpK2NhFO+ljqiQVUmZBwu+clWZntPDUDhJqoRxkUCNE5BTGT50q1HP QfJEi9bYtufHVQhrNykdB8tBVtQnsYhx/bjCnCWzQ8eccYE1vHvF8GAi/zH89yZXVRsf X0Dc65kG5rG/sDp+yfWIvdjxgpGrN4ZDPXlZOdPz/oE5LlYTGezjJ4im3KdOHlX3yDkh coI6cYwiB8XaWsaKSIfwnLCG6m60pbh8PAA4r8+f54EZ0OvEo2Gr4a63UCROB9CXkovW 1eJA== X-Gm-Message-State: ALoCoQkHj5cyXKV9moS0rj+yNw1CZmoyz45o9HUqo81QpgG5dESGC09Bfwie15zECDsKsKwxj57b X-Received: by 10.194.77.106 with SMTP id r10mr3853409wjw.91.1389286915865; Thu, 09 Jan 2014 09:01:55 -0800 (PST) Original-Received: by 10.194.165.226 with HTTP; Thu, 9 Jan 2014 09:01:24 -0800 (PST) In-Reply-To: <528C65F3.9080502@gmx.at> X-Google-Sender-Auth: 2i5Y_cUI5t8CWfH39Gq6GigO9JY X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] [fuzzy] X-Received-From: 74.125.82.177 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:167939 Archived-At: On Tue, Nov 19, 2013 at 11:34 PM, martin rudalics wrote: >> Yes, that's a fair point. Is there some way we could distinguish >> between such ephemeral selected-window changes and transitions from >> one steady state to another? > > If the NORECORD argument is non-nil as in `with-selected-window', the > call is usually an ephemeral one. `buffer-list-update-hook' is called > only when NORECORD is nil. Sorry I failed to follow up on this earlier. Stefan, do I understand correctly that you'd be amenable to a new `select-window-hook' provided that it did not come into play for the ephemeral changes of selected-window that can occur within a single command? If so, I'd like to take a stab at implementing this (I realize that any such hook could not be checked in until the feature thaw). Unless anything has changed since your earlier comment[0], I'd start with your suggestion of adding the new run_hooks call to Fselect_window after verifying that all of its current callers can tolerate running arbitrary Elisp. [0] http://debbugs.gnu.org/cgi/bugreport.cgi?bug=7381#59 Thanks, Josh