Re: [PATCH] frame.c: focus hooks

[Josh]

On Sat, Jan 11, 2014 at 2:25 AM, martin rudalics <address@hidden> wrote:
>>> 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.
>
> Can you telll me whether/why `buffer-list-update-hook' doesn't work for
> you?

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?

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.

Thanks,
Josh