bug#51930: 27.2; Buffer-local functions? Buffers specified buffer-locally?

bug#51930: 27.2; Buffer-local functions? Buffers specified buffer-locally?

[Drew Adams]

I'm trying to read (elisp) `Window Hooks', and I can't make heads or
tails of it.  Throughout this node there's mention of buffer-local
functions: "functions specified buffer-locally".

I have no idea what is meant by this.  I search the Elisp manual for
buffer-local, and I find zillions of matches that are about
buffer-local variables, of course.  And I find a couple of mentions
of buffer-local faces.  No mention, that I can find, of buffer-local
functions or "functions specified buffer-locally".  How to specify a
function buffer-locally?

A wild guess is that what you're trying to say has something to do
with using the LOCAL argument to `add-hook' or `remove-hook`.  But
if so, it's not clear what.

Please clean up this text so it's comprehensible by an average reader.
If buffer-local functions are indeed a thing now, please document what
they are, somewhere.

In GNU Emacs 27.2 (build 1, x86_64-w64-mingw32)
 of 2021-03-26 built on CIRROCUMULUS
Repository revision: deef5efafb70f4b171265b896505b92b6eef24e6
Repository branch: HEAD
Windowing system distributor 'Microsoft Corp.', version 10.0.19042
System Description: Microsoft Windows 10 Pro (v10.0.2009.19042.1288)

bug#51930: 27.2; Buffer-local functions? Buffers specified buffer-locally?

[Eli Zaretskii]

> From: Drew Adams <drew.adams@oracle.com>
> Date: Wed, 17 Nov 2021 21:51:29 +0000
> 
> I'm trying to read (elisp) `Window Hooks', and I can't make heads or
> tails of it.  Throughout this node there's mention of buffer-local
> functions: "functions specified buffer-locally".
> 
> I have no idea what is meant by this.  I search the Elisp manual for
> buffer-local, and I find zillions of matches that are about
> buffer-local variables, of course.  And I find a couple of mentions
> of buffer-local faces.  No mention, that I can find, of buffer-local
> functions or "functions specified buffer-locally".  How to specify a
> function buffer-locally?
> 
> A wild guess is that what you're trying to say has something to do
> with using the LOCAL argument to `add-hook' or `remove-hook`.  But
> if so, it's not clear what.
> 
> Please clean up this text so it's comprehensible by an average reader.
> If buffer-local functions are indeed a thing now, please document what
> they are, somewhere.

This is a very dramatic description of a problem ("can't make heads or
tails", "I have no idea what is meant", etc.), so I'm not sure whether
a simple cross-reference to the documentation of add-hook, which
explains what is meant by "buffer-local" in this case, will solve the
problem.  If it will, doing that is very easy.  In fact, I just did.

bug#51930: 27.2; Buffer-local functions? Buffers specified buffer-locally?

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

> This is a very dramatic description of a problem ("can't make heads or
> tails", "I have no idea what is meant", etc.), so I'm not sure whether
> a simple cross-reference to the documentation of add-hook, which
> explains what is meant by "buffer-local" in this case, will solve the
> problem.  If it will, doing that is very easy.  In fact, I just did.

I think "Functions specified buffer-locally" is an unusual way to say
"the buffer-local value of window-buffer-change-functions" -- if indeed
that's what it's trying to say.  I think rewriting this in a less
passive voice would be a good idea:

---
Functions specified buffer-locally are called for any window showing
the corresponding buffer if that window has been created or assigned
that buffer since the last time window change functions were run.  In
this case the window is passed as argument.

Functions specified by the default value are called for a frame if at
least one window on that frame has been added, deleted or assigned
another buffer since the last time window change functions were run.
In this case the frame is passed as argument.
---


-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#51930: 27.2; Buffer-local functions? Buffers specified buffer-locally?

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: Drew Adams <drew.adams@oracle.com>,  51930@debbugs.gnu.org
> Date: Thu, 18 Nov 2021 10:42:13 +0100
> 
> I think "Functions specified buffer-locally" is an unusual way to say
> "the buffer-local value of window-buffer-change-functions" -- if indeed
> that's what it's trying to say.  I think rewriting this in a less
> passive voice would be a good idea:

I didn't touch that text, I added a general explanation before it.  I
didn't understand the report as being against the passive tense there.
Of course, everyone should feel free to improve and/or clarify the
text in the manual, regardless.

bug#51930: [External] : Re: bug#51930: 27.2; Buffer-local functions? Buffers specified buffer-locally?

[Drew Adams]

> I think "Functions specified buffer-locally" is an unusual way to say
> "the buffer-local value of window-buffer-change-functions"

To put it mildly.  And it _doesn't_ say that,
at all.  There's no way to legitimately read
it as saying that.

> -- if indeed that's what it's trying to say.

Yes.  It's a question any reader will pose:
What is it trying to say?

> I think rewriting this in a less passive voice
> would be a good idea:
> 
> ---
> Functions specified buffer-locally

That has the same problem.  A reader asks,
What are they trying to say?  What does it
mean for a _function_ to be specified
buffer-locally?  Means nothing, so far.

bug#51930: 27.2; Buffer-local functions? Buffers specified buffer-locally?

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

> This is a very dramatic description of a problem ("can't make heads or
> tails", "I have no idea what is meant", etc.), so I'm not sure whether
> a simple cross-reference to the documentation of add-hook, which
> explains what is meant by "buffer-local" in this case, will solve the
> problem.  If it will, doing that is very easy.  In fact, I just did.

I think the section is clear after that clarification, so I'm closing
this bug report.

bug#51930: 27.2; Buffer-local functions? Buffers specified buffer-locally?

[Drew Adams]

> > This is a very dramatic description of a problem ("can't make heads or
> > tails", "I have no idea what is meant", etc.), so I'm not sure whether
> > a simple cross-reference to the documentation of add-hook, which
> > explains what is meant by "buffer-local" in this case, will solve the
> > problem.  If it will, doing that is very easy.  In fact, I just did.
> 
> I think the section is clear after that clarification, so I'm closing
> this bug report.

Nope, it's not clear.  The doc of `add-hook' does
not at all talk about buffer-local functions.  It
talks about buffer-local hooks and a buffer-local
hook list.  A buffer-local function is neither
defined nor described anywhere.

