bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#43412: [FEATURE] autorevert-only-if-visible [PATCH]


From: martin rudalics
Subject: bug#43412: [FEATURE] autorevert-only-if-visible [PATCH]
Date: Tue, 29 Sep 2020 16:34:07 +0200

> 1) For function `window-buffer-change-functions' when set globally: the
> docstring says that it takes an arg FRAME. During execution of those
> functions, will that arg necessarily be `(selected-frame)'?

No.  FRAME denotes the frame where a buffer change occurred.

> 2) For function `window-buffer-change-functions' when set buffer-local:
> Is there a straightforward way to ensure that the value will be set for
> all buffers, current and future?

No.  The term 'buffer-local' contradicts the formulation "for all
buffers".  If you want to catch changes for several buffers, you either
have to specify the buffer-local value for each of them or you have to
use the default value.

> This would be subtly different from the
> description of what occurs when setting the value globally, because no
> window-walk would be required, and it wouldn't be triggered by window
> deletion events.

Window deletion events as well as events that remove a buffer from a
window are caught by the default value only.  Note in this context that
'window-old-buffer' might not even return a meaningful value if the old
buffer has been deleted in the meantime.

> All I see is `buffer-list-update-hook' which is run by
> `get-buffer-create' (OK), but it's also run by ‘make-indirect-buffer’,
> ‘rename-buffer’, ‘kill-buffer’, ‘bury-buffer-internal’ and
> ‘select-window’ (all unnecessary for setting a buffer-local value in
> `window-buffer-change-functions').

Note that 'buffer-list-update-hook' is run in many locations that are
not related to window changes.

> Slightly off-topic: The 'describe-*' output for these symbols all have
> an ambiguous statement "Probably introduced at or before Emacs version
> 27.1". What's that 'probably' all about? Shouldn't the statement be
> unequivocal, at least for recently added symbols?

Emacs might be just cautious here.  It it finds a definition in version
27.1 and not in version 26.1, it doesn't want to deny that the variable
might have already existed in version 22.1 and was temporarily deleted
in version 25.1.

martin






reply via email to

[Prev in Thread] Current Thread [Next in Thread]