* [drew.adams@oracle.com: Info on define-minor-mode - :init-value or :initial-value?] @ 2005-07-27 14:57 Richard M. Stallman 2005-07-27 16:04 ` Luc Teirlinck 0 siblings, 1 reply; 21+ messages in thread From: Richard M. Stallman @ 2005-07-27 14:57 UTC (permalink / raw) Would someone please DTRT and then respond? ------- Start of forwarded message ------- From: "Drew Adams" <drew.adams@oracle.com> To: "Emacs-Pretest-Bug" <emacs-pretest-bug@gnu.org> Date: Tue, 26 Jul 2005 11:20:46 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Brightmail-Tracker: AAAAAQAAAAI= X-Whitelist: TRUE Subject: Info on define-minor-mode - :init-value or :initial-value? X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.63 Is the keyword :init-value or :initial-value? The explanation uses the former, but the example uses the latter. In GNU Emacs 22.0.50.1 (i386-mingw-nt5.1.2600) of 2005-06-26 on NONIQPC X server distributor `Microsoft Corp.', version 5.1.2600 configured using `configure --with-gcc (3.3) --cflags -I../../jpeg-6b-3/include -I../../libpng-1.2.8/include -I../. ./tiff-3.6.1-2/include -I../../xpm-nox-4.2.0/include -I../../zlib-1.2.2/incl ude' _______________________________________________ Emacs-pretest-bug mailing list Emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug ------- End of forwarded message ------- ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [drew.adams@oracle.com: Info on define-minor-mode - :init-value or :initial-value?] 2005-07-27 14:57 [drew.adams@oracle.com: Info on define-minor-mode - :init-value or :initial-value?] Richard M. Stallman @ 2005-07-27 16:04 ` Luc Teirlinck 2005-07-28 16:58 ` Stefan Monnier 0 siblings, 1 reply; 21+ messages in thread From: Luc Teirlinck @ 2005-07-27 16:04 UTC (permalink / raw) Cc: emacs-devel Richard Stallman wrote: Would someone please DTRT and then respond? For the moment, I just replaced the incorrect keyword :initial-value in the example with :init-value. However, probably somewhat more extensive changes are needed. The example (now) does: :init-value nil But this is redundant, as the default :init-value is nil anyway. So it probably just should be deleted. There is more. You can not specify a non-nil :init-value, unless either the minor mode is enabled by just setting the variable or unless you do something extra. That something extra is to preload the file containing the define-minor-mode before startup.el and then using `custom-reevaluate-setting in startup.el (for files included with the Emacs distribution) or to call the minor mode function near the end of the file (for files not included with the Emacs distribution). We could either document these requirements in the Elisp manual and the define-minor-mode docstring or change define-minor-mode so that these requirements are no longer necessary. The latter requires changes which Stefan probably would not like. For instance it would mean that the call to `define-minor-mode' would need to be delayed until after all functions used by the minor mode function have been defined (but only for define-minor-mode's with a non-nil :init-value). Sincerely, Luc. ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [drew.adams@oracle.com: Info on define-minor-mode - :init-value or :initial-value?] 2005-07-27 16:04 ` Luc Teirlinck @ 2005-07-28 16:58 ` Stefan Monnier 2005-07-28 17:43 ` [drew.adams@oracle.com: Info on define-minor-mode - :init-valueor :initial-value?] Drew Adams 2005-07-29 1:48 ` [drew.adams@oracle.com: Info on define-minor-mode - :init-value or :initial-value?] Luc Teirlinck 0 siblings, 2 replies; 21+ messages in thread From: Stefan Monnier @ 2005-07-28 16:58 UTC (permalink / raw) Cc: rms, emacs-devel > There is more. You can not specify a non-nil :init-value, unless > either the minor mode is enabled by just setting the variable or > unless you do something extra. In what way is this a limitation? I.e. if you don't use define-minor-mode, how would you do it differently? [ I don't mean to say that "manual" code can't do it differently, but that if it does it differently, it'll most likely break the convention that just loading a file shouldn't make any visible changes. ] Stefan ^ permalink raw reply [flat|nested] 21+ messages in thread
* RE: [drew.adams@oracle.com: Info on define-minor-mode - :init-valueor :initial-value?] 2005-07-28 16:58 ` Stefan Monnier @ 2005-07-28 17:43 ` Drew Adams 2005-07-29 2:56 ` Luc Teirlinck 2005-07-29 15:59 ` Stefan Monnier 2005-07-29 1:48 ` [drew.adams@oracle.com: Info on define-minor-mode - :init-value or :initial-value?] Luc Teirlinck 1 sibling, 2 replies; 21+ messages in thread From: Drew Adams @ 2005-07-28 17:43 UTC (permalink / raw) For the moment, I just replaced the incorrect keyword :initial-value in the example with :init-value. Thanks. > There is more. You can not specify a non-nil :init-value, unless > either the minor mode is enabled by just setting the variable or > unless you do something extra. In what way is this a limitation? I.e. if you don't use define-minor-mode, how would you do it differently? [ I don't mean to say that "manual" code can't do it differently, but that if it does it differently, it'll most likely break the convention that just loading a file shouldn't make any visible changes. ] I don't know how you'll decide to handle this, but I agree with Luc that it is confusing to set the :init-value to, say, `t' and then not see that initial value be effective. I did this recently, in fact. I saw the mode name appear in the mode-line after loading the file, saw that the mode variable was indeed `t', and was confused that the mode was not actually turned on, in spite of the mode-line indication and the variable value. Not good, in terms of user interface. This is not very clear to me, I admit, so ignore my comments if they are off-base. IIUC, users creating a library with a define-minor-mode that has a non-nil :init-value will need to do something like the following at the end of the library (otherwise, the lighter and mode variable will indicate that the mode is on after loading, but it is not really on): (if foo-mode (foo-mode 1)) If this is correct, couldn't this be made part of the define-minor-mode macro - say, to execute this code automatically after loading the library? If my understanding is correct, but such automatic treatment is not a good idea, shouldn't this `(if foo-mode (foo-mode 1))' cliche be documented as a guideline? I found it after 1) reading Luc's email and 2) grepping the Lisp directory to see how other libraries dealt with this issue. At the least, if nothing special is done to treat non-nil :init-value, and users need to do something additional themselves, then shouldn't the Info doc show an example with non-nil :init-value, instead of the current example using nil? WRT the guideline of "loading must not change anything" - I agree, but I think that turning on a minor mode is usually relatively benign, because it can be turned off easily. Users loading a library that defines a minor mode will not be shocked if the mode is turned on by default, if the logical initial value to use is something other than nil. Otherwise, if we're going to be rigid about this guideline (perhaps there are good reasons to do that, even in this case), then maybe we should just get rid of :init-value and have the initial value always be nil - that is, make users of a library turn on the minor mode explicitly. That would not be my preference, but it would at least avoid confusion. ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [drew.adams@oracle.com: Info on define-minor-mode - :init-valueor :initial-value?] 2005-07-28 17:43 ` [drew.adams@oracle.com: Info on define-minor-mode - :init-valueor :initial-value?] Drew Adams @ 2005-07-29 2:56 ` Luc Teirlinck 2005-07-30 23:44 ` Richard M. Stallman 2005-07-29 15:59 ` Stefan Monnier 1 sibling, 1 reply; 21+ messages in thread From: Luc Teirlinck @ 2005-07-29 2:56 UTC (permalink / raw) Cc: emacs-devel Drew Adams wrote: WRT the guideline of "loading must not change anything" - I agree, but I think that turning on a minor mode is usually relatively benign, because it can be turned off easily. Users loading a library that defines a minor mode will not be shocked if the mode is turned on by default, if the logical initial value to use is something other than nil. Otherwise, if we're going to be rigid about this guideline (perhaps there are good reasons to do that, even in this case), Emacs is completely inconsistent in how well it follows these guidelines. The _default_ :initialize function is custom-initialize-reset. That means that whenever a file containing a defcustom with a :set function is loaded, that :set function is called _even_ if the user customized the variable outside Custom, possibly in an attempt to avoid the :set function. In vain. The `custom-initialize-reset' bully will force the :set function on the user anyway. This has repeatedly caused me (and other people) problems in practice. We have systematically dealt with these problems on a one by one basis by overriding the default with an explicit, more polite, :initialize function for those defcustoms for which problems were reported. But additional problems keep popping up on a regular basis (see the `fringe-indicators' thread). The problems are often not that easy to trace down to custom-initialize-reset, because they occur when a file is loaded and for instance Custom loads tons of files behind the user's back. The reason for picking `custom-initialize-reset' as the default are autoloaded defcustoms with a :set function. But I believe that there _must_ be other ways to deal with such defcustoms than the bullyish custom-initialize-reset. A second :initialize function is custom-initialize-set. That one only calls the :set function if the variable is still unbound. This means that, if nothing else, the user can avoid the :set function by setting the variable outside Custom in his .emacs file. (For preloaded defcustoms, the user can undo the effects of the :set function in his .emacs file.) For non-preloaded defcustoms, even setting the variable to its standard value avoids calling the :set function, which could be useful, if you do not want the :set function to set a timer, hide some text, make some text read-only or perform all kind of other "courtesies" that :set functions like to do. On the other hand, the only :set function considered safe for minor modes is custom-initialize-default, which _never_ calls the :set function on initialization. This is completely inconsistent as the minor-mode :set functions are usually benign compared to some other :set functions that are out there. (See `fringe-indicators' for a really bad example of :set function abuse.) Actually, the standard :set function of define-minor-mode is one of the few classes of functions for which even custom-initialize-reset would be safe. So on the one hand I have trouble convincing people that we should try to get rid (after the release) of custom-initialize-reset by finding another solution for the autoload problem and on the other hand, I have trouble convincing Stefan that the _much_ more benign custom-initialize-set can be safe for minor modes that are natural to enable by default. Sincerely, Luc. ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [drew.adams@oracle.com: Info on define-minor-mode - :init-valueor :initial-value?] 2005-07-29 2:56 ` Luc Teirlinck @ 2005-07-30 23:44 ` Richard M. Stallman 2005-07-31 0:43 ` Luc Teirlinck 2005-07-31 1:02 ` Luc Teirlinck 0 siblings, 2 replies; 21+ messages in thread From: Richard M. Stallman @ 2005-07-30 23:44 UTC (permalink / raw) Cc: drew.adams, emacs-devel The _default_ :initialize function is custom-initialize-reset. That means that whenever a file containing a defcustom with a :set function is loaded, that :set function is called That seems like the right thing to me. If the user set the variable, he probably wanted to control the mode. _even_ if the user customized the variable outside Custom, possibly in an attempt to avoid the :set function. So what? One can't please everybody. This has repeatedly caused me (and other people) problems in practice. If you describe these problems, we could think about whether they are worth solving by changing this mechanism. However, if the problems only occur with a few particularly troublesome variables, it would be easier to deal with them one by one. hand, I have trouble convincing Stefan that the _much_ more benign custom-initialize-set can be safe for minor modes that are natural to enable by default. It seems plausible to me. don't know how you'll decide to handle this, but I agree with Luc that it is confusing to set the :init-value to, say, `t' and then not see that initial value be effective. I agree completely. Stefan wrote: > (if foo-mode (foo-mode 1)) This will turn on the minor mode if you happen to browse the corresponding customize group (because Custom will then load the file). I.e. it'd be a bug. Consider minor modes that work in the classical way: just setting the variable enables the mode, and no :set-function is needed. If the default value is t, just loading the file will enable the mode. What this means is that a minor mode's default value should never be t unless t is a harmless value for it. Once we decide that, there's no particular problem about :set functions. Regardless of whether the minor mode takes effect through a :set function or just by setting the variable, either way, the default value should be nil, unless for specific reasons t is harmless. Therefore, it is ok to run the :set function when the minor mode code is loaded. It is ok to use custom-initialize-reset for them. FWIW, that's OK by me. In the user doc (Elisp), we should say "this is how you create a minor mode..." and include the bit about (if foo-mode (foo-mode 1)) for non-nil init value. That is apparently an integral part of coding a minor mode with a non-nil init value. If so, this should not be mentioned only as an afterthought in an explanation of one of the examples. If we can't arrange to make just the defcustom do the job, documenting this method is ok with me. Perhaps we should document a simple way and a complex way. The simple way is that it all gets done by the :set function when the defcustom's expansion is executed. That requires putting the defcustom after the minor mode function and generating a defvar before the function. You'd use custom-initialize-reset. For cases which are more complex, you'd use custom-initialize-default and then write (if foo-mode (foo-mode 1)) at the end of the file. ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [drew.adams@oracle.com: Info on define-minor-mode - :init-valueor :initial-value?] 2005-07-30 23:44 ` Richard M. Stallman @ 2005-07-31 0:43 ` Luc Teirlinck 2005-07-31 14:58 ` Juanma Barranquero 2005-08-01 0:45 ` Richard M. Stallman 2005-07-31 1:02 ` Luc Teirlinck 1 sibling, 2 replies; 21+ messages in thread From: Luc Teirlinck @ 2005-07-31 0:43 UTC (permalink / raw) Cc: drew.adams, emacs-devel Richard Stallman wrote: The _default_ :initialize function is custom-initialize-reset. That means that whenever a file containing a defcustom with a :set function is loaded, that :set function is called That seems like the right thing to me. If the user set the variable, he probably wanted to control the mode. In the text you quoted, I was talking about defcustoms with a :set function that are _not_ minor modes. The vast majority of minor modes use custom-initialize-default, so the custom-initialize-reset problems do not apply to them. _even_ if the user customized the variable outside Custom, possibly in an attempt to avoid the :set function. So what? One can't please everybody. I thought that we decided that use of Custom was optional, that people should be able to customize everything in their .emacs and completely ignore Custom, if that is what they wanted to do. custom-initialize-reset effectively makes the Custom way of customizing things mandatory. If you try to customize things manually in your .emacs you subject yourself to Custom overriding you at random moments, without notice, when some file is loaded (for instance by Custom). This has repeatedly caused me (and other people) problems in practice. If you describe these problems, we could think about whether they are worth solving by changing this mechanism. However, if the problems only occur with a few particularly troublesome variables, it would be easier to deal with them one by one. Prior cases that were known to give problems have been solved already in various ways, but people just keep writing new very intrusive :set functions. I have proposed a solution for one very bad example in a different thread. I plan to install that solution if I do not hear any objections to it. But custom-initialize-reset can give bad surprises to people customizing a variable outside Custom, even for very reasonable :set functions. For instance, suppose that setting a variable only takes effect if a timer is set. People using Custom have come to expect that just setting a variable through Custom is sufficient. So you have to provide a :set function that calls the timer. Now somebody who wants the feature sometimes enabled and sometimes not might set a very complex value for the variable in his .emacs and then enable and disable the feature for that complex value by repeatedly setting and unsetting the (autoloadable) timer. But every so often the feature will be mysteriously silently enabled, when some file is silently loaded, for instance by Custom. (That is why, in defcustoms I write that call a timer in a :set function, I usually use custom-initialize-set, or, if the standard value does not require the timer, custom-initialize-default.) Sincerely, Luc. ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [drew.adams@oracle.com: Info on define-minor-mode - :init-valueor :initial-value?] 2005-07-31 0:43 ` Luc Teirlinck @ 2005-07-31 14:58 ` Juanma Barranquero 2005-08-01 0:45 ` Richard M. Stallman 1 sibling, 0 replies; 21+ messages in thread From: Juanma Barranquero @ 2005-07-31 14:58 UTC (permalink / raw) Cc: emacs-devel On 7/31/05, Luc Teirlinck <teirllm@dms.auburn.edu> wrote: > I thought that we decided that use of Custom was optional, that people > should be able to customize everything in their .emacs and completely > ignore Custom, if that is what they wanted to do. Yes, please! I for sure *don't* want Custom forcing its way on my variables. -- /L/e/k/t/u ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [drew.adams@oracle.com: Info on define-minor-mode - :init-valueor :initial-value?] 2005-07-31 0:43 ` Luc Teirlinck 2005-07-31 14:58 ` Juanma Barranquero @ 2005-08-01 0:45 ` Richard M. Stallman 2005-08-01 1:47 ` Luc Teirlinck 2005-08-01 5:33 ` Juanma Barranquero 1 sibling, 2 replies; 21+ messages in thread From: Richard M. Stallman @ 2005-08-01 0:45 UTC (permalink / raw) Cc: drew.adams, emacs-devel That seems like the right thing to me. If the user set the variable, he probably wanted to control the mode. In the text you quoted, I was talking about defcustoms with a :set function that are _not_ minor modes. I don't think this changes anything, but let's call it "behavior" rather than "mode". So what? One can't please everybody. I thought that we decided that use of Custom was optional, that people should be able to customize everything in their .emacs and completely ignore Custom, if that is what they wanted to do. That is just a goal, not an unbreakable rule. It seems irrelevant to this issue anyway. We're not talking about running Custom here. We're talking about what happens when you load a defcustom and the variable has already been set. If you try to customize things manually in your .emacs you subject yourself to Custom overriding you at random moments, without notice, when some file is loaded (for instance by Custom). It's not Custom that's doing this, it is loading the defcustom. Let's not complicate the issue unnecessarily. Prior cases that were known to give problems have been solved already in various ways, but people just keep writing new very intrusive :set functions. We just have to fix them to be less intrusive. Perhaps we could develop a list of guidelines they should follow. For instance, suppose that setting a variable only takes effect if a timer is set. People using Custom have come to expect that just setting a variable through Custom is sufficient. So you have to provide a :set function that calls the timer. Do you mean, that sets up the timer? Now somebody who wants the feature sometimes enabled and sometimes not might set a very complex value for the variable in his .emacs and then enable and disable the feature for that complex value by repeatedly setting and unsetting the (autoloadable) timer. Do you mean activating and canceling the timer? It seems like asking for trouble. But every so often the feature will be mysteriously silently enabled, when some file is silently loaded, for instance by Custom. The variable could have three states: an active timer, an inactive timer, and nil meaning no timer has been set. The set function could create the timer only if the variable is nil. ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [drew.adams@oracle.com: Info on define-minor-mode - :init-valueor :initial-value?] 2005-08-01 0:45 ` Richard M. Stallman @ 2005-08-01 1:47 ` Luc Teirlinck 2005-08-01 5:33 ` Juanma Barranquero 1 sibling, 0 replies; 21+ messages in thread From: Luc Teirlinck @ 2005-08-01 1:47 UTC (permalink / raw) Cc: drew.adams, emacs-devel Richard Stallman wrote: Do you mean, that sets up the timer? Yes. Do you mean activating and canceling the timer? Yes. But every so often the feature will be mysteriously silently enabled, when some file is silently loaded, for instance by Custom. The variable could have three states: an active timer, an inactive timer, and nil meaning no timer has been set. The set function could create the timer only if the variable is nil. That sounds complex, but anyway, the situation with timers is just one example among many. Using custom-initialize-set or custom-initialize-default completely solves the timer problem as I pointed out, so there is no need to come up with a more complex solution. Sincerely, Luc. ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [drew.adams@oracle.com: Info on define-minor-mode - :init-valueor :initial-value?] 2005-08-01 0:45 ` Richard M. Stallman 2005-08-01 1:47 ` Luc Teirlinck @ 2005-08-01 5:33 ` Juanma Barranquero 2005-08-01 16:46 ` Richard M. Stallman 1 sibling, 1 reply; 21+ messages in thread From: Juanma Barranquero @ 2005-08-01 5:33 UTC (permalink / raw) Cc: emacs-devel On 8/1/05, Richard M. Stallman <rms@gnu.org> wrote: > We're not talking about running Custom here. > We're talking about what happens when you load a defcustom and > the variable has already been set. If loading a defcustom is gonna modify a variable I've set in my .emacs, I want something akin to (please-defcustom-dont-fucking-touch 'my-variable) whether this is (put 'my-variable 'saved-value t) or anything else. -- /L/e/k/t/u ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [drew.adams@oracle.com: Info on define-minor-mode - :init-valueor :initial-value?] 2005-08-01 5:33 ` Juanma Barranquero @ 2005-08-01 16:46 ` Richard M. Stallman 0 siblings, 0 replies; 21+ messages in thread From: Richard M. Stallman @ 2005-08-01 16:46 UTC (permalink / raw) Cc: emacs-devel If loading a defcustom is gonna modify a variable I've set in my .emacs, I want something akin to (please-defcustom-dont-fucking-touch 'my-variable) Is there really such a problem, with the solution I've called for? ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [drew.adams@oracle.com: Info on define-minor-mode - :init-valueor :initial-value?] 2005-07-30 23:44 ` Richard M. Stallman 2005-07-31 0:43 ` Luc Teirlinck @ 2005-07-31 1:02 ` Luc Teirlinck 2005-08-01 0:45 ` Richard M. Stallman 1 sibling, 1 reply; 21+ messages in thread From: Luc Teirlinck @ 2005-07-31 1:02 UTC (permalink / raw) Cc: drew.adams, emacs-devel Richard Stallman wrote: If we can't arrange to make just the defcustom do the job, documenting this method is ok with me. Perhaps we should document a simple way and a complex way. The simple way is that it all gets done by the :set function when the defcustom's expansion is executed. That requires putting the defcustom after the minor mode function and generating a defvar before the function. You'd use custom-initialize-reset. For cases which are more complex, you'd use custom-initialize-default and then write (if foo-mode (foo-mode 1)) at the end of the file. If we are willing to change define-minor-mode, then I do not believe that there is any need for the more complex method, unless there is some reason why the define-minor-mode can not be delayed until all functions called by the minor mode have been defined. If we make define-minor-mode write a compiler defvar, then define the mode function and then write the defcustom, one can use custom-initialize-set if the define-minor-mode is not autoloaded, and custom-initialize-reset if it is to be autoloaded. Actually, custom-initialize-reset is relatively harmless for the default define-minor-mode :set function. (The problems I was referring to concern non minor mode :set functions, as I pointed out in my other message.) Sincerely, Luc. ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [drew.adams@oracle.com: Info on define-minor-mode - :init-valueor :initial-value?] 2005-07-31 1:02 ` Luc Teirlinck @ 2005-08-01 0:45 ` Richard M. Stallman 0 siblings, 0 replies; 21+ messages in thread From: Richard M. Stallman @ 2005-08-01 0:45 UTC (permalink / raw) Cc: drew.adams, emacs-devel For cases which are more complex, you'd use custom-initialize-default and then write (if foo-mode (foo-mode 1)) at the end of the file. If we are willing to change define-minor-mode, then I do not believe that there is any need for the more complex method, unless there is some reason why the define-minor-mode can not be delayed until all functions called by the minor mode have been defined. Sometimes it is inconvenient to order things that way. So let's document this as an optional method. ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [drew.adams@oracle.com: Info on define-minor-mode - :init-valueor :initial-value?] 2005-07-28 17:43 ` [drew.adams@oracle.com: Info on define-minor-mode - :init-valueor :initial-value?] Drew Adams 2005-07-29 2:56 ` Luc Teirlinck @ 2005-07-29 15:59 ` Stefan Monnier 2005-07-29 17:43 ` Drew Adams 2005-07-30 4:22 ` Luc Teirlinck 1 sibling, 2 replies; 21+ messages in thread From: Stefan Monnier @ 2005-07-29 15:59 UTC (permalink / raw) Cc: emacs-devel > (if foo-mode (foo-mode 1)) This will turn on the minor mode if you happen to browse the corresponding customize group (because Custom will then load the file). I.e. it'd be a bug. > Otherwise, if we're going to be rigid about this guideline (perhaps there > are good reasons to do that, even in this case), then maybe we should just > get rid of :init-value and have the initial value always be nil - that is, > make users of a library turn on the minor mode explicitly. That would not be > my preference, but it would at least avoid confusion. That might be a good alternative. Stefan ^ permalink raw reply [flat|nested] 21+ messages in thread
* RE: [drew.adams@oracle.com: Info on define-minor-mode - :init-valueor :initial-value?] 2005-07-29 15:59 ` Stefan Monnier @ 2005-07-29 17:43 ` Drew Adams 2005-07-30 4:22 ` Luc Teirlinck 1 sibling, 0 replies; 21+ messages in thread From: Drew Adams @ 2005-07-29 17:43 UTC (permalink / raw) > (if foo-mode (foo-mode 1)) This will turn on the minor mode if you happen to browse the corresponding customize group (because Custom will then load the file). I.e. it'd be a bug. Sorry, I don't understand. If the variable is t, then the mode should be turned on, no? Does it matter whether it is Customize or the user who loads the file? The mode will be turned on only if the variable is t - why is that bad? What am I missing? And, as I said, I picked this up from the standard Lisp sources, so if it is unadvisable then some updating might be in order. If we don't get rid of :init-value (not my call), and the above code is faulty, then what do you recommend to users writing libraries - just use nil as the :init-value always? ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [drew.adams@oracle.com: Info on define-minor-mode - :init-valueor :initial-value?] 2005-07-29 15:59 ` Stefan Monnier 2005-07-29 17:43 ` Drew Adams @ 2005-07-30 4:22 ` Luc Teirlinck 2005-07-30 13:58 ` [drew.adams@oracle.com: Info on define-minor-mode -:init-valueor :initial-value?] Drew Adams 1 sibling, 1 reply; 21+ messages in thread From: Luc Teirlinck @ 2005-07-30 4:22 UTC (permalink / raw) Cc: drew.adams, emacs-devel Stefan Monnier wrote: > Otherwise, if we're going to be rigid about this guideline (perhaps there > are good reasons to do that, even in this case), then maybe we should just > get rid of :init-value and have the initial value always be nil - that is, > make users of a library turn on the minor mode explicitly. That would not be > my preference, but it would at least avoid confusion. That might be a good alternative. No, because sometimes a standard value of t is appropriate and the :init-value _has_ to reflect the standard value, or Custom would consider the variable to be "rogue". What if I just document in the Elisp manual what the acceptable situations are for a non-nil :init-value and how it needs to be handled: pre-load the file containing the define-minor-mode before startup.el and call the minor mode function (or custom-reevaluate-setting if the minor mode only has to be enabled conditionally) in startup.el for minor modes included with the Emacs distribution that affect Emacs "globally" and put (if foo-mode (foo-mode 1)) at the end of the file containing the define-minor-mode for minor modes that only affect features defined in that file (and that are in files that are not pre-loaded). Sincerely, Luc. ^ permalink raw reply [flat|nested] 21+ messages in thread
* RE: [drew.adams@oracle.com: Info on define-minor-mode -:init-valueor :initial-value?] 2005-07-30 4:22 ` Luc Teirlinck @ 2005-07-30 13:58 ` Drew Adams 2005-07-30 21:46 ` Luc Teirlinck 0 siblings, 1 reply; 21+ messages in thread From: Drew Adams @ 2005-07-30 13:58 UTC (permalink / raw) What if I just document in the Elisp manual what the acceptable situations are for a non-nil :init-value and how it needs to be handled: pre-load the file containing the define-minor-mode before startup.el and call the minor mode function (or custom-reevaluate-setting if the minor mode only has to be enabled conditionally) in startup.el for minor modes included with the Emacs distribution that affect Emacs "globally" and put (if foo-mode (foo-mode 1)) at the end of the file containing the define-minor-mode for minor modes that only affect features defined in that file (and that are in files that are not pre-loaded). FWIW, that's OK by me. In the user doc (Elisp), we should say "this is how you create a minor mode..." and include the bit about (if foo-mode (foo-mode 1)) for non-nil init value. That is apparently an integral part of coding a minor mode with a non-nil init value. If so, this should not be mentioned only as an afterthought in an explanation of one of the examples. And, since this is user doc, I would put the user bit first and the "pre-load..." bit last, or remove the latter altogether. Most users reading this will use define-minor-mode in their own libraries, not in stuff that is part of Emacs. Or, if it is mentioned, perhaps mention it as a note to Emacs maintainers/developers as an alternative for dealing with the issue in internal code. What about my suggestion of including this bit of code automatically, as part of the expansion of define-minor-mode - perhaps by generating an eval-after-load or something? Is that feasible? If so, would there be a problem with such a hack? ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [drew.adams@oracle.com: Info on define-minor-mode -:init-valueor :initial-value?] 2005-07-30 13:58 ` [drew.adams@oracle.com: Info on define-minor-mode -:init-valueor :initial-value?] Drew Adams @ 2005-07-30 21:46 ` Luc Teirlinck 0 siblings, 0 replies; 21+ messages in thread From: Luc Teirlinck @ 2005-07-30 21:46 UTC (permalink / raw) Cc: emacs-devel Drew Adams wrote: What about my suggestion of including this bit of code automatically, as part of the expansion of define-minor-mode - perhaps by generating an eval-after-load or something? Is that feasible? If so, would there be a problem with such a hack? That is actually exactly what the define-minor-mode code used to do, before Stefan started changing it. (Stefan kept the eval-after-load, but made it do different things). However, using eval-after-load has many negative side effects, as I pointed out before. If one wants to have define-minor-mode enable a minor mode automatically if :init-value is non-nil, then I believe that the best way to do that would be to make define-minor-mode support alternative :initialize functions like custom-initialize-set by changing the order in which define-minor-mode defines things. (As I suggested earlier.) Sincerely, Luc. ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [drew.adams@oracle.com: Info on define-minor-mode - :init-value or :initial-value?] 2005-07-28 16:58 ` Stefan Monnier 2005-07-28 17:43 ` [drew.adams@oracle.com: Info on define-minor-mode - :init-valueor :initial-value?] Drew Adams @ 2005-07-29 1:48 ` Luc Teirlinck 2005-07-29 17:10 ` Stefan Monnier 1 sibling, 1 reply; 21+ messages in thread From: Luc Teirlinck @ 2005-07-29 1:48 UTC (permalink / raw) Cc: rms, emacs-devel Stefan Monnier wrote: > There is more. You can not specify a non-nil :init-value, unless > either the minor mode is enabled by just setting the variable or > unless you do something extra. In what way is this a limitation? I.e. if you don't use define-minor-mode, how would you do it differently? [ I don't mean to say that "manual" code can't do it differently, but that if it does it differently, it'll most likely break the convention that just loading a file shouldn't make any visible changes. ] Suppose that you have a minor mode that only makes a difference when you are using the speedbar. (I just take this as an example; any option that is itself not enabled by default will do.) The minor mode would be part of the intended default behavior of speedbar, but not everybody might like it, hence the need for a defcustom with default t. You use `custom-initialize-set' as the :initialize function. You put the minor mode code in speedbar.el. Now loading speedbar.el will enable the minor mode, unless the user overwrote that by setting the minor mode variable to nil. However, this will not change the behavior of Emacs in any way that is unrelated to the speedbar. With the current define-minor-mode code, you can _try_ to set the :initialize keyword to `custom-initialize-set', but it will not work, because define-minor-mode writes the defcustom before the minor mode function, hence executing the defcustom will yield an error. It is possible to change the define-minor-mode code to get around that, but I guess that it would require define-minor-mode to first write a compiler defvar, then the mode function, and then the defcustom. Also, all functions used by the minor mode function would have to be defined before the define-minor-mode (if the minor mode is enabled by default). Sincerely, Luc. ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [drew.adams@oracle.com: Info on define-minor-mode - :init-value or :initial-value?] 2005-07-29 1:48 ` [drew.adams@oracle.com: Info on define-minor-mode - :init-value or :initial-value?] Luc Teirlinck @ 2005-07-29 17:10 ` Stefan Monnier 0 siblings, 0 replies; 21+ messages in thread From: Stefan Monnier @ 2005-07-29 17:10 UTC (permalink / raw) Cc: rms, emacs-devel >> There is more. You can not specify a non-nil :init-value, unless >> either the minor mode is enabled by just setting the variable or >> unless you do something extra. > In what way is this a limitation? > I.e. if you don't use define-minor-mode, how would you do it differently? > [ I don't mean to say that "manual" code can't do it differently, but > that if it does it differently, it'll most likely break the convention > that just loading a file shouldn't make any visible changes. ] > Suppose that you have a minor mode that only makes a difference when > you are using the speedbar. (I just take this as an example; any > option that is itself not enabled by default will do.) The minor mode > would be part of the intended default behavior of speedbar, but not > everybody might like it, hence the need for a defcustom with default > t. You use `custom-initialize-set' as the :initialize function. You > put the minor mode code in speedbar.el. Now loading speedbar.el will > enable the minor mode, unless the user overwrote that by setting the > minor mode variable to nil. However, this will not change the behavior > of Emacs in any way that is unrelated to the speedbar. That's an interesting case indeed. With define-minor-mode you'd have to add (if foo-mode (foo-mode 1)) at the end of the file. It may not be the best solution, but it doesn't seem much worse than using custom-initialize-set since it saves you from having to worry about the ordering of defcustoms and defuns and it makes it very clear that code is run at the toplevel and that it thus needs to be checked for "no visible effect". Stefan ^ permalink raw reply [flat|nested] 21+ messages in thread
end of thread, other threads:[~2005-08-01 16:46 UTC | newest] Thread overview: 21+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2005-07-27 14:57 [drew.adams@oracle.com: Info on define-minor-mode - :init-value or :initial-value?] Richard M. Stallman 2005-07-27 16:04 ` Luc Teirlinck 2005-07-28 16:58 ` Stefan Monnier 2005-07-28 17:43 ` [drew.adams@oracle.com: Info on define-minor-mode - :init-valueor :initial-value?] Drew Adams 2005-07-29 2:56 ` Luc Teirlinck 2005-07-30 23:44 ` Richard M. Stallman 2005-07-31 0:43 ` Luc Teirlinck 2005-07-31 14:58 ` Juanma Barranquero 2005-08-01 0:45 ` Richard M. Stallman 2005-08-01 1:47 ` Luc Teirlinck 2005-08-01 5:33 ` Juanma Barranquero 2005-08-01 16:46 ` Richard M. Stallman 2005-07-31 1:02 ` Luc Teirlinck 2005-08-01 0:45 ` Richard M. Stallman 2005-07-29 15:59 ` Stefan Monnier 2005-07-29 17:43 ` Drew Adams 2005-07-30 4:22 ` Luc Teirlinck 2005-07-30 13:58 ` [drew.adams@oracle.com: Info on define-minor-mode -:init-valueor :initial-value?] Drew Adams 2005-07-30 21:46 ` Luc Teirlinck 2005-07-29 1:48 ` [drew.adams@oracle.com: Info on define-minor-mode - :init-value or :initial-value?] Luc Teirlinck 2005-07-29 17:10 ` 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.