unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
From: Boruch Baum <boruch_baum@gmx.com>
To: martin rudalics <rudalics@gmx.at>
Cc: 43412@debbugs.gnu.org
Subject: bug#43412: [FEATURE] autorevert-only-if-visible [PATCH]
Date: Tue, 29 Sep 2020 09:05:20 -0400	[thread overview]
Message-ID: <20200929130520.fub7arg7ifmgzmec@E15-2016.optimum.net> (raw)
In-Reply-To: <f28c7617-f546-2689-5280-08c14629db24@gmx.at>

On 2020-09-18 09:49, martin rudalics wrote:
> If you have any further questions, please ask.

Thanks for the informative response. None of the symbols you mentioned
are available in the emacs version I normally use, so they were all new
to me. I do have two follow-up questions that could save me some time:

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)'?

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? 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. 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').

> When these added functions (probably it's one and the same function) are
> run, one can use 'window-old-buffer', 'frame-old-selected-window',
> 'old-selected-window' and 'old-selected-frame' to individually check
> what has changed since the last time.  For example, to find out whether
> a window on the frame reported by 'window-buffer-change-functions' has
> changed its buffer, 'walk-window-tree' for that frame with a function
> that checks whether 'window-buffer' for any such window differs from
> 'window-old-buffer'.  If it does differ, you probably want to check
> whether that buffer should be reverted.

> For 'window-selection-change-functions' you probably want to just check
> whether the buffer of the selected window of the reported frame should
> be reverted.  I would avoid using 'window-configuration-change-hook'
> because that hook also triggers when a window changed its size.  All
> hooks are described in detail in section "28.28 Hooks for Window
> Scrolling and Changes" of the Elisp manual.

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?

--
hkp://keys.gnupg.net
CA45 09B5 5351 7C11 A9D1  7286 0036 9E45 1595 8BC0





  reply	other threads:[~2020-09-29 13:05 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-09-15  4:07 bug#43412: [FEATURE] autorevert-only-if-visible [PATCH] Boruch Baum
2020-09-15 14:30 ` Eli Zaretskii
2020-09-15 15:39   ` Boruch Baum
2020-09-15 15:49     ` Eli Zaretskii
2020-09-15 16:12       ` Boruch Baum
2020-09-15 17:24         ` Eli Zaretskii
2020-09-16 20:11           ` Boruch Baum
2020-09-17 13:13             ` Eli Zaretskii
2020-09-17 20:10               ` Boruch Baum
2020-09-18  6:35                 ` Eli Zaretskii
2020-09-18  7:49               ` martin rudalics
2020-09-29 13:05                 ` Boruch Baum [this message]
2020-09-29 14:34                   ` martin rudalics
2020-09-29 14:45                   ` Eli Zaretskii
2020-09-15 18:47 ` Michael Albinus
2020-09-15 19:31   ` Boruch Baum
2020-09-17 11:07     ` Michael Albinus
2020-09-17 20:03       ` Boruch Baum

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20200929130520.fub7arg7ifmgzmec@E15-2016.optimum.net \
    --to=boruch_baum@gmx.com \
    --cc=43412@debbugs.gnu.org \
    --cc=rudalics@gmx.at \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).