unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: martin rudalics <rudalics@gmx.at>
To: Matt Armstrong <matt@rfc20.org>,
	emacs-devel <emacs-devel@gnu.org>,
	Noam Postavsky <npostavs@gmail.com>
Subject: Re: "after" variable watchers
Date: Mon, 17 May 2021 18:41:09 +0200	[thread overview]
Message-ID: <1fef80fb-0b6f-14d9-e763-21ab9ecf652f@gmx.at> (raw)
In-Reply-To: <878s4dwgp8.fsf@rfc20.org>

 > I haven't seen vary many truly useful designs based on such a mechanism.
 > It would be good to understand why.
 >
 > I think the basic problem is that the "deeply nested fashion" you
 > mention is often quite complex, and many times ends up depending on
 > other variables that are not yet modified.
 >
 > Consider your example: what if the new value for `right-margin-width'
 > makes sense only after some other variables are also changed.  Say,
 > variables controlling fringe or scroll bar width, etc.  If those
 > variables are set by code after `right-margin-width' then the "valid
 > right-margin-width" predicate would reject the value even though it will
 > soon be valid.

No sane value will be ever rejected any more.  That's one of the major
clues of the new design.  Rather, the value will be stored as "nominal"
internally and get "realized" whenever that's possible.

 > What we end up with is a situation where not only the final state must
 > be valid (from the point of view of the watch function), but all
 > transient states too.

Right, if "valid" means "sane".  A `right-margin-width' of 500 columns
will be valid even if will never fit on your frame.

 > I have personally found systems like this to be
 > difficult to deal with.

A user will not have to care about transient and final states.  Every
state must be valid and none is the final one.  After you're through
with the changes cited above you may want to resize your frame and you
will end up in the next transient state.

 > The solution I most often I see is designs based on "dirty" state, where
 > some point in the future code is triggered to validate state state.  For
 > that I think the current watch mechanism is sufficient to track which
 > variables have changed?

Please read my answer to Eli.  Maybe it clarifies things a bit.  In
fact, the "after" variable watcher is needed to produce a "valid
transient state" which can be either displayed immediately or kept
pending until the next transient state has been produced.

martin



      reply	other threads:[~2021-05-17 16:41 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-05-17  8:27 "after" variable watchers martin rudalics
2021-05-17 10:23 ` Eli Zaretskii
2021-05-17 16:40   ` martin rudalics
2021-05-17 16:57     ` Eli Zaretskii
2021-05-18 15:10       ` martin rudalics
2021-05-20 13:46         ` Eli Zaretskii
2021-05-24  8:47           ` martin rudalics
2021-05-27 16:51             ` Eli Zaretskii
2021-06-06  7:42               ` martin rudalics
2021-05-17 18:36     ` Stefan Monnier
2021-05-17 18:45       ` Eli Zaretskii
2021-05-17 18:54         ` Stefan Monnier
2021-05-17 18:55           ` Stefan Monnier
2021-05-18 15:10       ` martin rudalics
2021-05-18 15:57         ` Stefan Monnier
2021-05-18 17:01           ` martin rudalics
2021-05-20 13:49             ` Eli Zaretskii
2021-05-24  8:48               ` martin rudalics
2021-05-27 16:53                 ` Eli Zaretskii
2021-05-17 14:57 ` Matt Armstrong
2021-05-17 16:41   ` martin rudalics [this message]

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=1fef80fb-0b6f-14d9-e763-21ab9ecf652f@gmx.at \
    --to=rudalics@gmx.at \
    --cc=emacs-devel@gnu.org \
    --cc=matt@rfc20.org \
    --cc=npostavs@gmail.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).