If what is meant is the use of the function on
a hook buffer-locally, then say that.  Don't imply
that there's such a thing, defined anywhere, as
a buffer-local function.  Or else define it
somewhere.

bug#51930: 27.2; Buffer-local functions? Buffers specified buffer-locally?

[Eli Zaretskii]

> From: Drew Adams <drew.adams@oracle.com>
> CC: "51930@debbugs.gnu.org" <51930@debbugs.gnu.org>
> Date: Tue, 20 Sep 2022 15:58:25 +0000
> 
> > I think the section is clear after that clarification, so I'm closing
> > this bug report.
> 
> Nope, it's not clear.  The doc of `add-hook' does
> not at all talk about buffer-local functions.

What are "buffer-local functions"?  I'm not aware of such a feature in
Emacs.  The documentation of add-hook doesn't mention any
"buffer-local functions".

The node "Windows Hooks" uses the phrase "Functions specified
buffer-locally", after it explains that hooks can have buffer-local or
global values.  I see no problem with that.

bug#51930: 27.2; Buffer-local functions? Buffers specified buffer-locally?

[Drew Adams]

> > > I think the section is clear after that clarification, so I'm closing
> > > this bug report.
> >
> > Nope, it's not clear.  The doc of `add-hook' does
> > not at all talk about buffer-local functions.
> 
> What are "buffer-local functions"?  I'm not aware of such a feature in
> Emacs.  The documentation of add-hook doesn't mention any
> "buffer-local functions".

We agree.  It's defined nowhere, AFAICT.  That's
the point of the bug report.

> The node "Windows Hooks" uses the phrase "Functions specified
> buffer-locally", after it explains that hooks can have buffer-local or
> global values.  I see no problem with that.

