Re: Custom dependencies

[kai.grossjohann@gmx.net (Kai Großjohann)]

"Stefan Monnier" <monnier+gnu/emacs/pretest@rum.cs.yale.edu> writes:

> 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.

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.

I think it depends on the various variables what needs to be done
when such a change happens.

> 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.

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? ]]

> 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 :-)

> - 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
evaluated each time you look at the variable.  So such a feature
needs to be built in to the variable.  This has happened for
mode-line-format, for instance.

It seems that custom is the wrong place to look for a solution for
this: the problem happens when the variable is accessed.

-- 
A preposition is not a good thing to end a sentence with.