Jan Vroonhof writes: Jan> That's exactly what the customize properties are: Jan> 'saved-value = "value from an init file" 'customized-value = "value from Jan> user input during an xemacs session" Jan> The custom save variables stuff is fine. Indeed, Custom does already most of the job and has become THE prefered way to define a variable as a user option. I'm not claiming that we should undo this obviously. But do we have enough information with what we have now ? For instance, it might be interesting to have more details on the origin of the saved value: user init file (I consider it to be a saving), user option file, X resource ... Jan> Custom is not a setting method. It is _also_ a setting method. Fair enough. It's a lack of precision from my part. I agree that Custom is first a method for saving options, and additionally has a nice graphical interface for setting those options. Here I was talking about Custom as the interface part. Jan> Indeed. So who cares that the property is called. custom-type is Jan> perfectly allright. Yes, who cares how it's called. However, the fact that it's called 'custom-type is just a symptom of the fact that when custom was more or less implicitely designated as the new standard way to declare user options, some important issues, like how it would interact with existing stuff were not raised enough. Calling it 'custom-type says more than calling it 'option-type or even 'variable-type. It implicitely states that it is for custom, and hides the fact that any other package or variable modification method could use it. Don't think I'm of bad faith. I usually attach a great importance to words and I'm convinced they carry more meaning than what seems at a first glance.[1] Jan> There is no reason set-variable shouldn't use it (and even update Jan> 'customized-value too??). All right, we're beginning to get at it! That's exactly the kind of question I had hoped to raise with my message. But this question is far from being anecdotic IMHO. How is it that it comes up only now ? I did the port of most of the options menu to custom a long time ago. However, this question didn't came to my mind at that time, and I think it should have. You ask why set-variable couldn't even update 'customized-value and I think that is a very important question. Do we want set-variable to act as custom or do we want it to do something else ? If we want it to act like custom, we're saying something important: it can not only set the variable, but tell XEmacs to save it. That's why I was saying that it's important to make the distinction between setting and saving. Only after realizing that I began to understand that set-variable is actually part of the problem we're discussing. Personaly, I'm not very much for set-variable acting like custom. It's important to have a method for setting a variable that you KNOW you won't want to save. However, custom is missing a set-variable equivalent, that wouldn't need to display a heavy graphical interface. Jan> I think you just missed what custom is all about. Customize is a saving Jan> and typing method. I didn't miss it. I hope I'm clearer now. Footnotes: [1] It's completely off-topic, but in France, there's a debate on feminization of several words describing professions for instance. Historically, some professions were reserved for men which explains why nowadays we lack many feminin equivalents. -- / / _ _ Didier Verna http://www.inf.enst.fr/~verna/ - / / - / / /_/ / E.N.S.T. INF C201.1 mailto:verna＠inf.enst.fr /_/ / /_/ / /__ / 46 rue Barrault Tel. (33) 01 45 81 73 46 75634 Paris cedex 13 Fax. (33) 01 45 81 31 19