Re: [PATCH] frame.c: focus hooks

[Josh <josh@foxtail.org>]

On Sun, Jan 12, 2014 at 1:54 AM, martin rudalics <rudalics@gmx.at> 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