Is that the node you've linked to?  I thought
you linked to node `Setting Hooks', where
`add-hook' is covered.  (I think you said you
linked to where `add-hook' is covered?)

FWIW, I don't see any node "Windows Hooks" in
Emacs 28.1 or earlier.  Presumably that was
added later - 28.2 or 29?

However, does that node define/explain what
it _means_ for a _function_ to be "specified
buffer-locally"?  Is it just about functions
on hooks, and is it just that a "function
specified buffer-locally" _is_ (the use of)
a function on a buffer-local hook?

100% agreement that it's clear that _hooks_
(which are variables) can be buffer-local.

It sounds like maybe we're agreeing?

bug#51930: 27.2; Buffer-local functions? Buffers specified buffer-locally?

[Eli Zaretskii]

> From: Drew Adams <drew.adams@oracle.com>
> CC: "larsi@gnus.org" <larsi@gnus.org>,
>         "51930@debbugs.gnu.org"
> 	<51930@debbugs.gnu.org>
> Date: Tue, 20 Sep 2022 16:37:15 +0000
> 
> > The node "Windows Hooks" uses the phrase "Functions specified
> > buffer-locally", after it explains that hooks can have buffer-local or
> > global values.  I see no problem with that.
> 
> Is that the node you've linked to?  I thought
> you linked to node `Setting Hooks', where
> `add-hook' is covered.  (I think you said you
> linked to where `add-hook' is covered?)

I looked in both.

> FWIW, I don't see any node "Windows Hooks" in

"Window Hooks", without "s".

> However, does that node define/explain what
> it _means_ for a _function_ to be "specified
> buffer-locally"?

I think it does, yes.

bug#51930: 27.2; Buffer-local functions? Buffers specified buffer-locally?

[Drew Adams]

> > > The node "Windows Hooks" uses the phrase "Functions specified
> > > buffer-locally", after it explains that hooks can have buffer-local
> > > or global values.  I see no problem with that.
> >
> > Is that the node you've linked to?  I thought
> > you linked to node `Setting Hooks', where
> > `add-hook' is covered.  (I think you said you
> > linked to where `add-hook' is covered?)
> 
> I looked in both.
> 
> > FWIW, I don't see any node "Windows Hooks" in
> 
> "Window Hooks", without "s".

Thanks; I see that now (e.g. in Emacs 28.1).

BTW, there's a typo here; "of" should be "or":

 As any hook, these hooks can be set either globally
 of buffer-locally via the LOCAL argument of 'add-hook'
 ^^
 (*note Setting Hooks::) when the hook is installed.

> > However, does that node define/explain what
> > it _means_ for a _function_ to be "specified
> > buffer-locally"?
> 
> I think it does, yes.

I don't think so, FWIW.  One might _guess_ that it
means that, when used on a buffer-local hook the	
function _is_ a buffer-local function, IOW, guess
that that's the definition of a buffer-local
function.  But that's not said, AFAICT.  Please
consider adding such a definition.  (But should
such a general definition be in a node about only
_window_ hooks?)

FWIW, I see nothing (in 18.1) in node `Setting
Hooks' that mentions buffer-local functions.  All
I see mention of there is buffer-local hooks.
(That doesn't mean there shouldn't be a link to
that node -- the link is good.)

bug#51930: 27.2; Buffer-local functions? Buffers specified buffer-locally?

[Phil Sainty]

The pattern I see in the manual is:

  -- Variable: HOOK-NAME
      This variable specifies functions ...

      Functions specified buffer-locally are called ...

      Functions specified by the default value are called ...


So there's a minor inconsistency in phrasing there.  How about we
change all of these like so:

      Functions specified by the buffer-local value are called ...

      Functions specified by the default value are called ...


Then it's consistent, and I think also resolves Drew's concern?


-Phil

bug#51930: 27.2; Buffer-local functions? Buffers specified buffer-locally?

[Drew Adams]

>       Functions specified buffer-locally are called ...
>       Functions specified by the default value are called ...
> 
> So there's a minor inconsistency in phrasing there.  How about we
> change all of these like so:
> 
>       Functions specified by the buffer-local value are called ...
>       Functions specified by the default value are called ...
> 
> Then it's consistent, and I think also resolves Drew's concern?

Works for me.  Thx.

