Re: "after" variable watchers

[Eli Zaretskii <eliz@gnu.org>]

> Cc: npostavs@gmail.com, emacs-devel@gnu.org
> From: martin rudalics <rudalics@gmx.at>
> Date: Mon, 17 May 2021 18:40:09 +0200
> 
>  > But the watcher function already gets the new value, so why do we need
>  > to be able to call it after the variable's value was changed?
> 
> Because knowing the new value in the watch function is of no practical
> use.  I'd have to pass it down to all functions called directly or
> indirectly by the watch function that make use of that value.

Sorry, I don't understand.  I really don't, not even after reading
your explanations.  (Assuming I understood the explanations: they seem
to mix what you intend to do with this "after-watcher" and what you
would have needed with the current watcher machinery, so it's
difficult to figure out which is which.)

Perhaps taking a single example and explaining how would this work
with today's watchers and with the feature you want to install could
help me understand.

>  > In general, this is a debugging feature, while you seem to be
>  > describing a use case where the watcher will be a constant part of an
>  > implementation of some feature, is that right?
> 
> Right.  In the mold of your `add-variable-watcher' at the end of
> frame.el.

So if I remove those, you will retract this proposal?

And note that the analogy is incomplete at best: the watchers in
frame.el watch _variables_ that we used to have forever, so making
them modifiable only via accessor functions would be a breaking
change.  Whereas you are talking about stuff which is done by
functions already.

>  > First, I'd like to better understand the need for this.
> 
> First, it's useful for having a change in a buffer's decorations take
> effect immediately.  So we get rid of things like
> 
>    Setting this variable does not take effect until a new buffer is displayed
>    in a window.  To make the change take effect, call ‘set-window-buffer’.

I think this could be a step in the wrong direction.  It might be
easier for users, but it makes it harder for us to develop Emacs in
the long run, for example if we want more threading.  That's because
all those global and buffer-local variables are part of the huge
global state we have, and that gets in the way of some features.

> And finally we would get rid of the present mixture of errors thrown at
> the user and that of changes that are silently ignored whenever a
> decoration does not fit.  A user then can set the nominal width of the
> right margin to some arbitrary number.  When the window is large enough
> to accommodate it, it will be displayed that way.  When the window gets
> too small, it will be temporarily clipped or skipped.

So we get silent fixes for all of them?  Not sure this is an
improvement.  I think we already had complaints about silently
"fixing" the decorations as we see fit.