Re: Custom dependencies

[Kai Großjohann]

"Stefan Monnier" <monnier+gnu/address@hidden> writes:

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

It seemed to me that you are talking about some general case:
whenever there are some options A and B that are dependent, you were
suggesting to take a specific action (frob one of them twice).

I was only talking about this specific case, only about
utf-translate-cjk-mode and the language environment, not about any
other option.  I have no idea what's the right thing to do about some
other dependent pair of options.

Maybe I misunderstood you.

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

Well, in this specific case, one of the options can be changed
interactively.  IMVHO it would be useful for changing the language
environment to also change the cjk translation tables appropriately.

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

That might work.  (But only for Customize users.)

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

But how does Custom change the code that's used to *access* a
variable?

I'm getting confused I think.

> Obviously, it can't work right unless B is some sort of global
> variable.

You mean, the window height isn't a variable?  Hm.  Yes.  I couldn't
think of another example.

Can you think of another example, so that we have something concrete
to discuss?
-- 
A preposition is not a good thing to end a sentence with.