bug#51930: 27.2; Buffer-local functions? Buffers specified buffer-locally?

[Eli Zaretskii]

> Date: Wed, 21 Sep 2022 12:13:05 +1200
> From: Phil Sainty <psainty@orcon.net.nz>
> Cc: Eli Zaretskii <eliz@gnu.org>, 51930@debbugs.gnu.org, larsi@gnus.org
> 
> So there's a minor inconsistency in phrasing there.  How about we
> change all of these like so:
> 
>       Functions specified by the buffer-local value are called ...
> 
>       Functions specified by the default value are called ...

Double passive tense? no, thanks.

bug#51930: 27.2; Buffer-local functions? Buffers specified buffer-locally?

[Phil Sainty]

On 2022-09-21 14:36, Eli Zaretskii wrote:
>> From: Phil Sainty <psainty@orcon.net.nz>
>>       Functions specified by the buffer-local value are called ...
>>       Functions specified by the default value are called ...
> 
> Double passive tense? no, thanks.

Well one of those is what's already in the manual.

I personally disagree that the double passive tense is bad here,
but here's another alternative:


  -- Variable: window-buffer-change-functions

      A list of functions called during redisplay when window buffers
      have changed.  Each function takes a single argument.

      For the buffer-local value, each function is called for any window
      showing the corresponding buffer, if that window has been created
      or assigned that buffer since the last time window change functions
      were run.  In this case the window is passed as argument.

      For the default value, each function is called for a frame if at
      least one window on that frame has been added, deleted or assigned
      another buffer since the last time window change functions were
      run.  In this case the frame is passed as argument.

bug#51930: 27.2; Buffer-local functions? Buffers specified buffer-locally?

[Stefan Kangas]

Phil Sainty <psainty@orcon.net.nz> writes:

> I personally disagree that the double passive tense is bad here,
> but here's another alternative:

That alternative is indeed less clear than what you had before.

    "Never use the passive where you can use the active."
                           ^^^^^^^^^^^^^
    —George Orwell, "Politics and the English Language," April 1946

Note the qualifier.

window-buffer-change-functions

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

I tried to fix the documentation of `window-buffer-change-functions'
to avoid passive voice, then discovered it was unclear in other ways.
So I decided to rewrite it to make it clear.

In that attempt, I found it was so unclear that I could not be sure
what the variable actually does.  I concluded ultimately that the
problem was in the variable's meaning, not just in the documentation
text.  If I understand it right, it uses the default (global?) value
in one way and buffer-local values in another way.

This messes up the general rule for the meaning of buffer-local
bindings, undermining the clarity of the Emacs Lisp language.  We
should try hard to avoid ever doing that.  In this case I think it
will not be hard.

I propose we replace it with two variables, each with a simple
meaning.  They could be `buffer-window-change-functions' and
`frame-buffer-change-functions'.

`frame-buffer-change-functions' would do what is documented for the
default value of `window-buffer-change-functions', and the
`buffer-window-change-functions' would do the job documented for the
buffer-local values.  (If I understand that documention correctly.)

We could retain `window-buffer-change-functions' for compatibility,
marked obsolete, if it has existed with its current meaning for long
enough to make that desirable.  Or, if that variable used to be
limited to frames, we could make `frame-buffer-change-functions'
an alias for it.

@defvar frame-buffer-change-functions
A list of functions for redisplay to call to indicate changes
in the displayed buffers in a frame.  Each function should accept
one argument, a frame.

Redisplay, when necessary, calls each of these functions once for each
frame, with the frame as argument, @emph{if} at least one window on
that frame has been added, deleted or made to display a different
buffer since the last time redisplay called these functions.
@end defvar

@defvar buffer-window-change-functions
A list of functions for redisplay to call (when necessary) to indicate
changes in the displayed buffers in a frame.  Each function should
accept one argument, a window.

For each window, @emph{if} the window has been created, or made to
display that buffer, since the last time redisplay called these
functions, redisplay checks the value of this variable in the window's
displayed buffer.  That value should be a list of functions of one
argument.  Redisplay calls each function on the list, giving the
window as argument.

