* Inconsistency in meaning of "user options" @ 2005-12-12 16:18 Richard M. Stallman 2005-12-12 22:23 ` Drew Adams 0 siblings, 1 reply; 8+ messages in thread From: Richard M. Stallman @ 2005-12-12 16:18 UTC (permalink / raw) Sometimes we use the term "user options" to mean "customizable variable" or "variable meant for the user to set". But sometimes we use it to mean "any settings you can customize", which includes faces as well. I think we should make this consistent. There is more than one way to do it; all of them will take work. The question is, which one is better? ^ permalink raw reply [flat|nested] 8+ messages in thread
* RE: Inconsistency in meaning of "user options" 2005-12-12 16:18 Inconsistency in meaning of "user options" Richard M. Stallman @ 2005-12-12 22:23 ` Drew Adams 2005-12-12 23:33 ` Lennart Borgman 2005-12-13 23:32 ` Richard M. Stallman 0 siblings, 2 replies; 8+ messages in thread From: Drew Adams @ 2005-12-12 22:23 UTC (permalink / raw) Sometimes we use the term "user options" to mean "customizable variable" or "variable meant for the user to set". But sometimes we use it to mean "any settings you can customize", which includes faces as well. I think we should make this consistent. There is more than one way to do it; all of them will take work. The question is, which one is better? We discussed this a while back, but I agree that it would be good to come to a conclusion. Are you proposing that we discuss and decide this _now_, and make the necessary changes before the 22.1 release? If so, here are a few thoughts: - "Option" means choice. All user settings involve choice, so they are all user options in this general sense. Another term for this is "user setting" or simply "setting". "Option" is usually better than setting to indicate something that can be changed at runtime. - If we chose to reserve "user option" for user-settable variables (those that have `*' as doc-string first char or are defined with defcustom), then we would have the least amount of work to do. This is because that is what "user option" has meant, historically (with perhaps a few more recent exceptions). In that case, since all faces are customizable, the terminology would be: 1) "user option or face" (all), 2) "customizable user option" (defcustom), 3) "user option" (which includes #2), and 4) "face". - If we decide to start from scratch, then the terms might be 1) "user option" (all), 2) "customizable user variable", 3) "user variable" (which includes #2), and 4) "face". - One problem with the previous choice is that it might not always be clear that "user option" includes faces, especially given our legacy terminology. If we want to be sure people understand that faces are included, we could say "user variable or face". In that case, the only difference between the two would be "option" vs "variable". - There is also the need to refer to non-user variables (all faces are user-settable). "Internal variable" is one possibility, but some such variables are not so internal. I would prefer "non-user variable" for this. - When there is a need to distinguish customizable from non-customizable user variables (or options), those terms are sufficient: "customizable" vs "non-customizable". On another subject, I think it's unfortunate that the terms "customize" and "customizable" have been appropriated for a particular kind of customization (using Custom buffers) - especially in an editor (++) that is all about customization (not Customization). It makes communicating about customization much more complex and confusing. It would be a lot better if Customize were called Foobar or Whatever. <Heresy> If we rework Customize substantially for Emacs 23 (which I hope we do), how about renaming Customize something else? </Heresy> Of course, if we intend to do that, we should not decide now upon terms like "customizable" (whateverable?). Nested cans of worm-eating worms... ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Inconsistency in meaning of "user options" 2005-12-12 22:23 ` Drew Adams @ 2005-12-12 23:33 ` Lennart Borgman 2005-12-13 0:02 ` Drew Adams 2005-12-13 23:32 ` Richard M. Stallman 1 sibling, 1 reply; 8+ messages in thread From: Lennart Borgman @ 2005-12-12 23:33 UTC (permalink / raw) Cc: emacs-devel Drew Adams wrote: > Sometimes we use the term "user options" to mean > "customizable variable" or "variable meant for the user to set". > But sometimes we use it to mean "any settings you can customize", > which includes faces as well. > > I think we should make this consistent. There is more than > one way to do it; all of them will take work. > The question is, which one is better? > >We discussed this a while back, but I agree that it would be good to come to >a conclusion. Are you proposing that we discuss and decide this _now_, and >make the necessary changes before the 22.1 release? > >If so, here are a few thoughts: > > - "Option" means choice. > > Why do we then have to distinguish between variables and faces? Does not option comprise both? If it does then I think option is a good term to use here. > - If we chose to reserve "user option" for user-settable variables (those >that have `*' as doc-string first char or are defined with defcustom), > > Do I misremember, was not those going to be converted to defcustoms, or? >On another subject, I think it's unfortunate that the terms "customize" and >"customizable" have been appropriated for a particular kind of customization >(using Custom buffers) - especially in an editor (++) that is all about >customization (not Customization). It makes communicating about >customization much more complex and confusing. It would be a lot better if >Customize were called Foobar or Whatever. > > That would maybe be good. Perhaps could we use these terms?: 1) user options 2) custom options (to be distinguished from "Custom options" ;-) I guess the meaning here is obvious, but just in case: 1 - those can not be set with Custom, 2 - those can be set with custom. ^ permalink raw reply [flat|nested] 8+ messages in thread
* RE: Inconsistency in meaning of "user options" 2005-12-12 23:33 ` Lennart Borgman @ 2005-12-13 0:02 ` Drew Adams 2005-12-13 0:23 ` Lennart Borgman 0 siblings, 1 reply; 8+ messages in thread From: Drew Adams @ 2005-12-13 0:02 UTC (permalink / raw) > - "Option" means choice. Why do we then have to distinguish between variables and faces? Because faces didn't exist when the term was coined for Emacs. Does not option comprise both? If it does then I think option is a good term to use here. Yes, that's what I said in the second alternative I proposed ("starting from scratch"). > - If we chose to reserve "user option" for user-settable > variables (those that have `*' as doc-string first char or > are defined with defcustom), Do I misremember, was not those going to be converted to defcustoms, or? Even if that were decided, it would not affect existing external libraries. The terminology we adopt should (also) address the case of non-customizable user variables. They exist; they will continue to exist in the future, unless we neuter `*'. Personally, I see nothing wrong with them, except that their existence adds more confusion to the Customize/customize mix. > On another subject, I think it's unfortunate that the terms > "customize" and "customizable" have been appropriated for a > particular kind of customization (using Custom buffers) - > especially in an editor (++) that is all about > customization (not Customization). It makes communicating about > customization much more complex and confusing. It would be a > lot better if Customize were called Foobar or Whatever. That would maybe be good. Perhaps could we use these terms?: 1) user options 2) custom options (to be distinguished from "Custom options" ;-) I guess the meaning here is obvious, but just in case: 1 - those can not be set with Custom, 2 - those can be set with custom. No, the meaning is not obvious, at least in American English. Something that is "custom" (e.g. a "custom motorcycle") is something that _has been_ customized. The term to use for customizable is "customizable", not "custom". It's also not clear to me what you gain by changing "Custom" to "custom", if your meaning of "custom" is "Custom" (can be set with Custom). My point was precisely to find some term that is different from "custom", to avoid confusion. ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Inconsistency in meaning of "user options" 2005-12-13 0:02 ` Drew Adams @ 2005-12-13 0:23 ` Lennart Borgman 2005-12-13 0:29 ` Drew Adams 2005-12-13 23:33 ` Richard M. Stallman 0 siblings, 2 replies; 8+ messages in thread From: Lennart Borgman @ 2005-12-13 0:23 UTC (permalink / raw) Cc: emacs-devel Drew Adams wrote: > That would maybe be good. Perhaps could we use these terms?: > > 1) user options > 2) custom options (to be distinguished from "Custom options" ;-) > > I guess the meaning here is obvious, but just in case: 1 - > those can not be set with Custom, 2 - those can be set with custom. > >No, the meaning is not obvious, at least in American English. Something that >is "custom" (e.g. a "custom motorcycle") is something that _has been_ >customized. The term to use for customizable is "customizable", not >"custom". > > Oh thanks, it is a bit hard with a foreign language. I would expect an option that had been changed to be called "customized" perhaps, but not "custom". easy-customizable option, e-customizable option? (it is more a joke...), custom-customizable option - too long, custom-enabled option, custom-setable option, defcustom option - we actually use this sometimes and I like it. But can the normal user understand that term? custom-enabled seems better to me then, but I do not know what that alludes to for you native english speakers. >It's also not clear to me what you gain by changing "Custom" to "custom", if >your meaning of "custom" is "Custom" (can be set with Custom). My point was >precisely to find some term that is different from "custom", to avoid >confusion. > It was just a joke. I suppose "Custom option" would mean one of those that you use to change the behaviour of Custom with. ^ permalink raw reply [flat|nested] 8+ messages in thread
* RE: Inconsistency in meaning of "user options" 2005-12-13 0:23 ` Lennart Borgman @ 2005-12-13 0:29 ` Drew Adams 2005-12-13 23:33 ` Richard M. Stallman 1 sibling, 0 replies; 8+ messages in thread From: Drew Adams @ 2005-12-13 0:29 UTC (permalink / raw) > Something that > is "custom" (e.g. a "custom motorcycle") is something that _has been_ > customized. The term to use for customizable is "customizable", not > "custom". Oh thanks, it is a bit hard with a foreign language. I would expect an option that had been changed to be called "customized" perhaps, but not "custom". "Customized" is correct; so is "custom". "Custom" is often used colloquially, especially for hobby things (cars, bikes...). I suppose "Custom option" would mean one of those that you use to change the behaviour of Custom with. I've been looking for those options! So much to change... ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Inconsistency in meaning of "user options" 2005-12-13 0:23 ` Lennart Borgman 2005-12-13 0:29 ` Drew Adams @ 2005-12-13 23:33 ` Richard M. Stallman 1 sibling, 0 replies; 8+ messages in thread From: Richard M. Stallman @ 2005-12-13 23:33 UTC (permalink / raw) Cc: drew.adams, emacs-devel >No, the meaning is not obvious, at least in American English. Something that >is "custom" (e.g. a "custom motorcycle") is something that _has been_ >customized. The term to use for customizable is "customizable", not >"custom". > > Oh thanks, it is a bit hard with a foreign language. I would expect an option that had been changed to be called "customized" perhaps, but not "custom". "Custom" as an adjective means "specialized for one party". The motorcycle may have been made to your own specifications; if so, it is a custom motorcycle, but it was not customized. It was custom-made. To "customize" an existing thing means to "change it to be special for one party". Thus, we speak about "customizing Emacs". To say a thing is "customized" means that it "has been changed to be special for one party." To say a thing is "customizable" means it can be changed to be special for one party. ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Inconsistency in meaning of "user options" 2005-12-12 22:23 ` Drew Adams 2005-12-12 23:33 ` Lennart Borgman @ 2005-12-13 23:32 ` Richard M. Stallman 1 sibling, 0 replies; 8+ messages in thread From: Richard M. Stallman @ 2005-12-13 23:32 UTC (permalink / raw) Cc: emacs-devel We discussed this a while back, but I agree that it would be good to come to a conclusion. Are you proposing that we discuss and decide this _now_, and make the necessary changes before the 22.1 release? Yes. These are problems in changes that I've made since Emacs 21, and we should fix them before it goes out. ^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2005-12-13 23:33 UTC | newest] Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2005-12-12 16:18 Inconsistency in meaning of "user options" Richard M. Stallman 2005-12-12 22:23 ` Drew Adams 2005-12-12 23:33 ` Lennart Borgman 2005-12-13 0:02 ` Drew Adams 2005-12-13 0:23 ` Lennart Borgman 2005-12-13 0:29 ` Drew Adams 2005-12-13 23:33 ` Richard M. Stallman 2005-12-13 23:32 ` Richard M. Stallman
Code repositories for project(s) associated with this public inbox https://git.savannah.gnu.org/cgit/emacs.git This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).