[Top][All Lists]

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

Re: Custom dependencies

From: Stefan Monnier
Subject: Re: Custom dependencies
Date: Fri, 04 Apr 2003 15:33:58 -0500

> > - 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.
> Agreed.
> > Kai suggests turn A off and back on, but you seem object to it.
> No, I suggest to turn utf-translate-cjk-mode off then back on.

Huh?  A is utf-translate-cjk-mode, so I don't understand what's
the difference between what I say and what you say.

> > 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.
> I disagree about this.
> Suppose somebody turns on utf-translate-cjk-mode (via custom or
> Lisp), then time passes, then they do M-x set-language-environment RET.
> At that time, something special needs to happen.

It depends on whether you want the dependency to be handled in
elisp or only in custom.  As someone who only uses elisp to
configure my Emacs, I wouldn't mind if the dependency handling only
worked in custom (as long as the docstrings make it clear enough
for me to DTRT in elisp if I care to).

> utf-translate-cjk-mode could add stuff to a
> language-environment-changed-hook, then set-language-environment
> could call that hook.  This is still a specific solution, not a
> general one.
> [[ Later on:  Oh, I see that there is such a thing!  It seems to be
> called set-language-environment-hook.  Well.  That seems to be the
> solution, doesn't it? ]]

That sounds good in the present case, but the discussion is
about the general case.  Of course, maybe we don't need to handle
the general case because it's too infrequent ?

> > Still, how should custom know that turning the thing off&on is the
> > right way to refresh A's setting after B was changed ?
> It can't.  Unless we tell it.  And the code will depend on the
> combination of A and B, there will be no general function that will
> do the right thing.  (Except, perhaps, run-hooks -- but that's
> cheating :-)

Maybe we can simply say that custom will call the :set function
again and it's the :set function to make sure that it will
refresh things as needed.

> > - 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.
> You mean that you could set next-screen-context-lines to `ten percent
> of the window height'?  That doesn't make sense: it needs to be

Custom currently allows such things.  Obviously, it can't work
right unless B is some sort of global variable.


reply via email to

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