Most buffers don't need this special treatment, so normally programs
will give `buffer-window-change-functions' a buffer-local value in
those buffers that do need it.
@end defvar

This is still complicated, but much less so.

Did I guess right about what the existing variable does?

-- 
Dr Richard Stallman (https://stallman.org)
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

RE: [External] : window-buffer-change-functions

[Drew Adams]

I guess this is somewhat related to bug #51930
(which is only about the doc).

https://debbugs.gnu.org/cgi/bugreport.cgi?bug=51930

bug#51930: 27.2; Buffer-local functions? Buffers specified buffer-locally?

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

        > For the buffer-local value, each function is called for any window
        > showing the corresponding buffer, if that window has been created
        > or assigned that buffer since the last time window change functions
        > were run.  In this case the window is passed as argument.

        > For the default value, each function is called for a frame if at
        > least one window on that frame has been added, deleted or assigned
        > another buffer since the last time window change functions were
        > run.  In this case the frame is passed as argument.

It is always better to avoid the passive tense entirely, unless that
is difficult somehow.  I wanted to do this, to provide an example.
In the process I found a much worse problem: the text is not clear at all.
I don't understand the behavior it tries to document.

But I tried anyway, and documented what appears to be a bizarre use of
both the variable's default value and its current value, in different ways.

======================================================================
A list of functions for redisplay to call when the assignment of
buffers to windows has changed.  Each function takes a single
argument.

This variable is peculiar in that its default value has one meaning
and its actual value (normally buffer-local) has a different meaning.
Redisplay uses both of these values, each in a different way.

For the actual (buffer-local) value, redisplay calls each function
once for each window, with the window as argument, if that window has
been created or assigned that buffer since the last time the window
change functions were called.

For the default value, redisplay calls each function once for each
frame, with the frame as argument, if at least one window on that
frame has been added, deleted or assigned another buffer since the
last time window change functions were called.
======================================================================

However, looking at the doc string of the variable seems to describe
a different behavior, more like this:

======================================================================
A list of functions for redisplay to call when the assignment of
buffers to windows has changed.  Each function takes a single
argument.

Redisplay examines the global value of this variable, and calls each
function once for each frame, with the frame as argument, if at least
one window on that frame has been added, deleted or made to display a
different buffer since the last time window change functions were
called.

Redisplay also checks a buffer-local value of this variable in each
buffer that's currenly displayed in a window.  If there is one,
redisplay calls each function listed there for each window that
displays the buffer in question, with the window as argument,
@emph{if} the window has been created, or made to display that buffer,
since the last time the window change functions were called.
======================================================================

Is this correct?  I can't tell from the text available.


-- 
Dr Richard Stallman (https://stallman.org)
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: window-buffer-change-functions

[Eli Zaretskii]

> From: Richard Stallman <rms@gnu.org>
> Date: Wed, 21 Sep 2022 09:59:24 -0400
> 
> I tried to fix the documentation of `window-buffer-change-functions'
> to avoid passive voice, then discovered it was unclear in other ways.
> So I decided to rewrite it to make it clear.
> 
> In that attempt, I found it was so unclear that I could not be sure
> what the variable actually does.  I concluded ultimately that the
> problem was in the variable's meaning, not just in the documentation
> text.  If I understand it right, it uses the default (global?) value
> in one way and buffer-local values in another way.
> 
> This messes up the general rule for the meaning of buffer-local
> bindings, undermining the clarity of the Emacs Lisp language.  We
> should try hard to avoid ever doing that.  In this case I think it
> will not be hard.
> 
> I propose we replace it with two variables, each with a simple
> meaning.  They could be `buffer-window-change-functions' and
> `frame-buffer-change-functions'.

I don't think this justifies splitting this variable (which exists
since Emacs 27) into two.  Such a split will cause a lot of problems
for existing code, because this hooks are used in a lot of Lisp
programs.  Keeping obsolete aliases is a PITA and a maintenance
burden, so it doesn't really eliminate this downside.

