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

[Dave Love <d.love@dl.ac.uk>]

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