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

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

[Stefan Monnier]

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


	Stefan

Re: Custom dependencies

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

Re: Custom dependencies

[Stefan Monnier]

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


	Stefan

Re: Custom dependencies

[Kai Großjohann]

"Stefan Monnier" <monnier+gnu/emacs@rum.cs.yale.edu> 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.

Re: Custom dependencies

[Stefan Monnier]

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

You don't understand: the expression is evaluated once and for all
when setting the variable.  Which is why dependencies might need to
be handled: to reset the var when things it refers to are changed.


	Stefan

Re: Custom dependencies

[Kai Großjohann]

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

> You don't understand: the expression is evaluated once and for all
> when setting the variable.  Which is why dependencies might need to
> be handled: to reset the var when things it refers to are changed.

Oh, boy, I was quite stubborn-headed, wasn't I.  Okay, now you got it
through my thick skull.

And now I understand the remark why :set-after won't work.  But it
seems that in this case, Custom itself could just follow the chain of
symbols, couldn't it?
-- 
A preposition is not a good thing to end a sentence with.

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

[Dave Love]

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

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

Sure (but not the rationale).

> I think the issue of dependencies is important, so let's try and improve
> it, rather than keep working around it.

Is there much attempt to work around it?

> Especially since you
> mention that it is crucial in order to customize calendar properly.

I think it's only really important if the current system of options is
maintained, but I don't know how much trouble it would cause to change
the currently-defined options.  The problem there is the multiple
levels of customized options, such that if I want to default things
appropriate to the locale, it's a real mess in ways I can't remember
the details of.

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

I think it does.  A should be re-set from its current value, since
something it depends on has changed.  Are there cases in which that
would be wrong?

>   Kai suggests turn A off and back on, but you
>   seem object to it.

I don't remember that, and it's not anything I thought I was objecting
to.  It's not a question of off and on in this case anyhow -- the
state that changes is the contents of a hash table.

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

Yes, if I understand correctly.

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

That's strictly true, but in most cases I can think of, it is the
right thing.  You'd have :set-after's for the Custom options which are
`usually' involved in E -- not strictly right, but unlikely to cause
trouble, I guess.

This probably means that the customization of those options isn't done
the way it should be, i.e. A shouldn't really be set with `defcustom'
but in some new way which is also aware of Custom's dependency
information.  (I haven't thought very much about implementing such a
thing, but I've often run into this issue.)

Take `display-time-string-forms' as an example that I recently worked
on (rather surprised that people could live with the distraction in
the new about-face mode line).  It's unlikely that a naive Custom user
would want to mess with the sexp as such, and probably unlikely that
anyone would unless they were adding new options.  I'd expect them
just to set `display-time-use-mail-icon' &c.  If
`display-time-string-forms' was re-set when
`display-time-use-mail-icon' & al were set, it would be less confusing
for users and the mode-line update could be more efficient.

Does that make sense?

Re: Custom dependencies

[Kai Großjohann]

Dave Love <d.love@dl.ac.uk> writes:

> "Stefan Monnier" <monnier+gnu/emacs/pretest@rum.cs.yale.edu> 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.
>
> I think it does.  A should be re-set from its current value, since
> something it depends on has changed.  Are there cases in which that
> would be wrong?

So, let's see.  We have (defcustom A ... :set-after '(B) ... :set
...something.long.here...).  And Dave suggests to call the :set
function from A after B has changed.  So whenever a variable X is
changed, we have to look through all other variables Y to see if they
mention X in the :set-after list.

>>   Kai suggests turn A off and back on, but you seem object to it.
>
> I don't remember that, and it's not anything I thought I was objecting
> to.  It's not a question of off and on in this case anyhow -- the
> state that changes is the contents of a hash table.

My thinking was as follows: (utf-translate-cjk-mode -1) clears the
hash table so that CJK unification is not done.  A subsequent
(utf-translate-cjk-mode 1) statement would then look at
current-language-environment and populate the hash table accordingly.

Of course, it is better to just populate the hash table in the right
way, without clearing it first.

>>   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.
>
> Yes, if I understand correctly.

So to look through all variables Y to see if their :set-after list
mentions X, and if so, to call the :set function?

That's a good idea.

(It would be nice to be able to do without the (custom-set-variables
...) block that's now used by Customize, because of the conditionals
I mentioned.)
-- 
A preposition is not a good thing to end a sentence with.

Re: Custom dependencies

[Stefan Monnier]

> So, let's see.  We have (defcustom A ... :set-after '(B) ... :set
> ...something.long.here...).  And Dave suggests to call the :set
> function from A after B has changed.  So whenever a variable X is
> changed, we have to look through all other variables Y to see if they
> mention X in the :set-after list.

No need for a "global search": you just need to do

	(push 'A (get 'B 'custom-reset-after-update))

when evaluating A's defcustom.

> My thinking was as follows: (utf-translate-cjk-mode -1) clears the
> hash table so that CJK unification is not done.  A subsequent
> (utf-translate-cjk-mode 1) statement would then look at
> current-language-environment and populate the hash table accordingly.

(utf-translate-cjk-mode 1) might also begin by clearing the hash-table.
Some minor modes try to optimize the case where "the mode was already
ON", but I think it's generally cleaner and more robust not to try and
be clever.


	Stefan