This hook is conceptually simple: it is called when the correspondence
between buffers and their windows changes.  The functions in the local
value are called for individual windows only when the corresponding
buffer is involved in the change, and the global value is called once
for any frame where the correspondence changed for any buffer.  This
shouldn't be hard to explain, and any not-100%-clean design shouldn't
get in the way of documenting it clearly and in a way that Lisp
programs could use, including elimination of passive tense.

So I don't agree with the need to introduce two separate new
variables.  The downsides of such a split aren't justified by the
minor conceptual problems you mention.

I added Martin, who made this change back in Emacs 27, to the
discussion, in the hope that he could comment on the issue.

bug#51930: 27.2; Buffer-local functions? Buffers specified buffer-locally?

[Eli Zaretskii]

> From: Richard Stallman <rms@gnu.org>
> Cc: eliz@gnu.org, 51930@debbugs.gnu.org, larsi@gnus.org,
> 	drew.adams@oracle.com
> Date: Wed, 21 Sep 2022 23:11:52 -0400
> 
> ======================================================================
> A list of functions for redisplay to call when the assignment of
> buffers to windows has changed.  Each function takes a single
> argument.
> 
> This variable is peculiar in that its default value has one meaning
> and its actual value (normally buffer-local) has a different meaning.
> Redisplay uses both of these values, each in a different way.
> 
> For the actual (buffer-local) value, redisplay calls each function
> once for each window, with the window as argument, if that window has
> been created or assigned that buffer since the last time the window
> change functions were called.
> 
> For the default value, redisplay calls each function once for each
> frame, with the frame as argument, if at least one window on that
> frame has been added, deleted or assigned another buffer since the
> last time window change functions were called.
> ======================================================================
> 
> However, looking at the doc string of the variable seems to describe
> a different behavior, more like this:
> 
> ======================================================================
> A list of functions for redisplay to call when the assignment of
> buffers to windows has changed.  Each function takes a single
> argument.
> 
> Redisplay examines the global value of this variable, and calls each
> function once for each frame, with the frame as argument, if at least
> one window on that frame has been added, deleted or made to display a
> different buffer since the last time window change functions were
> called.
> 
> Redisplay also checks a buffer-local value of this variable in each
> buffer that's currenly displayed in a window.  If there is one,
> redisplay calls each function listed there for each window that
> displays the buffer in question, with the window as argument,
> @emph{if} the window has been created, or made to display that buffer,
> since the last time the window change functions were called.
> ======================================================================
> 
> Is this correct?  I can't tell from the text available.

The manual is more correct: the code goes through windows and invokes
these functions for a window if its buffer has a non-nil buffer-local
value of the variable.

Re: window-buffer-change-functions

[martin rudalics]

I think that both, this text

 > A list of functions for redisplay to call when the assignment of
 > buffers to windows has changed.  Each function takes a single
 > argument.
 >
 > Redisplay examines the global value of this variable, and calls each
 > function once for each frame, with the frame as argument, if at least
 > one window on that frame has been added, deleted or made to display a
 > different buffer since the last time window change functions were
 > called.
 >
 > Redisplay also checks a buffer-local value of this variable in each
 > buffer that's currenly displayed in a window.  If there is one,
 > redisplay calls each function listed there for each window that
 > displays the buffer in question, with the window as argument,
 > @emph{if} the window has been created, or made to display that buffer,
 > since the last time the window change functions were called.

and this one

 > This hook is conceptually simple: it is called when the correspondence
 > between buffers and their windows changes.  The functions in the local
 > value are called for individual windows only when the corresponding
 > buffer is involved in the change, and the global value is called once
 > for any frame where the correspondence changed for any buffer.  This
 > shouldn't be hard to explain, and any not-100%-clean design shouldn't
 > get in the way of documenting it clearly and in a way that Lisp
 > programs could use, including elimination of passive tense.

both describe well what this is hook is supposed to provide and should
be used to improve the original text.

 > So I don't agree with the need to introduce two separate new
 > variables.  The downsides of such a split aren't justified by the
 > minor conceptual problems you mention.

If we provided two separate new variables, we'd also have to split
'window-size-change-functions', 'window-state-change-functions' and
'window-selection-change-functions' into two.

I'd invite people to read the entire section 29.31 on window change
functions and in particular the part at the end that tries to explain
the common aspects of buffer-local and default/global values for all of
these hooks.

