* bug#13583: 24.3.50; Error when activating auto-revert-mode @ 2013-01-29 10:59 Dani Moncayo 2013-01-29 11:10 ` Eli Zaretskii 0 siblings, 1 reply; 30+ messages in thread From: Dani Moncayo @ 2013-01-29 10:59 UTC (permalink / raw) To: 13583 Recipe from "emacs -Q": 1. Eval: (setq auto-revert-use-notify nil) 2. Visit some file. 3. M-x auto-revert-mode RET When I do it, my Emacs fails with this message: custom-initialize-reset: Symbol's value as variable is void: auto-revert-notify-watch-descriptor and auto-revert-mode is not activated. In GNU Emacs 24.3.50.1 (i386-mingw-nt5.2.3790) of 2013-01-25 on MS-W8-DANI Bzr revision: 111604 eliz@gnu.org-20130125143821-1ykj7ia1qjojjjnp Windowing system distributor `Microsoft Corp.', version 5.2.3790 Configured using: `configure --with-gcc (4.7) --no-opt --enable-checking --cflags -Ic:/emacs/libs/libXpm-3.5.10/include -Ic:/emacs/libs/libXpm-3.5.10/src -Ic:/emacs/libs/libpng-dev_1.4.3-1_win32/include -Ic:/emacs/libs/zlib-dev_1.2.5-2_win32/include -Ic:/emacs/libs/giflib-4.1.4-1-lib/include -Ic:/emacs/libs/jpeg-6b-4-lib/include -Ic:/emacs/libs/tiff-3.8.2-1-lib/include -Ic:/emacs/libs/libxml2-2.7.8-w32-bin/include/libxml2 -Ic:/emacs/libs/gnutls-3.1.5-w32/include -Ic:/emacs/libs/libiconv-1.14-2-mingw32-dev/include' -- Dani Moncayo ^ permalink raw reply [flat|nested] 30+ messages in thread
* bug#13583: 24.3.50; Error when activating auto-revert-mode 2013-01-29 10:59 bug#13583: 24.3.50; Error when activating auto-revert-mode Dani Moncayo @ 2013-01-29 11:10 ` Eli Zaretskii 2013-01-29 11:34 ` Dani Moncayo 2013-01-29 15:10 ` Stefan Monnier 0 siblings, 2 replies; 30+ messages in thread From: Eli Zaretskii @ 2013-01-29 11:10 UTC (permalink / raw) To: Dani Moncayo; +Cc: 13583 > Date: Tue, 29 Jan 2013 11:59:43 +0100 > From: Dani Moncayo <dmoncayo@gmail.com> > > Recipe from "emacs -Q": > 1. Eval: (setq auto-revert-use-notify nil) > 2. Visit some file. > 3. M-x auto-revert-mode RET > > When I do it, my Emacs fails with this message: > custom-initialize-reset: Symbol's value as variable is void: > auto-revert-notify-watch-descriptor > > and auto-revert-mode is not activated. Cockipt error. The doc string clearly says "If non-nil Auto Revert Mode uses file notification functions. This requires Emacs being compiled with file notification support (see `auto-revert-notify-enabled'). You should set this variable through Custom only." ^^^^^^^^^^^^^^^^^^^ ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ That's because this defcustom has a :set function defined for it; if that function isn't run, the results are unpredictable. Any reason not to close this bug? ^ permalink raw reply [flat|nested] 30+ messages in thread
* bug#13583: 24.3.50; Error when activating auto-revert-mode 2013-01-29 11:10 ` Eli Zaretskii @ 2013-01-29 11:34 ` Dani Moncayo 2013-01-29 12:08 ` Eli Zaretskii 2013-01-29 15:10 ` Stefan Monnier 1 sibling, 1 reply; 30+ messages in thread From: Dani Moncayo @ 2013-01-29 11:34 UTC (permalink / raw) To: Eli Zaretskii; +Cc: 13583 > Cockipt error. The doc string clearly says > > "If non-nil Auto Revert Mode uses file notification functions. > This requires Emacs being compiled with file notification > support (see `auto-revert-notify-enabled'). You should set this > variable through Custom only." ^^^^^^^^^^^^^^^^^^^ > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > > That's because this defcustom has a :set function defined for it; if > that function isn't run, the results are unpredictable. > > Any reason not to close this bug? I try to avoid the customize facility as much as I can, because it doesn't allow to set values based on conditions like the system-type, for example. If I do some customization "by hand" in my init file, I have all the power an flexibility of elisp for doing what I want. That is not possible using customize. So currently I use customize only for face-related settings, and BTW I have to maintain several custom files (one for GUI sessions, other for the Windows console and other for the Ubuntu console) because each environment requires a specific visual customization. Therefore, I'd like to be able to set `auto-revert-use-notify' directly in my init file, with `setq', but if that is not possible, I will have to adapt myself. -- Dani Moncayo ^ permalink raw reply [flat|nested] 30+ messages in thread
* bug#13583: 24.3.50; Error when activating auto-revert-mode 2013-01-29 11:34 ` Dani Moncayo @ 2013-01-29 12:08 ` Eli Zaretskii 2013-01-29 12:18 ` Dani Moncayo 2013-01-29 13:44 ` Michael Heerdegen 0 siblings, 2 replies; 30+ messages in thread From: Eli Zaretskii @ 2013-01-29 12:08 UTC (permalink / raw) To: Dani Moncayo; +Cc: 13583 > Date: Tue, 29 Jan 2013 12:34:40 +0100 > From: Dani Moncayo <dmoncayo@gmail.com> > Cc: 13583@debbugs.gnu.org > > I try to avoid the customize facility as much as I can, because it > doesn't allow to set values based on conditions like the system-type, > for example. Doesn't custom-set-variables work inside an "if" clause? If it does, then what's the problem of using it only on some systems? > Therefore, I'd like to be able to set `auto-revert-use-notify' > directly in my init file, with `setq', but if that is not possible, I > will have to adapt myself. You can run the :set form of the option, with suitable substitutions for "variable" and "value", instead of setting the value with setq. But then you'd need to change that every time the :set form changes in autorevert.el. ^ permalink raw reply [flat|nested] 30+ messages in thread
* bug#13583: 24.3.50; Error when activating auto-revert-mode 2013-01-29 12:08 ` Eli Zaretskii @ 2013-01-29 12:18 ` Dani Moncayo 2013-01-29 12:35 ` Eli Zaretskii 2013-01-29 13:44 ` Michael Heerdegen 1 sibling, 1 reply; 30+ messages in thread From: Dani Moncayo @ 2013-01-29 12:18 UTC (permalink / raw) To: Eli Zaretskii; +Cc: 13583 >> I try to avoid the customize facility as much as I can, because it >> doesn't allow to set values based on conditions like the system-type, >> for example. > > Doesn't custom-set-variables work inside an "if" clause? If it does, > then what's the problem of using it only on some systems? The problem with that approach is that, if I do some other customization and save it, the custom facility writes _all_ current unsaved customization to the custom file, therefore the customization of `auto-revert-use-notify' would end up in the custom file, which is not what I want, obviously. A workaround is to fool the customize facility by marking the relevant customizations as "saved" just after the call to custom-set-variables, but that is an ugly hack, IMO. >> Therefore, I'd like to be able to set `auto-revert-use-notify' >> directly in my init file, with `setq', but if that is not possible, I >> will have to adapt myself. > > You can run the :set form of the option, with suitable substitutions > for "variable" and "value", instead of setting the value with setq. > But then you'd need to change that every time the :set form changes in > autorevert.el. So that doesn't seem like a good solution either... -- Dani Moncayo ^ permalink raw reply [flat|nested] 30+ messages in thread
* bug#13583: 24.3.50; Error when activating auto-revert-mode 2013-01-29 12:18 ` Dani Moncayo @ 2013-01-29 12:35 ` Eli Zaretskii 2013-01-29 13:42 ` Dani Moncayo 0 siblings, 1 reply; 30+ messages in thread From: Eli Zaretskii @ 2013-01-29 12:35 UTC (permalink / raw) To: Dani Moncayo; +Cc: 13583 > Date: Tue, 29 Jan 2013 13:18:58 +0100 > From: Dani Moncayo <dmoncayo@gmail.com> > Cc: 13583@debbugs.gnu.org > > >> I try to avoid the customize facility as much as I can, because it > >> doesn't allow to set values based on conditions like the system-type, > >> for example. > > > > Doesn't custom-set-variables work inside an "if" clause? If it does, > > then what's the problem of using it only on some systems? > > The problem with that approach is that, if I do some other > customization and save it ??? You just said that you "try to avoid the customize facility", so why in the world would you want to save your customizations?? Instead of saving them, use the custom-set-variables function to do what you want, when you want. > the custom facility writes _all_ current unsaved customization to > the custom file, therefore the customization of > `auto-revert-use-notify' would end up in the custom file, which is > not what I want, obviously. This is a misunderstanding, surely: custom-set-variables does not save anything. It arranges for the variable to be customized, as if you used the Customize user interface. So I don't understand how "unsaved customizations" and "custom file" come into play here. Could you perhaps give more details about the workflow which brings you to those issues, including the commands you use? > A workaround is to fool the customize facility by marking the relevant > customizations as "saved" just after the call to custom-set-variables, > but that is an ugly hack, IMO. Why would you need to save any customizations at all? If you want to customize yet another variable, add yet another custom-set-variables form to your .emacs, that's all. What am I missing? ^ permalink raw reply [flat|nested] 30+ messages in thread
* bug#13583: 24.3.50; Error when activating auto-revert-mode 2013-01-29 12:35 ` Eli Zaretskii @ 2013-01-29 13:42 ` Dani Moncayo 2013-01-29 14:22 ` Dani Moncayo 2013-01-29 17:42 ` Eli Zaretskii 0 siblings, 2 replies; 30+ messages in thread From: Dani Moncayo @ 2013-01-29 13:42 UTC (permalink / raw) To: Eli Zaretskii; +Cc: 13583 >> The problem with that approach is that, if I do some other >> customization and save it > > ??? You just said that you "try to avoid the customize facility", so > why in the world would you want to save your customizations?? So far I use it for face customization, exclusively. > Instead of saving them, use the custom-set-variables function to do > what you want, when you want. Good idea. I'll do it. >> the custom facility writes _all_ current unsaved customization to >> the custom file, therefore the customization of >> `auto-revert-use-notify' would end up in the custom file, which is >> not what I want, obviously. > > This is a misunderstanding, surely: custom-set-variables does not save > anything. It arranges for the variable to be customized, as if you > used the Customize user interface. So I don't understand how "unsaved > customizations" and "custom file" come into play here. Could you > perhaps give more details about the workflow which brings you to those > issues, including the commands you use? In my init file, I store a file name in `custom-file' so that the stuff that customize manages is kept separate from my stuff, i.e., the things I've write myself in my init file. In the custom file, I have exclusively face customizations, which I can tweak and save whenever I want. So, if I write a call to customize-set-faces or customize-set-variables right in my init file, the customizations made that way end up in a "unsaved" state, so that if I do some face customization (using customize) and save it, the custom file receives not only the face customization, but also the other "unsaved" ones, which I wanted to keep out of the custom file. >> A workaround is to fool the customize facility by marking the relevant >> customizations as "saved" just after the call to custom-set-variables, >> but that is an ugly hack, IMO. > > Why would you need to save any customizations at all? If you want to > customize yet another variable, add yet another custom-set-variables > form to your .emacs, that's all. What am I missing? Yes, I think that's a good approach. I'll get rid of my custom file, and do the appropriate calls to custom-set-xxxx directly from my init file. Thank you. This bug can be closed. -- Dani Moncayo ^ permalink raw reply [flat|nested] 30+ messages in thread
* bug#13583: 24.3.50; Error when activating auto-revert-mode 2013-01-29 13:42 ` Dani Moncayo @ 2013-01-29 14:22 ` Dani Moncayo 2013-01-29 15:08 ` Drew Adams ` (2 more replies) 2013-01-29 17:42 ` Eli Zaretskii 1 sibling, 3 replies; 30+ messages in thread From: Dani Moncayo @ 2013-01-29 14:22 UTC (permalink / raw) To: Eli Zaretskii; +Cc: 13583 >> Why would you need to save any customizations at all? If you want to >> customize yet another variable, add yet another custom-set-variables >> form to your .emacs, that's all. What am I missing? > > Yes, I think that's a good approach. I'll get rid of my custom file, > and do the appropriate calls to custom-set-xxxx directly from my init > file. But for the record: IIUC, I that approach isn't flawless either, because doing face customization is pretty hard without the customize facility, and using customize will imply: 1. Do the customization in a custom buffer. 2. Save the customization (for getting the elisp code). 3. Look for the appropriate sentence in the generated custom file, and move it to my init file. That is not very convenient, but fortunately I don't do face customization every day. -- Dani Moncayo ^ permalink raw reply [flat|nested] 30+ messages in thread
* bug#13583: 24.3.50; Error when activating auto-revert-mode 2013-01-29 14:22 ` Dani Moncayo @ 2013-01-29 15:08 ` Drew Adams 2013-01-29 15:16 ` Wolfgang Jenkner 2013-01-29 17:44 ` Eli Zaretskii 2 siblings, 0 replies; 30+ messages in thread From: Drew Adams @ 2013-01-29 15:08 UTC (permalink / raw) To: 'Dani Moncayo', 'Eli Zaretskii'; +Cc: 13583 Dani said: > But for the record: IIUC, I that approach isn't flawless either, > because doing face customization is pretty hard without the customize > facility, and using customize will imply: > 1. Do the customization in a custom buffer. > 2. Save the customization (for getting the elisp code). > 3. Look for the appropriate sentence in the generated custom file, and > move it to my init file. > > That is not very convenient, but fortunately I don't do face > customization every day. and > A workaround is to fool the customize facility by marking the relevant > customizations as "saved" just after the call to custom-set-variables, > but that is an ugly hack, IMO. That workaround is an ugly hack, OK. But it is no more an ugly hack than the other workarounds (yes, they are just that) that you all have been discussing, IMO. Michael H. is right that (a) the custom* arsenal has the tools one needs but (b) interactive Customize itself should be expanded to provide general users with them directly (i.e., no Lisp needed). I do some of that in my ugly-little-hack library cus-edit+.el [*], but no doubt someone knowing the custom* code well could do better. There has been little interest so far, unfortunately. One reason is perhaps that the cus* code is difficult to fathom. Given the current state of what's available, I still do recommend the ugly little hack Dani mentioned: telling customize that there has been no change to the option (i.e., lying). That's what the custom* code itself does. That the names of the things involved make it look like you are claiming that the option has been _saved_, instead of telling customize to ignore any changes, is only a name problem - for us people. But yes, there is room for improvement. [*] http://www.emacswiki.org/emacs-en/download/cus-edit%2b.el http://www.emacswiki.org/emacs/CustomizingAndSaving#CustomizePlus ^ permalink raw reply [flat|nested] 30+ messages in thread
* bug#13583: 24.3.50; Error when activating auto-revert-mode 2013-01-29 14:22 ` Dani Moncayo 2013-01-29 15:08 ` Drew Adams @ 2013-01-29 15:16 ` Wolfgang Jenkner 2013-01-29 16:12 ` Drew Adams 2013-01-29 17:44 ` Eli Zaretskii 2 siblings, 1 reply; 30+ messages in thread From: Wolfgang Jenkner @ 2013-01-29 15:16 UTC (permalink / raw) To: Dani Moncayo; +Cc: 13583 On Tue, Jan 29 2013, Dani Moncayo wrote: > That is not very convenient, but fortunately I don't do face > customization every day. You could use a theme (in the sense of deftheme) for that. I have the impression that most (all?) of them are maintained by directly editing them and not via the customize interface. At least, I do this and otherwise pretend that "customize" doesn't exist (of course, themes are based on it but they shouldn't ;-) Wolfgang ^ permalink raw reply [flat|nested] 30+ messages in thread
* bug#13583: 24.3.50; Error when activating auto-revert-mode 2013-01-29 15:16 ` Wolfgang Jenkner @ 2013-01-29 16:12 ` Drew Adams 2013-01-29 21:25 ` Andy Moreton 0 siblings, 1 reply; 30+ messages in thread From: Drew Adams @ 2013-01-29 16:12 UTC (permalink / raw) To: 'Wolfgang Jenkner', 'Dani Moncayo', 'Stefan Monnier' Cc: 13583 WJ> I do this and otherwise pretend that "customize" doesn't exist WJ> (of course, themes are based on it but they shouldn't ;-) SM> It should be possible to have (setq auto-revert-use-notify SM> nil) in your .emacs and not use Custom. SM> SM> Stefan "who also uses Custom only for face settings" [Just two examples - other Emacs developers have admitted to much the same.] While there is perhaps room for improvement also for Lisp users of custom* code, the sad truth is that interactive Customize, which is what we advertize for general users, gets left behind in the dust. But it is there that real improvement is sorely needed. With so many Emacs developers not even using Customize interactively for their own use, interactive Customize is essentially abandoned in terms of development. Yidong and others have fixed some bugs and tweaked cosmetically around some of the edges, but otherwise the UI code has hardly been touched since its inception. Certainly there has been no improvement in the area being discussed here. The real shame is that because of its lacks (and its bad reputation resulting from those lacks and from its less-than-appealing UI) many novice users also skip using Customize interactively. And they, above all, should not. Too often they do so from the mistaken notion that Customize is just for sissies and that somehow using a bit of Lisp in their init files makes them more Programmer and less Luser. Unfortunately, that way they often miss out on the real power of custom*, including type-checking and :set forms, because they do not sufficiently understand what Lisp code to use. `setq' on its own certainly does not cut the mustard, but it is common to see users rely on it. The best thing that could happen - for users, IMO, is for Emacs developers to stop, themselves, using "Custom only for face settings" etc., and thus confront the deficiencies of the UI directly. Turn your frustration with it into something constructive - for all users. With that, there might be some hope that users would sooner or later get the Customize improvements they deserve. ^ permalink raw reply [flat|nested] 30+ messages in thread
* bug#13583: 24.3.50; Error when activating auto-revert-mode 2013-01-29 16:12 ` Drew Adams @ 2013-01-29 21:25 ` Andy Moreton 2013-01-29 22:35 ` Drew Adams 0 siblings, 1 reply; 30+ messages in thread From: Andy Moreton @ 2013-01-29 21:25 UTC (permalink / raw) To: 13583 On Tue 29 Jan 2013, Drew Adams wrote: > The real shame is that because of its lacks (and its bad reputation resulting > from those lacks and from its less-than-appealing UI) many novice users also > skip using Customize interactively. And they, above all, should not. > > Too often they do so from the mistaken notion that Customize is just for sissies > and that somehow using a bit of Lisp in their init files makes them more > Programmer and less Luser. The poor discoverability of options and the need to use lisp forms in some custom values eventaully force all users who do more than tinker at the edges to learn some elisp and avoid Customize altogether. > Unfortunately, that way they often miss out on the real power of custom*, > including type-checking and :set forms, because they do not sufficiently > understand what Lisp code to use. `setq' on its own certainly does not cut the > mustard, but it is common to see users rely on it. The type checking may useful, but it shouldn't be buried in a library that brings in so much extra cruft with it. Far better to make those facilities available and useful whether the customize UI is used or not, and to document this style of usage in the emacs manual (even if this is only links to the elisp manual). Customize is also strongly anti modular, lumping settings for eveything together, and giving the user no control over per platform or per machine settings. It also neatly ensures that the user cannot add any comments to the customised settings when they are saved. > The best thing that could happen - for users, IMO, is for Emacs developers to > stop, themselves, using "Custom only for face settings" etc., and thus confront > the deficiencies of the UI directly. Turn your frustration with it into > something constructive - for all users. No, the best thing would be to remove Customize altogether :-) AndyM ^ permalink raw reply [flat|nested] 30+ messages in thread
* bug#13583: 24.3.50; Error when activating auto-revert-mode 2013-01-29 21:25 ` Andy Moreton @ 2013-01-29 22:35 ` Drew Adams 2013-01-30 23:42 ` Andy Moreton 0 siblings, 1 reply; 30+ messages in thread From: Drew Adams @ 2013-01-29 22:35 UTC (permalink / raw) To: 'Andy Moreton', 13583 > > The real shame is that because of its lacks (and its bad > > reputation resulting from those lacks and from its > > less-than-appealing UI) many novice users also > > skip using Customize interactively. And they, above all, > > should not. > > > > Too often they do so from the mistaken notion that Customize > > is just for sissies and that somehow using a bit of Lisp in > > their init files makes them more Programmer and less Luser. > > The poor discoverability of options Agreed, assuming I understand what you mean. > and the need to use lisp forms in some custom values Are you referring to Customize UI fields for inputting a value, where the value can or must be a Lisp sexp? I'm guessing yes; otherwise, I don't follow you. > eventaully force all users who do more than tinker at > the edges to learn some elisp Anyone who uses _Emacs_ and does more than tinker at the edges will end up learning some Elisp. That's not specific to the Customize UI. (And, in itself, learning some Elisp is a good thing, not a bad thing.) But yes, you are right that learning some Lisp helps. > and avoid Customize altogether. Not at all. There is nothing that "forces all users" who do more than tinker to "avoid Customize altogether". That's an extreme (because of "force") version of precisely the fallacy that I'm trying to point out. Just because a user knows some Elisp is no reason that s?he should (let alone is forced to) "avoid Customize altogether". You are perfectly illustrating the very problem I pointed to: users can mistakenly think that having recourse to Elisp instead of Customize is somehow more advanced or somehow necessary to do anything non-trivial. Nothing could be further from the truth. I would add, however, that there are too many users of defcustom who either do not understand its possibilities or are too lazy to DTRT when it comes to defining the :type and the possible user inputs/interactions. Based on core code I've seen, this applies also to Emacs Dev, to some extent. It is all too easy to just throw together a simple but awful definition - one that is not as helpful to users as it should be. I mention this here because it too can give users the impression that Customize is something only rudimentary and coarse-grained - by which I mean not only the UI (which is admittedly primitive) but the Customize machinery underlying it. If the writer of a defcustom has only a rudimentary knowledge of defcustom or just doesn't care enough, the result is, yes, a poor, rough, rudimentary UI for that option. That's not the fault of defcustom or the Customize UI so much as it is the fault of the programmer who designs that option and its customization possibilities. > The type checking may useful, but it shouldn't be buried in a library > that brings in so much extra cruft with it. I agree 100%. It's an important point. All the more important because this feature is available to Emacs Lisp programmers ONLY for option customization. So they do not and cannot take advantage of it otherwise. And in many cases they are, I think, not even very aware of it. This is so important, IMO, that I've suggested that such type-checking (i.e., defcustom :type's) could be useful for non-option variables (defvars) as well. There is no reason not to be able to take advantage of this feature for other variables. Unfortunately, there was little interest: "YAGNI", was about the only response. Today, if you want to take advantage of type-checking then you need to make the variable that benefits from it into a user option. Emacs Dev should separate these two orthogonal things: type checking and user customizability. > Far better to make those facilities available and useful whether > the customize UI is used or not, +1! I could not agree more. > and to document this style of usage in the emacs manual (even > if this is only links to the elisp manual). +1 again. > Customize is also strongly anti modular, lumping settings for > eveything together, and giving the user no control over per > platform or per machine settings. > > It also neatly ensures that the user cannot add any > comments to the customised settings when they are saved. Yes, those are among the things that should be improved. There is in fact a lot of room for improvement in the Customize UI and wrt Emacs customizing more generally. As I mentioned, one problem is that the custom* (more generally, the widget*) code is difficult to fathom and poorly documented. The result is that few Elisp programmers can or want to hack it. And that probably goes for Emacs Dev programmers as well. The author, Per A., was not wont to spend much effort communicating with Emacs Dev about the code. It lacks, above all, easy ways to follow it and discover info about its parts. Following it in the debugger is, well, "interesting". Another problem, another reason that few people hack the Customize code, I think, is the phenomenon I pointed to earlier: they don't bother to use the Customize UI themselves, so they are not that familiar with it and its problems, and they too easily tend to think that it is beneath them, somehow lower than using Lisp. FWIW, I use both Lisp and the Customize UI for my customizations. I _want_ Customize to automatically manage most of my option and face customizations. But in a separate `custom-file'. I specifically keep my init file away from Customize, and I think Emacs Dev should advise most users to do the same thing. There is little reason to let a program mix automatically generated code in with your manually edited code. And vice versa, there is little reason for you to be editing the same file that contains automatically generated code. > > The best thing that could happen - for users, IMO, is for > > Emacs developers to stop, themselves, using "Custom only for > > face settings" etc., and thus confront the deficiencies of the > > UI directly. Turn your frustration with it into > > something constructive - for all users. > > No, the best thing would be to remove Customize altogether :-) Though I disagree, I won't argue with you about that. I will say that that attitude is a primary obstacle to our improving customization for Emacs users. I don't mean your attitude personally, but the fact that the same attitude is so prevalent. The reaction of most Emacs developers is just to ignore Customize, which is no more helpful than removing it would be. FWIW, I used to feel exactly as you just expressed it: Customize is not worth it. Little by little I came to learn more about it, and now I feel strongly that it is a good thing. Had I not tried to make my code useful for other users besides myself, I would never have bothered to learn more about defcustom :type's etc. I would have just continued to keep the same attitude toward what Customize is good for: nothing. Not that the _UI_ is wonderful - far from it. It is especially all of the behind-the-scenes initialization, :set triggering, backing up, and type-checking that is helpful, if not indispensable for robust preference management. Trying to take advantage of those features using only Lisp is the problem that was at the starting point of this thread. You can do it, but you must be on your toes and learn a fair amount about the custom* code. See earlier in the thread, about different "ugly little hacks" to get custom* to do what you want. I do some of that myself, and I put some of it into an extension of the Customize UI code, so that others can benefit without needing to dive into the custom* code themselves each time. IMO, that's the kind of thing we need, to start with: fix the UI so it lets you do the kinds of things that started this thread: e.g., tell Customize to ignore certain changes and consider them irrelevant to saving. There is no reason that users should need to use Lisp to do this kind of thing. It is simple to give them an action in the UI that accomplishes the same thing. Users are not forced to resort to Lisp and "avoid Customize altogether", but they do need to use Lisp today to accomplish certain things that Customize should let them do interactively, directly. Those are a minority of the things that one can do with the custom* features, but it is still important to integrate them into the UI. ^ permalink raw reply [flat|nested] 30+ messages in thread
* bug#13583: 24.3.50; Error when activating auto-revert-mode 2013-01-29 22:35 ` Drew Adams @ 2013-01-30 23:42 ` Andy Moreton 2013-01-30 23:52 ` Drew Adams 0 siblings, 1 reply; 30+ messages in thread From: Andy Moreton @ 2013-01-30 23:42 UTC (permalink / raw) To: 13583 On Tue 29 Jan 2013, Drew Adams wrote: >> and avoid Customize altogether. > > Not at all. There is nothing that "forces all users" who do more than tinker to > "avoid Customize altogether". That's an extreme (because of "force") version of > precisely the fallacy that I'm trying to point out. > > Just because a user knows some Elisp is no reason that s?he should (let alone is > forced to) "avoid Customize altogether". > > You are perfectly illustrating the very problem I pointed to: users can > mistakenly think that having recourse to Elisp instead of Customize is somehow > more advanced or somehow necessary to do anything non-trivial. Nothing could be > further from the truth. I don't use customize at all. It's hard to find options in the UI and its harder to configure things via the UI than to do it directly via elisp. > I would add, however, that there are too many users of defcustom who either do > not understand its possibilities or are too lazy to DTRT when it comes to > defining the :type and the possible user inputs/interactions. > > Based on core code I've seen, this applies also to Emacs Dev, to some extent. > It is all too easy to just throw together a simple but awful definition - one > that is not as helpful to users as it should be. This is an essential problem of the customize package. By making it to hard to write and debug something robust, package authors are more likely to do the minimum neccesary to "tick the box" and move on. The very prescence of customize is a strong disicentive for a developer to come up with something better, due to all fo the comatibiility and migration headaches that must be overcome for a replacement or evolution to be acceptable. >> The type checking may useful, but it shouldn't be buried in a library >> that brings in so much extra cruft with it. > > I agree 100%. It's an important point. All the more important because this > feature is available to Emacs Lisp programmers ONLY for option customization. > So they do not and cannot take advantage of it otherwise. And in many cases > they are, I think, not even very aware of it. Type checking and accessor methods are fundamental primitives that belong in the interpreter/compiler or an object system library. The extra stuff for deciding how to present a variavble of a particular type in UI is a separate set of concerns. > This is so important, IMO, that I've suggested that such type-checking (i.e., > defcustom :type's) could be useful for non-option variables (defvars) as well. > There is no reason not to be able to take advantage of this feature for other > variables. Unfortunately, there was little interest: "YAGNI", was about the > only response. The Cygwin folk use SHTDI (somebody has to do it) and PTC (patches thoughtfully considered), both which are applicable here. > Today, if you want to take advantage of type-checking then you need to make the > variable that benefits from it into a user option. Emacs Dev should separate > these two orthogonal things: type checking and user customizability. Agreed (but see above). >> Far better to make those facilities available and useful whether >> the customize UI is used or not, > > +1! I could not agree more. > >> and to document this style of usage in the emacs manual (even >> if this is only links to the elisp manual). > > +1 again. > >> Customize is also strongly anti modular, lumping settings for >> eveything together, and giving the user no control over per >> platform or per machine settings. >> >> It also neatly ensures that the user cannot add any >> comments to the customised settings when they are saved. > > Yes, those are among the things that should be improved. There is in fact a lot > of room for improvement in the Customize UI and wrt Emacs customizing more > generally. > > As I mentioned, one problem is that the custom* (more generally, the widget*) > code is difficult to fathom and poorly documented. The result is that few Elisp > programmers can or want to hack it. Agreed. These code quality issues are good reasons for delaying integration of a new feature until the basics are in place. > And that probably goes for Emacs Dev programmers as well. The author, Per A., > was not wont to spend much effort communicating with Emacs Dev about the code. > It lacks, above all, easy ways to follow it and discover info about its parts. > Following it in the debugger is, well, "interesting". > > Another problem, another reason that few people hack the Customize code, I > think, is the phenomenon I pointed to earlier: they don't bother to use the > Customize UI themselves, so they are not that familiar with it and its problems, > and they too easily tend to think that it is beneath them, somehow lower than > using Lisp. No, I think the problem is that most emacs devs don't use it because they do not experince the problems that it clains to be a solution for. Those who have used it have discovered that it causes pain, and resolved not to repeat the experience. > I _want_ Customize to automatically manage most of my option and face > customizations. > > But in a separate `custom-file'. I specifically keep my init file away from > Customize, and I think Emacs Dev should advise most users to do the same thing. > There is little reason to let a program mix automatically generated code in with > your manually edited code. And vice versa, there is little reason for you to be > editing the same file that contains automatically generated code. That is the only thing I configure about it: to prevent it damaging my init file :-) >> > The best thing that could happen - for users, IMO, is for >> > Emacs developers to stop, themselves, using "Custom only for >> > face settings" etc., and thus confront the deficiencies of the >> > UI directly. Turn your frustration with it into >> > something constructive - for all users. >> >> No, the best thing would be to remove Customize altogether :-) > > Though I disagree, I won't argue with you about that. I will say that that > attitude is a primary obstacle to our improving customization for Emacs users. > I don't mean your attitude personally, but the fact that the same attitude is so > prevalent. > > The reaction of most Emacs developers is just to ignore Customize, which is no > more helpful than removing it would be. > > FWIW, I used to feel exactly as you just expressed it: Customize is not worth > it. Little by little I came to learn more about it, and now I feel strongly > that it is a good thing. > > Had I not tried to make my code useful for other users besides myself, I would > never have bothered to learn more about defcustom :type's etc. I would have > just continued to keep the same attitude toward what Customize is good for: > nothing. > > Not that the _UI_ is wonderful - far from it. It is especially all of the > behind-the-scenes initialization, :set triggering, backing up, and type-checking > that is helpful, if not indispensable for robust preference management. That machinery is what puts me off in the first place. Customize wraps everything up in an embedded language to describe how to transform settings into lisp. I'd rather avoid the obfuscation and write the lisp myself to start with. > Trying to take advantage of those features using only Lisp is the problem that > was at the starting point of this thread. You can do it, but you must be on > your toes and learn a fair amount about the custom* code. See earlier in the > thread, about different "ugly little hacks" to get custom* to do what you want. > > I do some of that myself, and I put some of it into an extension of the > Customize UI code, so that others can benefit without needing to dive into the > custom* code themselves each time. Please consider contributing these improvements to emacs. > IMO, that's the kind of thing we need, to start with: fix the UI so it lets you > do the kinds of things that started this thread: e.g., tell Customize to ignore > certain changes and consider them irrelevant to saving. > > There is no reason that users should need to use Lisp to do this kind of thing. > It is simple to give them an action in the UI that accomplishes the same thing. Agreed, but this should not be at the expense of doing things directly from code and avoiding the UI. AndyM ^ permalink raw reply [flat|nested] 30+ messages in thread
* bug#13583: 24.3.50; Error when activating auto-revert-mode 2013-01-30 23:42 ` Andy Moreton @ 2013-01-30 23:52 ` Drew Adams 0 siblings, 0 replies; 30+ messages in thread From: Drew Adams @ 2013-01-30 23:52 UTC (permalink / raw) To: 'Andy Moreton', 13583 > > I do some of that myself, and I put some of it into an > > extension of the Customize UI code, so that others can > > benefit without needing to dive into the custom* code > > themselves each time. > > Please consider contributing these improvements to emacs. I did - proposed the explicit code changes long ago. And the code is still available, as I mentioned. ^ permalink raw reply [flat|nested] 30+ messages in thread
* bug#13583: 24.3.50; Error when activating auto-revert-mode 2013-01-29 14:22 ` Dani Moncayo 2013-01-29 15:08 ` Drew Adams 2013-01-29 15:16 ` Wolfgang Jenkner @ 2013-01-29 17:44 ` Eli Zaretskii 2 siblings, 0 replies; 30+ messages in thread From: Eli Zaretskii @ 2013-01-29 17:44 UTC (permalink / raw) To: Dani Moncayo; +Cc: 13583 > Date: Tue, 29 Jan 2013 15:22:04 +0100 > From: Dani Moncayo <dmoncayo@gmail.com> > Cc: 13583@debbugs.gnu.org > > >> Why would you need to save any customizations at all? If you want to > >> customize yet another variable, add yet another custom-set-variables > >> form to your .emacs, that's all. What am I missing? > > > > Yes, I think that's a good approach. I'll get rid of my custom file, > > and do the appropriate calls to custom-set-xxxx directly from my init > > file. > > But for the record: IIUC, I that approach isn't flawless either, > because doing face customization is pretty hard without the customize > facility, and using customize will imply: > 1. Do the customization in a custom buffer. > 2. Save the customization (for getting the elisp code). > 3. Look for the appropriate sentence in the generated custom file, and > move it to my init file. > > That is not very convenient, but fortunately I don't do face > customization every day. Exactly. If you change customizations very frequently, then they probably don't belong in your init/custom file anyway. ^ permalink raw reply [flat|nested] 30+ messages in thread
* bug#13583: 24.3.50; Error when activating auto-revert-mode 2013-01-29 13:42 ` Dani Moncayo 2013-01-29 14:22 ` Dani Moncayo @ 2013-01-29 17:42 ` Eli Zaretskii 1 sibling, 0 replies; 30+ messages in thread From: Eli Zaretskii @ 2013-01-29 17:42 UTC (permalink / raw) To: Dani Moncayo; +Cc: 13583 > Date: Tue, 29 Jan 2013 14:42:39 +0100 > From: Dani Moncayo <dmoncayo@gmail.com> > Cc: 13583@debbugs.gnu.org > > In the custom file, I have exclusively face customizations, which I > can tweak and save whenever I want. For face customizations, you can use custom-save-faces instead. > So, if I write a call to customize-set-faces or > customize-set-variables right in my init file, the customizations made > that way end up in a "unsaved" state, so that if I do some face > customization (using customize) and save it, the custom file receives > not only the face customization, but also the other "unsaved" ones, > which I wanted to keep out of the custom file. Then keep all your calls to custom-save-* in one place. This way, even if you overwrite them, you can easily restore order by using the backup of that single file. (You do back up your init files, right?) ^ permalink raw reply [flat|nested] 30+ messages in thread
* bug#13583: 24.3.50; Error when activating auto-revert-mode 2013-01-29 12:08 ` Eli Zaretskii 2013-01-29 12:18 ` Dani Moncayo @ 2013-01-29 13:44 ` Michael Heerdegen 2013-01-29 17:39 ` Eli Zaretskii 1 sibling, 1 reply; 30+ messages in thread From: Michael Heerdegen @ 2013-01-29 13:44 UTC (permalink / raw) To: 13583 Eli Zaretskii <eliz@gnu.org> writes: > You can run the :set form of the option, with suitable substitutions > for "variable" and "value", instead of setting the value with setq. > But then you'd need to change that every time the :set form changes in > autorevert.el. IMHO, no user should need to do something like that. I have a question: If it may be necessary for users to run this code to achieve what Dani wants (which is not exotic), why don't we just provide a callable function that DTRT (and call it in the setter), instead of forcing people to call this code indirectly via Custom? The current situation is consistent and not a bug, yes - but it may also be confusing to non-experts (i.e., the majority of Emacs users). I often saw people being reluctant about using `custom-set-variables' in their init file. I browsed the doc of `custom-set-variables', as well as the "Customization" chapter in the manual. I found no places were we say that some of these functions are suitable for being called from other files than the custom file, without danger. But if it is sometimes even necessary to do so, even if the user doesn't use the Customize interface, shouldn't we clearly explain this somewhere? Regards, Michael. ^ permalink raw reply [flat|nested] 30+ messages in thread
* bug#13583: 24.3.50; Error when activating auto-revert-mode 2013-01-29 13:44 ` Michael Heerdegen @ 2013-01-29 17:39 ` Eli Zaretskii 2013-01-29 18:13 ` Michael Heerdegen 0 siblings, 1 reply; 30+ messages in thread From: Eli Zaretskii @ 2013-01-29 17:39 UTC (permalink / raw) To: Michael Heerdegen; +Cc: 13583 > From: Michael Heerdegen <michael_heerdegen@web.de> > Date: Tue, 29 Jan 2013 14:44:50 +0100 > > Eli Zaretskii <eliz@gnu.org> writes: > > > You can run the :set form of the option, with suitable substitutions > > for "variable" and "value", instead of setting the value with setq. > > But then you'd need to change that every time the :set form changes in > > autorevert.el. > > IMHO, no user should need to do something like that. No one does. Using custom-set-variables is much easier. I just wanted to give Dani all the alternatives I knew about. Nothing wrong with that, is there? > I often saw people being reluctant about using `custom-set-variables' in > their init file. > > I browsed the doc of `custom-set-variables', as well as the > "Customization" chapter in the manual. I found no places were we say > that some of these functions are suitable for being called from other > files than the custom file, without danger. I call it from my .emacs, and never had any problems in years. ^ permalink raw reply [flat|nested] 30+ messages in thread
* bug#13583: 24.3.50; Error when activating auto-revert-mode 2013-01-29 17:39 ` Eli Zaretskii @ 2013-01-29 18:13 ` Michael Heerdegen 0 siblings, 0 replies; 30+ messages in thread From: Michael Heerdegen @ 2013-01-29 18:13 UTC (permalink / raw) To: 13583 Eli Zaretskii <eliz@gnu.org> writes: > > IMHO, no user should need to do something like that. > > No one does. Using custom-set-variables is much easier. I just > wanted to give Dani all the alternatives I knew about. Nothing wrong > with that, is there? Ok, no - sorry. > > I often saw people being reluctant about using `custom-set-variables' in > > their init file. > > > > I browsed the doc of `custom-set-variables', as well as the > > "Customization" chapter in the manual. I found no places were we say > > that some of these functions are suitable for being called from other > > files than the custom file, without danger. > > I call it from my .emacs, and never had any problems in years. Good to know - still wonder if we should say explicitly somewhere that this is possible/supported. Regards, Michael. ^ permalink raw reply [flat|nested] 30+ messages in thread
* bug#13583: 24.3.50; Error when activating auto-revert-mode 2013-01-29 11:10 ` Eli Zaretskii 2013-01-29 11:34 ` Dani Moncayo @ 2013-01-29 15:10 ` Stefan Monnier 2013-01-29 16:06 ` Michael Albinus 1 sibling, 1 reply; 30+ messages in thread From: Stefan Monnier @ 2013-01-29 15:10 UTC (permalink / raw) To: Eli Zaretskii; +Cc: 13583 > Cockipt error. The doc string clearly says > "If non-nil Auto Revert Mode uses file notification functions. > This requires Emacs being compiled with file notification > support (see `auto-revert-notify-enabled'). You should set this > variable through Custom only." ^^^^^^^^^^^^^^^^^^^ > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > That's because this defcustom has a :set function defined for it; if > that function isn't run, the results are unpredictable. > Any reason not to close this bug? It should be possible to have (setq auto-revert-use-notify nil) in your .emacs and not use Custom. Stefan "who also uses Custom only for face settings" ^ permalink raw reply [flat|nested] 30+ messages in thread
* bug#13583: 24.3.50; Error when activating auto-revert-mode 2013-01-29 15:10 ` Stefan Monnier @ 2013-01-29 16:06 ` Michael Albinus 2013-01-29 17:48 ` Eli Zaretskii 2013-01-30 18:05 ` Dani Moncayo 0 siblings, 2 replies; 30+ messages in thread From: Michael Albinus @ 2013-01-29 16:06 UTC (permalink / raw) To: Stefan Monnier; +Cc: 13583 Stefan Monnier <monnier@IRO.UMontreal.CA> writes: >> Cockipt error. The doc string clearly says >> "If non-nil Auto Revert Mode uses file notification functions. >> This requires Emacs being compiled with file notification >> support (see `auto-revert-notify-enabled'). You should set this >> variable through Custom only." ^^^^^^^^^^^^^^^^^^^ >> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ >> That's because this defcustom has a :set function defined for it; if >> that function isn't run, the results are unpredictable. >> Any reason not to close this bug? > > It should be possible to have (setq auto-revert-use-notify nil) in your > .emacs and not use Custom. I've added :initialize 'custom-initialize-default to that defcustom. That seems to do the job. Best regards, Michael. ^ permalink raw reply [flat|nested] 30+ messages in thread
* bug#13583: 24.3.50; Error when activating auto-revert-mode 2013-01-29 16:06 ` Michael Albinus @ 2013-01-29 17:48 ` Eli Zaretskii 2013-01-29 21:39 ` Stefan Monnier 2013-01-30 7:28 ` Michael Albinus 2013-01-30 18:05 ` Dani Moncayo 1 sibling, 2 replies; 30+ messages in thread From: Eli Zaretskii @ 2013-01-29 17:48 UTC (permalink / raw) To: Michael Albinus; +Cc: 13583 > From: Michael Albinus <michael.albinus@gmx.de> > Cc: Eli Zaretskii <eliz@gnu.org>, 13583@debbugs.gnu.org > Date: Tue, 29 Jan 2013 17:06:10 +0100 > > Stefan Monnier <monnier@IRO.UMontreal.CA> writes: > > >> Cockipt error. The doc string clearly says > >> "If non-nil Auto Revert Mode uses file notification functions. > >> This requires Emacs being compiled with file notification > >> support (see `auto-revert-notify-enabled'). You should set this > >> variable through Custom only." ^^^^^^^^^^^^^^^^^^^ > >> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > >> That's because this defcustom has a :set function defined for it; if > >> that function isn't run, the results are unpredictable. > >> Any reason not to close this bug? > > > > It should be possible to have (setq auto-revert-use-notify nil) in your > > .emacs and not use Custom. > > I've added > > :initialize 'custom-initialize-default > > to that defcustom. That seems to do the job. Thanks, but the doc string still says one needs to use Customize. Anyway, if ":initialize 'custom-initialize-default" is such a wonderful feature that everyone wants, why isn't it the default, and why does the user of defcustom need to opt-in it? ^ permalink raw reply [flat|nested] 30+ messages in thread
* bug#13583: 24.3.50; Error when activating auto-revert-mode 2013-01-29 17:48 ` Eli Zaretskii @ 2013-01-29 21:39 ` Stefan Monnier 2013-01-30 17:55 ` Eli Zaretskii 2013-01-30 7:28 ` Michael Albinus 1 sibling, 1 reply; 30+ messages in thread From: Stefan Monnier @ 2013-01-29 21:39 UTC (permalink / raw) To: Eli Zaretskii; +Cc: 13583, Michael Albinus > Anyway, if ":initialize 'custom-initialize-default" is such a > wonderful feature that everyone wants, why isn't it the default, and > why does the user of defcustom need to opt-in it? Sadly, it all depends on the particulars of the case at hand. Stefan ^ permalink raw reply [flat|nested] 30+ messages in thread
* bug#13583: 24.3.50; Error when activating auto-revert-mode 2013-01-29 21:39 ` Stefan Monnier @ 2013-01-30 17:55 ` Eli Zaretskii 2013-01-30 21:02 ` Stefan Monnier 0 siblings, 1 reply; 30+ messages in thread From: Eli Zaretskii @ 2013-01-30 17:55 UTC (permalink / raw) To: Stefan Monnier; +Cc: 13583, michael.albinus > From: Stefan Monnier <monnier@IRO.UMontreal.CA> > Cc: Michael Albinus <michael.albinus@gmx.de>, 13583@debbugs.gnu.org > Date: Tue, 29 Jan 2013 16:39:09 -0500 > > > Anyway, if ":initialize 'custom-initialize-default" is such a > > wonderful feature that everyone wants, why isn't it the default, and > > why does the user of defcustom need to opt-in it? > > Sadly, it all depends on the particulars of the case at hand. Could you perhaps elaborate a bit more? ^ permalink raw reply [flat|nested] 30+ messages in thread
* bug#13583: 24.3.50; Error when activating auto-revert-mode 2013-01-30 17:55 ` Eli Zaretskii @ 2013-01-30 21:02 ` Stefan Monnier 0 siblings, 0 replies; 30+ messages in thread From: Stefan Monnier @ 2013-01-30 21:02 UTC (permalink / raw) To: Eli Zaretskii; +Cc: 13583, michael.albinus >> > Anyway, if ":initialize 'custom-initialize-default" is such a >> > wonderful feature that everyone wants, why isn't it the default, and >> > why does the user of defcustom need to opt-in it? >> Sadly, it all depends on the particulars of the case at hand. > Could you perhaps elaborate a bit more? Not much, really. Basically it depends on the typical use case, and on what happens in the rest of the code (e.g. if the setter is not run, is the resulting state consistent and to which value does it correspond). Stefan ^ permalink raw reply [flat|nested] 30+ messages in thread
* bug#13583: 24.3.50; Error when activating auto-revert-mode 2013-01-29 17:48 ` Eli Zaretskii 2013-01-29 21:39 ` Stefan Monnier @ 2013-01-30 7:28 ` Michael Albinus 2013-01-30 16:54 ` Eli Zaretskii 1 sibling, 1 reply; 30+ messages in thread From: Michael Albinus @ 2013-01-30 7:28 UTC (permalink / raw) To: Eli Zaretskii; +Cc: 13583 Eli Zaretskii <eliz@gnu.org> writes: >> >> Cockipt error. The doc string clearly says >> >> "If non-nil Auto Revert Mode uses file notification functions. >> >> This requires Emacs being compiled with file notification >> >> support (see `auto-revert-notify-enabled'). You should set this >> >> variable through Custom only." ^^^^^^^^^^^^^^^^^^^ >> >> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ >> >> That's because this defcustom has a :set function defined for it; if >> >> that function isn't run, the results are unpredictable. >> >> Any reason not to close this bug? >> > >> > It should be possible to have (setq auto-revert-use-notify nil) in your >> > .emacs and not use Custom. >> >> I've added >> >> :initialize 'custom-initialize-default >> >> to that defcustom. That seems to do the job. > > Thanks, but the doc string still says one needs to use Customize. The docstring says "You should set this variable through Custom only." "Should" is not too restrictive, I believe. Best regards, Michael. ^ permalink raw reply [flat|nested] 30+ messages in thread
* bug#13583: 24.3.50; Error when activating auto-revert-mode 2013-01-30 7:28 ` Michael Albinus @ 2013-01-30 16:54 ` Eli Zaretskii 2013-01-30 19:24 ` Michael Albinus 0 siblings, 1 reply; 30+ messages in thread From: Eli Zaretskii @ 2013-01-30 16:54 UTC (permalink / raw) To: Michael Albinus; +Cc: 13583 > From: Michael Albinus <michael.albinus@gmx.de> > Cc: monnier@IRO.UMontreal.CA, 13583@debbugs.gnu.org > Date: Wed, 30 Jan 2013 08:28:39 +0100 > > >> I've added > >> > >> :initialize 'custom-initialize-default > >> > >> to that defcustom. That seems to do the job. > > > > Thanks, but the doc string still says one needs to use Customize. > > The docstring says "You should set this variable through Custom only." > "Should" is not too restrictive, I believe. But "only" is. ^ permalink raw reply [flat|nested] 30+ messages in thread
* bug#13583: 24.3.50; Error when activating auto-revert-mode 2013-01-30 16:54 ` Eli Zaretskii @ 2013-01-30 19:24 ` Michael Albinus 0 siblings, 0 replies; 30+ messages in thread From: Michael Albinus @ 2013-01-30 19:24 UTC (permalink / raw) To: Eli Zaretskii; +Cc: 13583 Eli Zaretskii <eliz@gnu.org> writes: >> > Thanks, but the doc string still says one needs to use Customize. >> >> The docstring says "You should set this variable through Custom only." >> "Should" is not too restrictive, I believe. > > But "only" is. Nitpicking! :-) I've changed it in the trunk. Best regards, Michael. ^ permalink raw reply [flat|nested] 30+ messages in thread
* bug#13583: 24.3.50; Error when activating auto-revert-mode 2013-01-29 16:06 ` Michael Albinus 2013-01-29 17:48 ` Eli Zaretskii @ 2013-01-30 18:05 ` Dani Moncayo 1 sibling, 0 replies; 30+ messages in thread From: Dani Moncayo @ 2013-01-30 18:05 UTC (permalink / raw) To: Michael Albinus; +Cc: 13583 >> It should be possible to have (setq auto-revert-use-notify nil) in your >> .emacs and not use Custom. > > I've added > > :initialize 'custom-initialize-default > > to that defcustom. That seems to do the job. Seems to work, indeed. Thank you. -- Dani Moncayo ^ permalink raw reply [flat|nested] 30+ messages in thread
end of thread, other threads:[~2013-01-30 23:52 UTC | newest] Thread overview: 30+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2013-01-29 10:59 bug#13583: 24.3.50; Error when activating auto-revert-mode Dani Moncayo 2013-01-29 11:10 ` Eli Zaretskii 2013-01-29 11:34 ` Dani Moncayo 2013-01-29 12:08 ` Eli Zaretskii 2013-01-29 12:18 ` Dani Moncayo 2013-01-29 12:35 ` Eli Zaretskii 2013-01-29 13:42 ` Dani Moncayo 2013-01-29 14:22 ` Dani Moncayo 2013-01-29 15:08 ` Drew Adams 2013-01-29 15:16 ` Wolfgang Jenkner 2013-01-29 16:12 ` Drew Adams 2013-01-29 21:25 ` Andy Moreton 2013-01-29 22:35 ` Drew Adams 2013-01-30 23:42 ` Andy Moreton 2013-01-30 23:52 ` Drew Adams 2013-01-29 17:44 ` Eli Zaretskii 2013-01-29 17:42 ` Eli Zaretskii 2013-01-29 13:44 ` Michael Heerdegen 2013-01-29 17:39 ` Eli Zaretskii 2013-01-29 18:13 ` Michael Heerdegen 2013-01-29 15:10 ` Stefan Monnier 2013-01-29 16:06 ` Michael Albinus 2013-01-29 17:48 ` Eli Zaretskii 2013-01-29 21:39 ` Stefan Monnier 2013-01-30 17:55 ` Eli Zaretskii 2013-01-30 21:02 ` Stefan Monnier 2013-01-30 7:28 ` Michael Albinus 2013-01-30 16:54 ` Eli Zaretskii 2013-01-30 19:24 ` Michael Albinus 2013-01-30 18:05 ` Dani Moncayo
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.