unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
From: martin rudalics <rudalics@gmx.at>
To: Boruch Baum <boruch_baum@gmx.com>
Cc: 43412@debbugs.gnu.org
Subject: bug#43412: [FEATURE] autorevert-only-if-visible [PATCH]
Date: Tue, 29 Sep 2020 16:34:07 +0200	[thread overview]
Message-ID: <cf74f1f2-d895-a9e6-fd9b-6b7885e0140f@gmx.at> (raw)
In-Reply-To: <20200929130520.fub7arg7ifmgzmec@E15-2016.optimum.net>

 > 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	other threads:[~2020-09-29 14:34 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
2020-09-29 14:34                   ` martin rudalics [this message]
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=cf74f1f2-d895-a9e6-fd9b-6b7885e0140f@gmx.at \
    --to=rudalics@gmx.at \
    --cc=43412@debbugs.gnu.org \
    --cc=boruch_baum@gmx.com \
    /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).