Thanks, martin

Re: window-buffer-change-functions

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

I'm glad to have contributed improved documentation for the current
behavior of window-buffer-change-functions, but that behavior violates
the abstraction of variable bindings.

A variable is supposed to have one value at any given time.  It might
be the default binding, or a something-local binding.  But regardless
of why that binding is current at any time, its value is _the value_
of the variable at that time.  The other bindings shouldn't affect
what the variable stands for when they are not current.

Special exceptions that undermine the meaning of a variable's value,
or any general design principle, cause conceptual confusion that will
get us in trouble.

-- 
Dr Richard Stallman (https://stallman.org)
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: window-buffer-change-functions

[Eli Zaretskii]

> From: Richard Stallman <rms@gnu.org>
> Cc: eliz@gnu.org, emacs-devel@gnu.org
> Date: Thu, 22 Sep 2022 23:19:45 -0400
> 
> A variable is supposed to have one value at any given time.  It might
> be the default binding, or a something-local binding.  But regardless
> of why that binding is current at any time, its value is _the value_
> of the variable at that time.  The other bindings shouldn't affect
> what the variable stands for when they are not current.
> 
> Special exceptions that undermine the meaning of a variable's value,
> or any general design principle, cause conceptual confusion that will
> get us in trouble.

I think I agree, but could you please explain why you think this
variable violates that principle?  Because I don't think I see that.

Re: window-buffer-change-functions

[Phil Sainty]

On 2022-09-23 15:19, Richard Stallman wrote:
> A variable is supposed to have one value at any given time.  It might
> be the default binding, or a something-local binding.  But regardless
> of why that binding is current at any time, its value is _the value_
> of the variable at that time.  The other bindings shouldn't affect
> what the variable stands for when they are not current.

Although the case in question is still unusual, it's worth noting that
most hooks might use both the buffer-local and default values when they
run, if both values are defined.  Quoting `add-hook':

     The optional fourth argument, LOCAL, if non-nil, says to modify
     the hook's buffer-local value rather than its global value.
     This makes the hook buffer-local, and it makes t a member of the
     buffer-local value.  That acts as a flag to run the hook
     functions of the global value as well as in the local value.

Therefore, in a majority of cases, running a hook with a buffer-local
value processes both the buffer-local list *and* the global list for
that variable.

As this behaviour is under the control of the buffer-local value,
it's still not the same as both values being used automatically for
two different purposes; but I just wanted to point out that there
has long been an established mechanism by which both the buffer-local
binding and the default binding of a hook variable are used together,
so the window hooks aren't unique in that regard.

The window hooks are different in other ways of course, but they are
reacting to window and frame changes rather than buffer changes, so
it probably wouldn't ever make sense for a buffer-local value to take
precedence over the default value for these hooks.  Splitting each of
them into two separate hooks wouldn't really gain anything in terms
of functionality then?


-Phil

Re: window-buffer-change-functions

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > Therefore, in a majority of cases, running a hook with a buffer-local
  > value processes both the buffer-local list *and* the global list for
  > that variable.

That's true -- but I contend that this is a clean variation of the
general mechanism.  Instead of "the buffer-local binding replaces the
default binding", we have "the buffer-local list's elements add to the
default list's elements."  This behavior is to the usual buffer-local
binding behavior, as advising a function is to redefining it.

That makes it clean.

What window-buffer-change-functions and such do is ad hoc.  The clean
and simple interface for this would be to have a frame functions list
and a window functions list.  Each one would be simple and clean.
What we have now is artificially packing two different lists into two
bindings of one variable.

-- 
Dr Richard Stallman (https://stallman.org)
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: window-buffer-change-functions

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > > Special exceptions that undermine the meaning of a variable's value,
  > > or any general design principle, cause conceptual confusion that will
  > > get us in trouble.

  > I think I agree, but could you please explain why you think this
  > variable violates that principle?  Because I don't think I see that.

I don't know how to explain it, because it is so blatant that I don't
see where the disagreement could be.
-- 
Dr Richard Stallman (https://stallman.org)
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)