* Custom dependencies (was: utf-translate-cjk-mode) [not found] ` <rzqadf6fr4h.fsf@albion.dl.ac.uk> @ 2003-04-04 15:19 ` Stefan Monnier 2003-04-04 19:42 ` Custom dependencies Kai Großjohann 2003-04-08 9:34 ` Custom dependencies (was: utf-translate-cjk-mode) Dave Love 0 siblings, 2 replies; 9+ messages in thread From: Stefan Monnier @ 2003-04-04 15:19 UTC (permalink / raw) Cc: emacs-devel [ 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 ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Custom dependencies 2003-04-04 15:19 ` Custom dependencies (was: utf-translate-cjk-mode) Stefan Monnier @ 2003-04-04 19:42 ` Kai Großjohann 2003-04-04 20:33 ` Stefan Monnier 2003-04-08 9:34 ` Custom dependencies (was: utf-translate-cjk-mode) Dave Love 1 sibling, 1 reply; 9+ messages in thread From: Kai Großjohann @ 2003-04-04 19:42 UTC (permalink / raw) "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. ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Custom dependencies 2003-04-04 19:42 ` Custom dependencies Kai Großjohann @ 2003-04-04 20:33 ` Stefan Monnier 2003-04-05 15:49 ` Kai Großjohann 0 siblings, 1 reply; 9+ messages in thread From: Stefan Monnier @ 2003-04-04 20:33 UTC (permalink / raw) Cc: emacs-devel > > - 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 ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Custom dependencies 2003-04-04 20:33 ` Stefan Monnier @ 2003-04-05 15:49 ` Kai Großjohann 2003-04-06 20:55 ` Stefan Monnier 0 siblings, 1 reply; 9+ messages in thread From: Kai Großjohann @ 2003-04-05 15:49 UTC (permalink / raw) Cc: emacs-devel "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. ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Custom dependencies 2003-04-05 15:49 ` Kai Großjohann @ 2003-04-06 20:55 ` Stefan Monnier 2003-04-07 9:05 ` Kai Großjohann 0 siblings, 1 reply; 9+ messages in thread From: Stefan Monnier @ 2003-04-06 20:55 UTC (permalink / raw) Cc: 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 ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Custom dependencies 2003-04-06 20:55 ` Stefan Monnier @ 2003-04-07 9:05 ` Kai Großjohann 0 siblings, 0 replies; 9+ messages in thread From: Kai Großjohann @ 2003-04-07 9:05 UTC (permalink / raw) Cc: emacs-devel "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. ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Custom dependencies (was: utf-translate-cjk-mode) 2003-04-04 15:19 ` Custom dependencies (was: utf-translate-cjk-mode) Stefan Monnier 2003-04-04 19:42 ` Custom dependencies Kai Großjohann @ 2003-04-08 9:34 ` Dave Love 2003-04-08 12:56 ` Custom dependencies Kai Großjohann 1 sibling, 1 reply; 9+ messages in thread From: Dave Love @ 2003-04-08 9:34 UTC (permalink / raw) Cc: emacs-devel "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? ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Custom dependencies 2003-04-08 9:34 ` Custom dependencies (was: utf-translate-cjk-mode) Dave Love @ 2003-04-08 12:56 ` Kai Großjohann 2003-04-08 18:35 ` Stefan Monnier 0 siblings, 1 reply; 9+ messages in thread From: Kai Großjohann @ 2003-04-08 12:56 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Custom dependencies 2003-04-08 12:56 ` Custom dependencies Kai Großjohann @ 2003-04-08 18:35 ` Stefan Monnier 0 siblings, 0 replies; 9+ messages in thread From: Stefan Monnier @ 2003-04-08 18:35 UTC (permalink / raw) Cc: emacs-devel > 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 ^ permalink raw reply [flat|nested] 9+ messages in thread
end of thread, other threads:[~2003-04-08 18:35 UTC | newest] Thread overview: 9+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- [not found] <rzqvfxvh7wj.fsf@albion.dl.ac.uk> [not found] ` <8465pvpnhy.fsf@lucy.is.informatik.uni-duisburg.de> [not found] ` <rzqadf6fr4h.fsf@albion.dl.ac.uk> 2003-04-04 15:19 ` Custom dependencies (was: utf-translate-cjk-mode) Stefan Monnier 2003-04-04 19:42 ` Custom dependencies Kai Großjohann 2003-04-04 20:33 ` Stefan Monnier 2003-04-05 15:49 ` Kai Großjohann 2003-04-06 20:55 ` Stefan Monnier 2003-04-07 9:05 ` Kai Großjohann 2003-04-08 9:34 ` Custom dependencies (was: utf-translate-cjk-mode) Dave Love 2003-04-08 12:56 ` Custom dependencies Kai Großjohann 2003-04-08 18:35 ` Stefan Monnier
Code repositories for project(s) associated with this external index https://git.savannah.gnu.org/cgit/emacs.git https://git.savannah.gnu.org/cgit/emacs/org-mode.git This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.