On Sun, Jan 12, 2014 at 1:54 AM, martin rudalics <address@hidden> 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
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4