* window-buffer-change-functions [not found] ` <7110e0330e878c144a6364a8e6ad651c@webmail.orcon.net.nz> @ 2022-09-21 13:59 ` Richard Stallman 2022-09-21 16:22 ` [External] : window-buffer-change-functions Drew Adams 2022-09-22 6:21 ` window-buffer-change-functions Eli Zaretskii 0 siblings, 2 replies; 9+ messages in thread From: Richard Stallman @ 2022-09-21 13:59 UTC (permalink / raw) To: emacs-devel [[[ 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) ^ permalink raw reply [flat|nested] 9+ messages in thread
* RE: [External] : window-buffer-change-functions 2022-09-21 13:59 ` window-buffer-change-functions Richard Stallman @ 2022-09-21 16:22 ` Drew Adams 2022-09-22 6:21 ` window-buffer-change-functions Eli Zaretskii 1 sibling, 0 replies; 9+ messages in thread From: Drew Adams @ 2022-09-21 16:22 UTC (permalink / raw) To: rms@gnu.org, emacs-devel@gnu.org I guess this is somewhat related to bug #51930 (which is only about the doc). https://debbugs.gnu.org/cgi/bugreport.cgi?bug=51930 ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: window-buffer-change-functions 2022-09-21 13:59 ` window-buffer-change-functions Richard Stallman 2022-09-21 16:22 ` [External] : window-buffer-change-functions Drew Adams @ 2022-09-22 6:21 ` Eli Zaretskii 2022-09-22 9:44 ` window-buffer-change-functions martin rudalics 1 sibling, 1 reply; 9+ messages in thread From: Eli Zaretskii @ 2022-09-22 6:21 UTC (permalink / raw) To: Richard Stallman, martin rudalics; +Cc: emacs-devel > 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. ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: window-buffer-change-functions 2022-09-22 6:21 ` window-buffer-change-functions Eli Zaretskii @ 2022-09-22 9:44 ` martin rudalics 2022-09-23 3:19 ` window-buffer-change-functions Richard Stallman 0 siblings, 1 reply; 9+ messages in thread From: martin rudalics @ 2022-09-22 9:44 UTC (permalink / raw) To: Eli Zaretskii, Richard Stallman; +Cc: emacs-devel 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 ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: window-buffer-change-functions 2022-09-22 9:44 ` window-buffer-change-functions martin rudalics @ 2022-09-23 3:19 ` Richard Stallman 2022-09-23 6:12 ` window-buffer-change-functions Eli Zaretskii 2022-09-23 11:13 ` window-buffer-change-functions Phil Sainty 0 siblings, 2 replies; 9+ messages in thread From: Richard Stallman @ 2022-09-23 3:19 UTC (permalink / raw) To: martin rudalics; +Cc: eliz, emacs-devel [[[ 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) ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: window-buffer-change-functions 2022-09-23 3:19 ` window-buffer-change-functions Richard Stallman @ 2022-09-23 6:12 ` Eli Zaretskii 2022-09-24 2:43 ` window-buffer-change-functions Richard Stallman 2022-09-23 11:13 ` window-buffer-change-functions Phil Sainty 1 sibling, 1 reply; 9+ messages in thread From: Eli Zaretskii @ 2022-09-23 6:12 UTC (permalink / raw) To: rms; +Cc: rudalics, emacs-devel > 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. ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: window-buffer-change-functions 2022-09-23 6:12 ` window-buffer-change-functions Eli Zaretskii @ 2022-09-24 2:43 ` Richard Stallman 0 siblings, 0 replies; 9+ messages in thread From: Richard Stallman @ 2022-09-24 2:43 UTC (permalink / raw) To: Eli Zaretskii; +Cc: rudalics, emacs-devel [[[ 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) ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: window-buffer-change-functions 2022-09-23 3:19 ` window-buffer-change-functions Richard Stallman 2022-09-23 6:12 ` window-buffer-change-functions Eli Zaretskii @ 2022-09-23 11:13 ` Phil Sainty 2022-09-24 2:43 ` window-buffer-change-functions Richard Stallman 1 sibling, 1 reply; 9+ messages in thread From: Phil Sainty @ 2022-09-23 11:13 UTC (permalink / raw) To: rms; +Cc: martin rudalics, eliz, emacs-devel 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 ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: window-buffer-change-functions 2022-09-23 11:13 ` window-buffer-change-functions Phil Sainty @ 2022-09-24 2:43 ` Richard Stallman 0 siblings, 0 replies; 9+ messages in thread From: Richard Stallman @ 2022-09-24 2:43 UTC (permalink / raw) To: Phil Sainty; +Cc: rudalics, eliz, emacs-devel [[[ 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) ^ permalink raw reply [flat|nested] 9+ messages in thread
end of thread, other threads:[~2022-09-24 2:43 UTC | newest] Thread overview: 9+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- [not found] <SJ0PR10MB54886AFA7B33CF1E43E2E013F39A9@SJ0PR10MB5488.namprd10.prod.outlook.com> [not found] ` <83o86hyild.fsf@gnu.org> [not found] ` <877d1ycbom.fsf@gnus.org> [not found] ` <SJ0PR10MB548895C6693206D88C719E60F34C9@SJ0PR10MB5488.namprd10.prod.outlook.com> [not found] ` <835yhivx39.fsf@gnu.org> [not found] ` <SJ0PR10MB5488AA81BBFCC4B4CE2D31B4F34C9@SJ0PR10MB5488.namprd10.prod.outlook.com> [not found] ` <83v8piuh5k.fsf@gnu.org> [not found] ` <SJ0PR10MB54887366A66613D1189EC466F34C9@SJ0PR10MB5488.namprd10.prod.outlook.com> [not found] ` <2f85eda92184de27e10572e6b2320885@webmail.orcon.net.nz> [not found] ` <83pmfpv4fs.fsf@gnu.org> [not found] ` <7110e0330e878c144a6364a8e6ad651c@webmail.orcon.net.nz> 2022-09-21 13:59 ` window-buffer-change-functions Richard Stallman 2022-09-21 16:22 ` [External] : window-buffer-change-functions Drew Adams 2022-09-22 6:21 ` window-buffer-change-functions Eli Zaretskii 2022-09-22 9:44 ` window-buffer-change-functions martin rudalics 2022-09-23 3:19 ` window-buffer-change-functions Richard Stallman 2022-09-23 6:12 ` window-buffer-change-functions Eli Zaretskii 2022-09-24 2:43 ` window-buffer-change-functions Richard Stallman 2022-09-23 11:13 ` window-buffer-change-functions Phil Sainty 2022-09-24 2:43 ` window-buffer-change-functions Richard Stallman
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).