[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Custom dependencies (was: utf-translate-cjk-mode)

From: Stefan Monnier
Subject: Custom dependencies (was: utf-translate-cjk-mode)
Date: Fri, 04 Apr 2003 10:19:36 -0500

[ Since the :set-after thingy is now (hopefully) finally properly
  handled by define-minor-mode, I assume that you now agree that Kai's
  change was good. ]
> > set-language-environment could holler if utf-translate-cjk-mode was
> > set when it is called.  That might be useful in some way or other.
> > Or it could look if utf-translate-cjk-mode is on, and if so, turn it
> > off then on again.  That would exhibit more dwimishness.
> I think that would be wrong, apart from being very unclean.  Custom
> supports at least the declaration of dependencies, even if it doesn't
> use them fully.  Why do you want to avoid that, presumably at the
> expense of the less sophisticated users Custom is particularly aimed at?

I think the issue of dependencies is important, so let's try and improve
it, rather than keep working around it.  Especially since you
mention that it is crucial in order to customize calendar properly.

I see two different cases:

- The case as above where variable A has a non-trivial :set function
  which depends on variable B, so that when B is changed something
  should be done to A.
  It seems that the :set-after thingy is a good way to specify the
  dependency, but it doesn't describe what should be done to A
  when B changes.  Kai suggests turn A off and back on, but you
  seem object to it.  I believe that you object only to
  set-language-environment doing it, not to the off&on thing: it
  should be done by custom without set-language-environment
  (or current-language-environment for that matter) knowing anything
  about utf-translate-cjk-mode.
  Still, how should custom know that turning the thing off&on is
  the right way to refresh A's setting after B was changed ?

- The case where A is set to "the value of E" where E is a sexp
  that refers to B.  In such a case, the dependency is not part of
  A but of A's current setting, so :set-after is not a good solution.
  I don't know how custom could find out (or be told about) such
  dependencies.  OTOH, "what to do when B changes" is trivial to answer
  this time.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]