* Visual cleanup for customize buffers @ 2006-01-12 21:58 Kim F. Storm 2006-01-12 23:45 ` Luc Teirlinck ` (3 more replies) 0 siblings, 4 replies; 57+ messages in thread From: Kim F. Storm @ 2006-01-12 21:58 UTC (permalink / raw) Here are some trivial patches to cleanup some of the visual clutter in customize buffers: - Don't show the "Hide value" button for trivial values which fit on one line initially. I don't see ANY reason why a user would click on that button to, say, hide a boolean or numeric value. - For choice values, replace the old [Value Menu] Value by the more common [Value v] (where v is a "pull down" icon) To see some good examples of this, try M-x customize-group cua and look at the variables "cua prefix override inhibit delay" and "Cua normal cursor color". - Remove the empty line between the [STATE] line and the documentation. *** wid-edit.el 04 Jan 2006 17:15:51 +0100 1.160 --- wid-edit.el 12 Jan 2006 22:42:11 +0100 *************** *** 1416,1421 **** --- 1416,1423 ---- (call-interactively (or (widget-get widget :complete-function) widget-complete-field))) + (defvar widget-choice-menu-image nil) + (defun widget-default-create (widget) "Create WIDGET at point in the current buffer." (widget-specify-insert *************** *** 1423,1429 **** button-begin button-end sample-begin sample-end doc-begin doc-end ! value-pos) (insert (widget-get widget :format)) (goto-char from) ;; Parse escapes in format. --- 1425,1431 ---- button-begin button-end sample-begin sample-end doc-begin doc-end ! value-pos value-choice-button) (insert (widget-get widget :format)) (goto-char from) ;; Parse escapes in format. *************** *** 1436,1443 **** (setq button-begin (point)) (insert (widget-get-indirect widget :button-prefix))) ((eq escape ?\]) ! (insert (widget-get-indirect widget :button-suffix)) ! (setq button-end (point))) ((eq escape ?\{) (setq sample-begin (point))) ((eq escape ?\}) --- 1438,1471 ---- (setq button-begin (point)) (insert (widget-get-indirect widget :button-prefix))) ((eq escape ?\]) ! (save-excursion ! (setq button-end (point)) ! (when value-choice-button ! (goto-char button-begin) ! (when (search-forward ":" button-end t) ! (setq button-end (1- (point)))) ! (goto-char button-end) ! (when (eq (preceding-char) ?\n) ! (backward-char 1)) ! (insert " ") ! (if (display-graphic-p) ! (insert-image ! (or widget-choice-menu-image ! (setq widget-choice-menu-image ! (create-image "\377\176\176\074\074\030\030\377" ! 'xbm t :width 8 :height 8 ! :foreground ! (if (facep 'custom-button) ! (face-foreground 'custom-button) ! "black") ! :background ! (if (facep 'custom-button) ! (face-background 'custom-button) ! "lightgrey") ! :ascent 'center))) ">") ! (insert (propertize "?>" )) ! (setq button-end (point))) ! (insert (widget-get-indirect widget :button-suffix)))) ((eq escape ?\{) (setq sample-begin (point))) ((eq escape ?\}) *************** *** 1469,1474 **** --- 1497,1505 ---- (if (and button-begin (not button-end)) (widget-apply widget :value-create) (setq value-pos (point)))) + ((eq escape ?V) + (widget-apply widget :value-create) + (setq value-choice-button t)) (t (widget-apply widget :format-handler escape))))) ;; Specify button, sample, and doc, and insert value. *************** *** 3560,3566 **** (define-widget 'choice 'menu-choice "A union of several sexp types." :tag "Choice" ! :format "%{%t%}: %[Value Menu%] %v" :button-prefix 'widget-push-button-prefix :button-suffix 'widget-push-button-suffix :prompt-value 'widget-choice-prompt-value) --- 3591,3597 ---- (define-widget 'choice 'menu-choice "A union of several sexp types." :tag "Choice" ! :format "%{%t%}: %[%V%]" :button-prefix 'widget-push-button-prefix :button-suffix 'widget-push-button-suffix :prompt-value 'widget-choice-prompt-value) *************** *** 3629,3635 **** :prompt-value 'widget-boolean-prompt-value :button-prefix 'widget-push-button-prefix :button-suffix 'widget-push-button-suffix ! :format "%{%t%}: %[Toggle%] %v\n" :on "on (non-nil)" :off "off (nil)") --- 3660,3666 ---- :prompt-value 'widget-boolean-prompt-value :button-prefix 'widget-push-button-prefix :button-suffix 'widget-push-button-suffix ! :format "%{%t%}: %v %[Toggle%]\n" :on "on (non-nil)" :off "off (nil)") *** cus-edit.el 12 Jan 2006 09:13:27 +0100 1.275 --- cus-edit.el 12 Jan 2006 22:11:35 +0100 *************** *** 2513,2526 **** tag) buttons) (insert " ") ! (push (widget-create-child-and-convert ! widget 'visibility ! :help-echo "Hide the value of this option." ! :on "Hide Value" ! :off "Show Value" ! :action 'custom-toggle-parent ! t) ! buttons) (push (widget-create-child-and-convert widget type :format value-format --- 2513,2527 ---- tag) buttons) (insert " ") ! (unless (atom value) ! (push (widget-create-child-and-convert ! widget 'visibility ! :help-echo "Hide the value of this option." ! :on "Hide Value" ! :off "Show Value" ! :action 'custom-toggle-parent ! t) ! buttons)) (push (widget-create-child-and-convert widget type :format value-format *************** *** 2540,2546 **** ;; this anyway. The doc string widget should be added like the others. ;; --dv (widget-put widget :buttons buttons) ! (insert "\n") ;; Insert documentation. (widget-default-format-handler widget ?h) --- 2541,2548 ---- ;; this anyway. The doc string widget should be added like the others. ;; --dv (widget-put widget :buttons buttons) ! (unless (eq (preceding-char) ?\n) ! (insert "\n")) ;; Insert documentation. (widget-default-format-handler widget ?h) -- Kim F. Storm <storm@cua.dk> http://www.cua.dk ^ permalink raw reply [flat|nested] 57+ messages in thread
* Re: Visual cleanup for customize buffers 2006-01-12 21:58 Visual cleanup for customize buffers Kim F. Storm @ 2006-01-12 23:45 ` Luc Teirlinck 2006-01-13 12:37 ` Kim F. Storm ` (2 more replies) 2006-01-13 0:08 ` Luc Teirlinck ` (2 subsequent siblings) 3 siblings, 3 replies; 57+ messages in thread From: Luc Teirlinck @ 2006-01-12 23:45 UTC (permalink / raw) Cc: emacs-devel Kim Storm wrote: - Don't show the "Hide value" button for trivial values which fit on one line initially. I don't see ANY reason why a user would click on that button to, say, hide a boolean or numeric value. To hide them from the whole buffer buttons, from key bindings that operate on the whole buffer and from menu bar items that operate on the whole buffer. (These operations ignore hidden options and faces.) There are no "Hide Value" buttons in single option or face buffers, where they would _really_ be useless. Granted, there is very strong evidence that nobody uses the whole buffer buttons or functions _in multi-option buffers_ anyway. The majority of them were complete no-ops in group buffers until relatively recently and nobody complained about that until relatively recently. So nobody _could_ have used them, unless they used private bug fixes. But they are no longer no-ops now and _as long as we provide whole buffer functionality_ we need to provide people with a way to "hide" options from the whole buffer operations. Sincerely, Luc. ^ permalink raw reply [flat|nested] 57+ messages in thread
* Re: Visual cleanup for customize buffers 2006-01-12 23:45 ` Luc Teirlinck @ 2006-01-13 12:37 ` Kim F. Storm 2006-01-13 14:18 ` Luc Teirlinck 2006-01-13 16:40 ` Stefan Monnier 2006-01-13 19:04 ` Bill Wohler 2006-01-14 5:49 ` Richard M. Stallman 2 siblings, 2 replies; 57+ messages in thread From: Kim F. Storm @ 2006-01-13 12:37 UTC (permalink / raw) Cc: emacs-devel Luc Teirlinck <teirllm@dms.auburn.edu> writes: > Kim Storm wrote: > > - Don't show the "Hide value" button for trivial values which > fit on one line initially. I don't see ANY reason why a > user would click on that button to, say, hide a boolean > or numeric value. > > To hide them from the whole buffer buttons, from key bindings that > operate on the whole buffer and from menu bar items that operate on > the whole buffer. (These operations ignore hidden options and faces.) I never realized this -- "hide value" implies something very different to me. If I use the whole-buffer buttons, I would like it to save ALL changes. Anyway I just tried this (M-x customize-group cua): - Go to a face option, eg. "cua global mark" - click on "show face" - change some property of the face. - click on "hide face" (assuming that I don't want to save that change) => this gives an error saying "there are unset changes" and it doesn't hide the face. - select "State" => "Set for Current Session" on the option => the (sample) of the face is updated, and it looks fine - click "Hide face" to remove the clutter of the face definition - go on changing other options in the cua group => so I now have a mix of face and option changes which are either set for current session or not set at all. - click on whole buffer "Save for Future Sessions" button => saves the unset options, but NOT the changed face!! HUH?? I just hide the face to remove the clutter -- not because I didn't want to save it for future sessions. IMO, this functionality is just too obscure and confusing, and I doubt anyone finds it useful. > There are no "Hide Value" buttons in single option or face buffers, > where they would _really_ be useless. Really?? The "hide value" button is right there when I look! I don't see any code that removes the button -- that's what I added. > Granted, there is very strong evidence that nobody uses the whole > buffer buttons or functions _in multi-option buffers_ anyway. The > majority of them were complete no-ops in group buffers until > relatively recently and nobody complained about that until relatively > recently. So nobody _could_ have used them, unless they used private > bug fixes. But they are no longer no-ops now and _as long as we > provide whole buffer functionality_ we need to provide people with a > way to "hide" options from the whole buffer operations. I don't see why! If people want to save indiviual options, use the individual State buttons. If people want to save everything, use the whole buffer buttons. IMO, there is NO NEED to have the "partial save" functionality -- and even if there was, it is IMO very obscure to base it on the "show/hide" value state of the variables. -- Kim F. Storm <storm@cua.dk> http://www.cua.dk ^ permalink raw reply [flat|nested] 57+ messages in thread
* Re: Visual cleanup for customize buffers 2006-01-13 12:37 ` Kim F. Storm @ 2006-01-13 14:18 ` Luc Teirlinck 2006-01-13 15:16 ` Kim F. Storm 2006-01-13 16:40 ` Stefan Monnier 1 sibling, 1 reply; 57+ messages in thread From: Luc Teirlinck @ 2006-01-13 14:18 UTC (permalink / raw) Cc: emacs-devel Kim Storm wrote: - click on whole buffer "Save for Future Sessions" button => saves the unset options, but NOT the changed face!! That is because you hid it, as I explained. Really?? The "hide value" button is right there when I look! I don't see any code that removes the button -- that's what I added. Yes, I somehow got confused here. I do not know why I somehow did not notice the button there. I don't see why! If people want to save indiviual options, use the individual State buttons. If people want to save everything, use the whole buffer buttons. It would definitely be wrong to change the behavior of the whole buffer buttons with respect to hidden items before the release. Some of the few people who use the whole buffer buttons may have come to rely on it. Importantly, some Custom internals rely on the whole buffer buttons not operating on hidden buttons. For instance, it is what prevents the whole buffer buttons from recursively descending into subgroups (which would be a bug with very bad consequences). Also, if one changed the behavior, it would be very difficult to avoid introducing a variety of other bugs. For instance, one would have to make sure that the whole buffer buttons would not operate on hidden options that are set outside Custom or are otherwise "rogue", which would also be a very bad bug. There has been a previous discussion on Custom where you proposed to get rid of the State buttons (at least by default). I believe that the present discussion shows that this would be a very bad idea (except maybe in single option buffers). If it were implemented one would definitely need to be able to hide options from the whole buffer buttons. (And some basic, often needed, things like resetting one single option to its standard value would get very complex and clumsy.) I believe that the main problem with the whole buffer buttons (and related functionality) is that it is too visible to beginning users, who should not use them (except in single option buffers), because they are too tricky to use. Sincerely, Luc. ^ permalink raw reply [flat|nested] 57+ messages in thread
* Re: Visual cleanup for customize buffers 2006-01-13 14:18 ` Luc Teirlinck @ 2006-01-13 15:16 ` Kim F. Storm 2006-01-13 19:05 ` Drew Adams ` (5 more replies) 0 siblings, 6 replies; 57+ messages in thread From: Kim F. Storm @ 2006-01-13 15:16 UTC (permalink / raw) Cc: emacs-devel Luc Teirlinck <teirllm@dms.auburn.edu> writes: > Kim Storm wrote: > > - click on whole buffer "Save for Future Sessions" button > > => saves the unset options, but NOT the changed face!! > > That is because you hid it, as I explained. Ok, so I looked in the manual -- which states: If you see `[Show Value]' instead of `[Hide Value]', it means that the value is hidden; the customization buffer initially hides values that take up several lines. Invoke `[Show Value]' to show the value. Sounds pretty harmless to me ... but (much later), it states: Near the top of the customization buffer there are two lines of buttons: ... Each of the other buttons performs an operation--set, save or reset--on each of the settings in the buffer that could meaningfully be set, saved or reset. They do not operate on settings whose values are hidden, nor on subgroups not visible in the buffer. Ok, I never really noticed that last sentence... > > Really?? The "hide value" button is right there when I look! > > I don't see any code that removes the button -- that's what > I added. > > Yes, I somehow got confused here. I do not know why I somehow did not > notice the button there. BTW; in 21.1, the button in called [Show] or [Hide] -- less clutter. Also the text State: HIDDEN, invoke "Show" in the previous line to show. is bogus -- "Show" should be either "Show Value" or "Show Face". > > I don't see why! If people want to save indiviual options, use > the individual State buttons. If people want to save everything, use > the whole buffer buttons. > > It would definitely be wrong to change the behavior of the whole > buffer buttons with respect to hidden items before the release. Some > of the few people who use the whole buffer buttons may have come to > rely on it. So what!? I cannot imagine anybody relying on this buggy(!) behaviour. > Importantly, some Custom internals rely on the whole > buffer buttons not operating on hidden buttons. For instance, it is > what prevents the whole buffer buttons from recursively descending > into subgroups (which would be a bug with very bad consequences). There must surely be ways to ensure that without confusing the user. > Also, if one changed the behavior, it would be very difficult to avoid > introducing a variety of other bugs. For instance, one would have to > make sure that the whole buffer buttons would not operate on hidden > options that are set outside Custom or are otherwise "rogue", which > would also be a very bad bug. Likewise. > > There has been a previous discussion on Custom where you proposed to > get rid of the State buttons (at least by default). I believe that > the present discussion shows that this would be a very bad idea > (except maybe in single option buffers). Even I can get wiser, so I agree ;-) Anyway, IMHO the "full-line" State buttons are way to noticable -- so in 21.1, I had set these variables to reduce the clutter: (setq custom-magic-show nil custom-magic-show-button t) This would replace the big ugly state lines by a small icon button, e.g. [+] in front of the first line of documentation. Sadly, in 22.x, this no longer has the desired effect, as the small icon is shown on a line of its own -- which is just as annoying as the original state button. Really, my main gripe with M-x customize is that the customize buffers are so damn ugly and cluttered, that I only enter when I really need to. It seems like the trend is to add or extend the clutter rather than reducing it. > If it were implemented one > would definitely need to be able to hide options from the whole buffer > buttons. Why? They would just "save all options" -- just like any other GUI applications do when you click "Save" or "Appy" or "Ok". I honestly don't see why emacs has to be different here. Being different (be default) is just confusing. > (And some basic, often needed, things like resetting one > single option to its standard value would get very complex and clumsy.) So what. I bet that most people are used to click "Cancel" and start over if they mess things up too gravely. > I believe that the main problem with the whole buffer buttons (and > related functionality) is that it is too visible to beginning users, > who should not use them (except in single option buffers), because > they are too tricky to use. I believe that the main (and only) problem with the whole buffer buttons is that they are "too tricky to use". Just make them do "the obvious thing" -- that is, to work on the whole buffer. -- Kim F. Storm <storm@cua.dk> http://www.cua.dk ^ permalink raw reply [flat|nested] 57+ messages in thread
* RE: Visual cleanup for customize buffers 2006-01-13 15:16 ` Kim F. Storm @ 2006-01-13 19:05 ` Drew Adams 2006-01-13 19:16 ` David Kastrup ` (4 subsequent siblings) 5 siblings, 0 replies; 57+ messages in thread From: Drew Adams @ 2006-01-13 19:05 UTC (permalink / raw) It seems like the trend is to add or extend the clutter rather than reducing it. Reducing the clutter should be one of the main goals in reworking Customize, after the release. Why? They would just "save all options" -- just like any other GUI applications do when you click "Save" or "Appy" or "Ok". I honestly don't see why emacs has to be different here. Being different (be default) is just confusing. This probably deserves more discussion, after the release. My a priori feeling (meaning that you might convince me otherwise) is that _because_ Emacs lets you set things without saving them (automatically), you must also be able to save individual changes. And _because_ multiple (even many!) changes might have been made, if we let users save more than one at a time then they should be able to specify which changes to save. It is too dangerous to simply save everything that has been changed when you click a Save button. You must be able to see what will be saved. And, preferably, you should be able to modify the set of saves to be made. IOW, "Emacs has to be different here", I think, because it is different in letting you set without saving (which feature I wouldn't want to sacrifice). You can end up with lots of changes, some of which you might even have forgotten you made, and some of which you do not really want to save. This difference is magnified in importance by the fact that Emacs is typically used in very long editor sessions - people keep the same session running for days, weeks, and even months at a time. It is too easy to forget that you changed something long ago which you don't necessarily want to save for future sessions. By making the changes that will be saved explicit (i.e., notifying the user), I think everyone should be satisfied. Those who want Save to simply save everything would just confirm (not hard to do). Those who want to save only some changes would have the opportunity to do so. ^ permalink raw reply [flat|nested] 57+ messages in thread
* Re: Visual cleanup for customize buffers 2006-01-13 15:16 ` Kim F. Storm 2006-01-13 19:05 ` Drew Adams @ 2006-01-13 19:16 ` David Kastrup 2006-01-13 23:28 ` Luc Teirlinck ` (3 subsequent siblings) 5 siblings, 0 replies; 57+ messages in thread From: David Kastrup @ 2006-01-13 19:16 UTC (permalink / raw) Cc: Luc Teirlinck, emacs-devel storm@cua.dk (Kim F. Storm) writes: > Luc Teirlinck <teirllm@dms.auburn.edu> writes: > >> Kim Storm wrote: >> >> - click on whole buffer "Save for Future Sessions" button >> >> => saves the unset options, but NOT the changed face!! >> >> That is because you hid it, as I explained. > > Ok, so I looked in the manual -- which states: > > If you see `[Show Value]' instead of `[Hide Value]', it means that > the value is hidden; the customization buffer initially hides > values that take up several lines. Invoke `[Show Value]' to show > the value. > > Sounds pretty harmless to me ... but (much later), it states: > > Near the top of the customization buffer there are two lines of > buttons: > ... > Each of the other buttons performs an operation--set, save or > reset--on each of the settings in the buffer that could > meaningfully be set, saved or reset. They do not operate on > settings whose values are hidden, nor on subgroups not visible in > the buffer. > > Ok, I never really noticed that last sentence... Actually, I think this behavior might have some usefulness as a quirk, it is too incoherent to be a feature. a) to be "expected" behavior, the naming would have to be something like Access/Disregard instead of Show/Hide. Show/hide implies that only the visibility is concerned. b) if the visibility affects the operation of "save settings", it makes absolutely no sense that some options start out being shown, others hidden. -- David Kastrup, Kriemhildstr. 15, 44793 Bochum ^ permalink raw reply [flat|nested] 57+ messages in thread
* Re: Visual cleanup for customize buffers 2006-01-13 15:16 ` Kim F. Storm 2006-01-13 19:05 ` Drew Adams 2006-01-13 19:16 ` David Kastrup @ 2006-01-13 23:28 ` Luc Teirlinck 2006-01-13 23:34 ` Luc Teirlinck 2006-01-14 16:14 ` Richard M. Stallman 2006-01-14 0:08 ` Luc Teirlinck ` (2 subsequent siblings) 5 siblings, 2 replies; 57+ messages in thread From: Luc Teirlinck @ 2006-01-13 23:28 UTC (permalink / raw) Cc: emacs-devel Kim Storm wrote: BTW; in 21.1, the button in called [Show] or [Hide] -- less clutter. Also the text State: HIDDEN, invoke "Show" in the previous line to show. is bogus -- "Show" should be either "Show Value" or "Show Face". Both the change you mention above and the adding of the newline you want to remove were installed in CVS on July 20, 2002 by Richard: * cus-edit.el (custom-variable-value-create): Say "Show Value", not just "Show". Also "Hide Value". Output a newline before the doc string. I hope Richard remembers why he added the newline and why that newline is not necessary for faces. Sincerely, Luc. ^ permalink raw reply [flat|nested] 57+ messages in thread
* Re: Visual cleanup for customize buffers 2006-01-13 23:28 ` Luc Teirlinck @ 2006-01-13 23:34 ` Luc Teirlinck 2006-01-14 16:14 ` Richard M. Stallman 1 sibling, 0 replies; 57+ messages in thread From: Luc Teirlinck @ 2006-01-13 23:34 UTC (permalink / raw) Cc: emacs-devel >From my previous message: Both the change you mention above and the adding of the newline you want to remove were installed in CVS on July 20, 2002 by Richard: To quote it more in full, showing a related change for "Show/Hide Face" (even more of what you consider clutter): * cus-edit.el (custom-variable-value-create): Say "Show Value", not just "Show". Also "Hide Value". Output a newline before the doc string. (custom-face-value-create): Say "Show Face" and "Hide Face". Sincerely, Luc. ^ permalink raw reply [flat|nested] 57+ messages in thread
* Re: Visual cleanup for customize buffers 2006-01-13 23:28 ` Luc Teirlinck 2006-01-13 23:34 ` Luc Teirlinck @ 2006-01-14 16:14 ` Richard M. Stallman 1 sibling, 0 replies; 57+ messages in thread From: Richard M. Stallman @ 2006-01-14 16:14 UTC (permalink / raw) Cc: emacs-devel, storm * cus-edit.el (custom-variable-value-create): Say "Show Value", not just "Show". Also "Hide Value". Output a newline before the doc string. I hope Richard remembers why he added the newline and why that newline is not necessary for faces. I do sometimes forget, but before you start reminding me to do something, please allow me a chance to do it! The simple mechanics of my responding to a message can take more than a day. ^ permalink raw reply [flat|nested] 57+ messages in thread
* Re: Visual cleanup for customize buffers 2006-01-13 15:16 ` Kim F. Storm ` (2 preceding siblings ...) 2006-01-13 23:28 ` Luc Teirlinck @ 2006-01-14 0:08 ` Luc Teirlinck 2006-01-14 0:44 ` Luc Teirlinck 2006-01-14 16:14 ` Richard M. Stallman 5 siblings, 0 replies; 57+ messages in thread From: Luc Teirlinck @ 2006-01-14 0:08 UTC (permalink / raw) Cc: emacs-devel Kim Storm wrote: Really, my main gripe with M-x customize is that the customize buffers are so damn ugly and cluttered, that I only enter when I really need to. You do not need to. Just use `M-x customize-browse'. Sincerely, Luc. ^ permalink raw reply [flat|nested] 57+ messages in thread
* Re: Visual cleanup for customize buffers 2006-01-13 15:16 ` Kim F. Storm ` (3 preceding siblings ...) 2006-01-14 0:08 ` Luc Teirlinck @ 2006-01-14 0:44 ` Luc Teirlinck 2006-01-14 1:56 ` Kim F. Storm 2006-01-14 16:14 ` Richard M. Stallman 2006-01-14 16:14 ` Richard M. Stallman 5 siblings, 2 replies; 57+ messages in thread From: Luc Teirlinck @ 2006-01-14 0:44 UTC (permalink / raw) Cc: emacs-devel Kim Storm wrote: > (And some basic, often needed, things like resetting one > single option to its standard value would get very complex and clumsy.) So what. I bet that most people are used to click "Cancel" and start over if they mess things up too gravely. Suppose I save 10 different complex items in a Custom buffer for future sessions. Some sessions later I want to reset one of these to its standard value. I do not want to reset the other nine and redo them, because they are complex and would take a lot of work to redo, even if I actually could remember the values. How could I handle this without individual State buttons? How is your magic whole buffer "Cancel" button supposed to help me in this situation? > If it were implemented one > would definitely need to be able to hide options from the whole buffer > buttons. Why? They would just "save all options" -- just like any other GUI applications do when you click "Save" or "Appy" or "Ok". I honestly don't see why emacs has to be different here. Being different (be default) is just confusing. Two reasons: firstly, that interface has serious flaws and secondly, programs that use it take special steps to minimize the consequences of these flaws, which Emacs does not take at all, quite to the contrary. The example I gave above illustrates both reasons. In the "Apply-OK-Cancel" interface I can not even reset anything to its standard value to begin with, once I have OK'ed it. I can not even easily figure out what the standard value is. This is a major nuisance. The fact that you have to Apply or OK everything at once or completely punt, click "Cancel", loosing _all_ your edits and closing the application and then start it up again and start from scratch is another major (and very irritating) nuisance. But most applications with such an interface would limit customizability to simple enable-disable toggles and radio buttons, so at least you do not lose anything complex. This is not the case for Emacs customizations (except in the Options menubar item). Basically, the "Apply-OK-Cancel" interface becomes completely disfunctional once you apply it to a customization buffer containing several options that can be set to complex values. That is also why the Custom whole buffer buttons are completely disfunctional in multi-option buffers. Sincerely, Luc. ^ permalink raw reply [flat|nested] 57+ messages in thread
* Re: Visual cleanup for customize buffers 2006-01-14 0:44 ` Luc Teirlinck @ 2006-01-14 1:56 ` Kim F. Storm 2006-01-14 2:58 ` Chong Yidong 2006-01-14 6:10 ` Drew Adams 2006-01-14 16:14 ` Richard M. Stallman 1 sibling, 2 replies; 57+ messages in thread From: Kim F. Storm @ 2006-01-14 1:56 UTC (permalink / raw) Cc: emacs-devel Luc Teirlinck <teirllm@dms.auburn.edu> writes: > Kim Storm wrote: > > > (And some basic, often needed, things like resetting one > > single option to its standard value would get very complex and clumsy.) > > So what. I bet that most people are used to click "Cancel" and start > over if they mess things up too gravely. > > Suppose I save 10 different complex items in a Custom buffer for > future sessions. Some sessions later I want to reset one of these to > its standard value. I do not want to reset the other nine and redo > them, because they are complex and would take a lot of work to redo, > even if I actually could remember the values. How could I handle this > without individual State buttons? You don't have to... as I now believe that we should keep the state buttons! .. so just use the state button to reset the option. Or you could just customize the individual option and reset it. > How is your magic whole buffer > "Cancel" button supposed to help me in this situation? It can't -- since there is no magic about it. :-) > > > If it were implemented one > > would definitely need to be able to hide options from the whole buffer > > buttons. > > Why? They would just "save all options" -- just like any other GUI > applications do when you click "Save" or "Appy" or "Ok". I honestly > don't see why emacs has to be different here. Being different (be > default) is just confusing. > > Two reasons: firstly, that interface has serious flaws and secondly, > programs that use it take special steps to minimize the consequences > of these flaws, which Emacs does not take at all, quite to the contrary. I've not seen those "serious flaws" ... or not though much about them. .. that's the interface, so that's what I (have to) use. > > The example I gave above illustrates both reasons. How often do you do that? How often does the average emacs user do that? I doubt it happens very often ... and we should design the interface to be optimal for the "normal case" (which should be familar to what the user expects from working with other applications), and still provide the advanced capabilities for the expert users. Having both the "whole buffer" buttons and the "state" buttons serves these purposes very well IMO. > In the > "Apply-OK-Cancel" interface I can not even reset anything to its > standard value to begin with, once I have OK'ed it. I can not even > easily figure out what the standard value is. This is a major nuisance. Use the State button. > The fact that you have to Apply or OK everything at once or completely > punt, click "Cancel", loosing _all_ your edits and closing the > application and then start it up again and start from scratch is > another major (and very irritating) nuisance. Sure, but most users would expect things to work like that. So there is no reason to not provide the ability to do so in emacs. With the additional state buttons, we can also manage individual options, which is better than what other programs can do -- which is excellent. But the two supplements each other (and thus suits different groups of users). > But most applications > with such an interface would limit customizability to simple > enable-disable toggles and radio buttons, so at least you do not lose > anything complex. This is not the case for Emacs customizations > (except in the Options menubar item). That is not true. E.g. in a browser, you can configure fonts, filenames, urls, and a lot of other options on such pages. > > Basically, the "Apply-OK-Cancel" interface becomes completely > disfunctional once you apply it to a customization buffer containing > several options that can be set to complex values. That is also why > the Custom whole buffer buttons are completely disfunctional in > multi-option buffers. I completely disagree! This is a well-known customization interface, which suits its purpose quite well in most applications, so I just don't see why you claim it is completely disfunctional in Emacs. If we have BOTH the whole buffer "apply ok cancel" buttons, AND the individual STATE buttons, I cannot understand why the "apply ok cancel" buttons need any magic behaviour -- they should simply apply to ALL modified options (in the buffer). There's nothing disfunctional about that IMO. Let me repeat my point of view: The problem is not the whole buffer buttons as such; rather it is the completely obscure functionality of those buttons -- where you really need to be an expert to understand what they do. Just fix the functionality to do the "natural thing" (and keep the State buttons for the advanced/expert users who want finer control). -- Kim F. Storm <storm@cua.dk> http://www.cua.dk ^ permalink raw reply [flat|nested] 57+ messages in thread
* Re: Visual cleanup for customize buffers 2006-01-14 1:56 ` Kim F. Storm @ 2006-01-14 2:58 ` Chong Yidong 2006-01-14 6:10 ` Drew Adams 1 sibling, 0 replies; 57+ messages in thread From: Chong Yidong @ 2006-01-14 2:58 UTC (permalink / raw) Cc: Luc Teirlinck, emacs-devel > Let me repeat my point of view: > > The problem is not the whole buffer buttons as such; rather it is the > completely obscure functionality of those buttons -- where you really > need to be an expert to understand what they do. Just fix the > functionality to do the "natural thing" (and keep the State buttons > for the advanced/expert users who want finer control). I concur. ^ permalink raw reply [flat|nested] 57+ messages in thread
* RE: Visual cleanup for customize buffers 2006-01-14 1:56 ` Kim F. Storm 2006-01-14 2:58 ` Chong Yidong @ 2006-01-14 6:10 ` Drew Adams 1 sibling, 0 replies; 57+ messages in thread From: Drew Adams @ 2006-01-14 6:10 UTC (permalink / raw) > Basically, the "Apply-OK-Cancel" interface becomes > completely disfunctional once you apply it to a > customization buffer containing several options that > can be set to complex values. That is also why the > Custom whole buffer buttons are completely > disfunctional in multi-option buffers. I completely disagree! This is a well-known customization interface, which suits its purpose quite well in most applications, so I just don't see why you claim it is completely disfunctional in Emacs. I don't think it's completely dysfunctional (if fixed), but I think it's necessarily inadequate for Emacs. See below. If we have BOTH the whole buffer "apply ok cancel" buttons, AND the individual STATE buttons, I cannot understand why the "apply ok cancel" buttons need any magic behaviour -- they should simply apply to ALL modified options (in the buffer). There's nothing disfunctional about that IMO. Even without the show/hide monstrosity, the problems are that 1) you don't know what you're getting (what changes will be saved) and 2) you cannot modify that set of save candidates. Let me repeat my point of view: The problem is not the whole buffer buttons as such; rather it is the completely obscure functionality of those buttons -- where you really need to be an expert to understand what they do. Just fix the functionality to do the "natural thing" (and keep the State buttons for the advanced/expert users who want finer control). There is more than one issue that has been raised about the whole-buffer buttons: 1. Luc pointed out that there are currently problems wrt acting on or not acting on changes that are hidden. Kim's point about this is, I think, that things could be simplified so that there would be no such hide/show problems with whole-buffer buttons: hiding info should not having anything to do with which preferences are acted upon. I don't think Luc disagrees with that (I don't, in any case), though Luc might disagree that it will be simple to solve all of the hide/show problems. However, a) we're not there yet (the problems exist, today) and b) that is anyway not a sufficient argument in favor of a simple Save All button or a simple Apply-Ok-Cancel UI, because it does not address the other arguments that have been raised (see below). 2. I pointed out that Emacs lets users change preferences without necessarily saving them. This is a big difference from most applications. A UI that automatically saves all changes (on exit via `OK') loses the advantage that Emacs offers in this area. Being able to change multiple preferences and experiment with them without automatically saving is something we should not give up. 3. I pointed out that not only can you set preferences without saving them, but Emacs sessions are typically much longer than those of other apps. These two facts, together, mean that a button that simply saves all changes is not appropriate. You might have changed many preferences, perhaps over a long period of time, and you might even have forgotten some of those changes. Users need to be informed of just what has changed and so will potentially be saved, and asked for their confirmation before saving. It would be better to also let users select or deselect changed preferences for saving. IOW, because of the decoupling of setting and saving, there is a need to determine which changes to save - a one-size-fits-all Save button isn't good enough. And the individual State buttons don't serve well here either. You don't want to be _required_ to explicitly act on each preference separately. You want to be able to quickly save all of them, if appropriate, after review, or quickly save all except a few that you uncheck. 4. I expect interactive customization to be extended beyond what is strictly the Customize buffer UI. That is, I hope that other ways of changing preference values will in the future work hand-in-glove with Customize, so that you can, for example, use a handy graphic tool or command to change face properties, yet still take advantage of the Customize UI to save such changes, undo them, or tweak them further. That is, I'd like to see the Customize UI recognize (at least some) changes made outside it as being equivalent to changes made inside it. If this happens, it too will argue against having only a simple Save All button and in favor of informing users of what potentially needs saving and letting them choose which changes to save. This is really the same as argument #3, but it strengthens that argument by extending its scope. No matter which preferences are changed, or how they are changed, the Customize UI should help you recognize unsaved changes and make it easy for you to save those you want to save. Think of `customize-customized' - that should be the first building block of any whole-buffer Save function for customize. At the very least, clicking a whole-buffer Save button should do the equivalent of `customize-customized' for the preferences in the current Customize buffer, so you see what changes you're saving. We can obviously do better than simply displaying a separate list of the changed preferences, but we need this _functionality_ of informing the user of what's changed, in one form or another. ^ permalink raw reply [flat|nested] 57+ messages in thread
* Re: Visual cleanup for customize buffers 2006-01-14 0:44 ` Luc Teirlinck 2006-01-14 1:56 ` Kim F. Storm @ 2006-01-14 16:14 ` Richard M. Stallman 1 sibling, 0 replies; 57+ messages in thread From: Richard M. Stallman @ 2006-01-14 16:14 UTC (permalink / raw) Cc: emacs-devel, storm We are not going to eliminate the individual State buttons. ^ permalink raw reply [flat|nested] 57+ messages in thread
* Re: Visual cleanup for customize buffers 2006-01-13 15:16 ` Kim F. Storm ` (4 preceding siblings ...) 2006-01-14 0:44 ` Luc Teirlinck @ 2006-01-14 16:14 ` Richard M. Stallman 2006-01-14 20:50 ` Lennart Borgman ` (2 more replies) 5 siblings, 3 replies; 57+ messages in thread From: Richard M. Stallman @ 2006-01-14 16:14 UTC (permalink / raw) Cc: teirllm, emacs-devel They do not operate on settings whose values are hidden, nor on subgroups not visible in the buffer. Indeed, this seems to be an intentional feature--not a quirk or a bug. Let's not change it. Agreed. The show/hide names even seem to imply that they only affect the display, not the behavior. That is a valid argument that there is a flaw in this feature. For now, we could fix it by changing the text that the State line displays in this case, to something like SET: Value has been set for this session; CAN'T BE SAVED NOW because hidden Other bigger changes could be considered for after the release but not for now. a) to be "expected" behavior, the naming would have to be something like Access/Disregard instead of Show/Hide. That might be a change we could make now, but I fear it will not be easy to decide what it should really say. b) if the visibility affects the operation of "save settings", it makes absolutely no sense that some options start out being shown, others hidden. It is absolutely essential that large values start out hidden. - If we keep global buttons (or equivalent menu items or whatever) that operate on multiple preferences all at once, each button action should: 1) explicitly list the preferences that will be affected or those that will *not* be affected (or perhaps both?), whichever group is smaller, and 2) require confirmation. That could be a good solution to that flaw, if it works out well in practice. - One way to do this would be to provide a check box next to each preference in the buffer and 1) precheck the boxes of those preferences that the program thinks could be targets If the "hide value" buttons control this, we don't need a checkbox to control it too. ^ permalink raw reply [flat|nested] 57+ messages in thread
* Re: Visual cleanup for customize buffers 2006-01-14 16:14 ` Richard M. Stallman @ 2006-01-14 20:50 ` Lennart Borgman 2006-01-14 21:32 ` Luc Teirlinck 2006-01-14 21:58 ` Drew Adams 2006-01-15 1:40 ` Luc Teirlinck 2 siblings, 1 reply; 57+ messages in thread From: Lennart Borgman @ 2006-01-14 20:50 UTC (permalink / raw) Cc: emacs-devel, teirllm, Kim F. Storm Richard M. Stallman wrote: > b) if the visibility affects the operation of "save settings", it > makes absolutely no sense that some options start out being shown, > others hidden. > > It is absolutely essential that large values start out hidden. > Would it perhaps be easy to make it impossible to hide a value that has been changed and not set in the current custom buffer? That could perhaps be a bit less confusing. ^ permalink raw reply [flat|nested] 57+ messages in thread
* Re: Visual cleanup for customize buffers 2006-01-14 20:50 ` Lennart Borgman @ 2006-01-14 21:32 ` Luc Teirlinck 2006-01-14 21:47 ` Lennart Borgman 0 siblings, 1 reply; 57+ messages in thread From: Luc Teirlinck @ 2006-01-14 21:32 UTC (permalink / raw) Cc: storm, rms, emacs-devel Lennart Borgman wrote: Would it perhaps be easy to make it impossible to hide a value that has been changed and not set in the current custom buffer? That could perhaps be a bit less confusing. If I understand correctly, it is already supposed to be impossible right now. You should get the minibuffer message: "There are unset changes". Was there some case where this failed for you? So normally, you will never inadvertently fail to Set or Save a value that you have edited, if you use the whole buffer "Set for Current Session" or "Save for Future Sessions" buttons. You will never inadvertently keep edits you did not want to keep if you use the whole buffer "Undo Edits" button. What you can do however, is, for instance, set a value for the current session, and then hide it. Then edit other options and save those for future sessions. The one you had only set for the current session will not be saved. Also, if you have a saved value for an option, and hide it before choosing "Erase Customization", that saved value will not be erased. According to Kim's theory, if I understand it correctly, people accustomed to the "Apply-OK-Cancel" type interface would never use anything but the whole buffer "Save for Future Sessions", "Undo Edits" (and "Finish") buttons. In that case, the fact that these buttons will not work on hidden items will _never_ inconvenience them, because there will be no hidden edited items. Note that in the many years that this feature existed (as long as Custom has been part of Emacs), there was not exactly a flood of complaints by people having been surprised or inconvenienced by it. I know of none (before yesterday). Complaints only started after I pointed the feature out, from people who did not know it existed, and hence probably had never been affected by the feature either. Sincerely, Luc. ^ permalink raw reply [flat|nested] 57+ messages in thread
* Re: Visual cleanup for customize buffers 2006-01-14 21:32 ` Luc Teirlinck @ 2006-01-14 21:47 ` Lennart Borgman 2006-01-15 18:09 ` Luc Teirlinck 2006-01-15 18:41 ` Kim F. Storm 0 siblings, 2 replies; 57+ messages in thread From: Lennart Borgman @ 2006-01-14 21:47 UTC (permalink / raw) Cc: emacs-devel, rms, storm Luc Teirlinck wrote: > Lennart Borgman wrote: > > Would it perhaps be easy to make it impossible to hide a value that has > been changed and not set in the current custom buffer? That could > perhaps be a bit less confusing. > > If I understand correctly, it is already supposed to be impossible > right now. You should get the minibuffer message: "There are unset changes". > Was there some case where this failed for you? > No, sorry, I actually forgot that. However the other cases you mentioned seem to me serious enough. > According to Kim's theory, if I understand it correctly, people > accustomed to the "Apply-OK-Cancel" type interface would never > use anything but the whole buffer "Save for Future Sessions", > "Undo Edits" (and "Finish") buttons. In that case, the fact that > these buttons will not work on hidden items will _never_ inconvenience > them, because there will be no hidden edited items. > I would guess it is quite natural to use Hide but still assume that the whole buffer buttons apply. > Note that in the many years that this feature existed (as long as > Custom has been part of Emacs), there was not exactly a flood of > complaints by people having been surprised or inconvenienced by it. > I know of none (before yesterday). Complaints only started after I > pointed the feature out, from people who did not know it existed, and > hence probably had never been affected by the feature either. > My impression when we started looking at Custom was that not many developers or advanced users were using it. Could that perhaps be part of the reason that there were not many complaints? A feature as obscure as this (that hidden values do not get saved or set) is very easy to miss. You probably set several features if you hide the value before hitting the set or save buttons. When you perhaps quite a while afterward notice something is not working you may have forgotten or you may very well guess it is some kind of bug instead. ^ permalink raw reply [flat|nested] 57+ messages in thread
* Re: Visual cleanup for customize buffers 2006-01-14 21:47 ` Lennart Borgman @ 2006-01-15 18:09 ` Luc Teirlinck 2006-01-15 18:41 ` Kim F. Storm 1 sibling, 0 replies; 57+ messages in thread From: Luc Teirlinck @ 2006-01-15 18:09 UTC (permalink / raw) Cc: emacs-devel, rms, storm Lennart Borgman wrote: My impression when we started looking at Custom was that not many developers or advanced users were using it. We do get bug reports about Custom, so it _is_ used by many people knowledgeable enough to file bug reports. Some Emacs developers apparently do not use it. I use it extensively, but never use the whole buffer buttons in multi-option buffers, except for testing purposes if I am making code changes to them. I have the impression that the latter use _still_ means that I use the whole buffer buttons in multi-option buffers a lot more extensively than other people do. Custom is, in as far as I know, the only reliable option browser Emacs has. The `apropos' facility is not a reliable alternative, because you can not find non-loaded stuff that way and, in my own experience, most of the time the options I need to find turn out not to be loaded. If after using customize-browse, you find the option you want, it is a lot more convenient to customize it right in the buffer you have in front of you, than to visit your .emacs and start writing some Lisp code, no matter how well you know Elisp. So there are good reasons for advanced users to use it. Sincerely, Luc. ^ permalink raw reply [flat|nested] 57+ messages in thread
* Re: Visual cleanup for customize buffers 2006-01-14 21:47 ` Lennart Borgman 2006-01-15 18:09 ` Luc Teirlinck @ 2006-01-15 18:41 ` Kim F. Storm 2006-01-15 19:59 ` Luc Teirlinck 1 sibling, 1 reply; 57+ messages in thread From: Kim F. Storm @ 2006-01-15 18:41 UTC (permalink / raw) Cc: Luc Teirlinck, rms, emacs-devel Lennart Borgman <lennart.borgman.073@student.lu.se> writes: > A feature as > obscure as this (that hidden values do not get saved or set) is very > easy to miss. You probably set several features if you hide the value > before hitting the set or save buttons. When you perhaps quite a while > afterward notice something is not working you may have forgotten or > you may very well guess it is some kind of bug instead. Whatever the reason for the "feature", it is IMHO completely broken as a user interface. For options like faces which are hidden initially (and other options where Luc pointed out my changes has problems because you need to hide them to be able to navigate the customize buffer), the user may easily hide such values for no other reason than "to hide it". -- Kim F. Storm <storm@cua.dk> http://www.cua.dk ^ permalink raw reply [flat|nested] 57+ messages in thread
* Re: Visual cleanup for customize buffers 2006-01-15 18:41 ` Kim F. Storm @ 2006-01-15 19:59 ` Luc Teirlinck 0 siblings, 0 replies; 57+ messages in thread From: Luc Teirlinck @ 2006-01-15 19:59 UTC (permalink / raw) Cc: lennart.borgman.073, rms, emacs-devel Kim Storm wrote: Whatever the reason for the "feature", it is IMHO completely broken as a user interface. (The "feature" being that the whole buffer buttons ignore hidden items.) As I pointed out before, this is too dangerous to mess with before the release, because Custom internals rely too heavily on it, as well as for some other reasons. After the release, this has to be considered in conjunction with other possible changes which might completely change the problem, or even make it irrelevant. I do not see what the purpose of continuing to discuss this _right now_ is. What is easy and safe to do right now is to better inform people that these buttons do not operate on groups, hidden options or options changed outside Custom, by saying that in the text above these buttons, as I proposed earlier. Sincerely, Luc. ^ permalink raw reply [flat|nested] 57+ messages in thread
* RE: Visual cleanup for customize buffers 2006-01-14 16:14 ` Richard M. Stallman 2006-01-14 20:50 ` Lennart Borgman @ 2006-01-14 21:58 ` Drew Adams 2006-01-14 22:17 ` Drew Adams 2006-01-15 1:40 ` Luc Teirlinck 2 siblings, 1 reply; 57+ messages in thread From: Drew Adams @ 2006-01-14 21:58 UTC (permalink / raw) - If we keep global buttons (or equivalent menu items or whatever) that operate on multiple preferences all at once, each button action should: 1) explicitly list the preferences that will be affected or those that will *not* be affected (or perhaps both?), whichever group is smaller, and 2) require confirmation. That could be a good solution to that flaw, if it works out well in practice. - One way to do this would be to provide a check box next to each preference in the buffer and 1) precheck the boxes of those preferences that the program thinks could be targets If the "hide value" buttons control this, we don't need a checkbox to control it too. You're right that we don't need two different mechanisms to control this. But hide/show currently does two things: 1) control the scope of whole-buffer actions and, 2) well, hide/show stuff. Check boxes are only one suggestion for #1. In any case, I think it might make sense to separate show/hide (which has as aim to remove clutter or show details) from selection or marking of preferences for acting upon. I like the way this is done in Dired. There, we have one mechanism for marking files to act upon and another mechanism (kill lines) for hiding ("omitting") files - we don't simply expect people to hide all the files that are not to be acted upon. It's true, however, that if you hide a file in Dired and then try to, say, mark all files that have its extension, the hidden file will not be marked - hidden files are not seen by marking commands. This does mean that you can, in effect, use hide instead of unmark in many cases - but you cannot use show instead of mark: the scope of actions is always indicated explicitly by the presence of visible marks. If Dired were like Customize is currently, then the only mechanism for "marking/unmarking" files would be hiding/showing them. I think that would be a step backward, because it is clearer to see both the marked and the unmarked objects when you perform an action on the former. So, for Customize as for Dired, perhaps it is better not to have the target set for actions be affected by what is currently visible. No matter which way the design works, there can be confusion if the two (mark & show) are related: if actions affect hidden stuff, then you are not seeing everything that is affected; if they don't affect hidden stuff, then you can end up using only show/hide also to determine the scope of actions (giving it two different purposes). To me, show/hide has its own use and purpose, and it should probably not also define the scope of actions. However, as in the case of Dired, it could affect what gets "unmarked" (and so, indirectly, what gets acted upon). The marks would at all times show explicitly what will be acted upon, however. Dired handles marks on hidden stuff pretty well, I think: 1) you cannot mark a hidden file (it is not seen by marking commands), and 2) if you hide a file that is (already) marked, it is unmarked by hiding it. This means that all hidden files are unmarked, but the hide/show mechanism is not generally what is used to directly control the scope of actions - instead, explicit marks indicate that scope. And although hide effectively causes unmark, show never causes mark. Whatever we decide, the scope of actions should somehow be made clear in the case of hidden stuff - let the user know that foo and toto are hidden and therefore won't be acted upon (e.g. saved) - or will be acted upon, depending on the design we choose (I prefer the former). The use of a separate marking mechanism would, as in the case of Dired, help make this clear: it is simple in Dired to check whether marking affects hidden files (no) and whether hiding affects marked files (yes). And most importantly, an explicit mark, not the visibility of objects, indicates the scope of actions. ^ permalink raw reply [flat|nested] 57+ messages in thread
* RE: Visual cleanup for customize buffers 2006-01-14 21:58 ` Drew Adams @ 2006-01-14 22:17 ` Drew Adams 0 siblings, 0 replies; 57+ messages in thread From: Drew Adams @ 2006-01-14 22:17 UTC (permalink / raw) I like the way this is done in Dired. There, we have one mechanism for marking files to act upon and another mechanism (kill lines) for hiding ("omitting") files - we don't simply expect people to hide all the files that are not to be acted upon. I should point out that even though I used "omitting" here in parentheses I was thinking of `dired-kill-line', rather than the `omit' functionality of dired-x. The latter is a bit different, in some regards, from what I described. For example, marked files are never omitted, but they can be hidden by "dired-killing" them. The analogy for `omit' in Customize would be that stuff marked for possible action could never be hidden. I think I prefer the behavior of `dired-kill-line' in this regard, but both behaviors are probably worth discussing in the context of Customize. ^ permalink raw reply [flat|nested] 57+ messages in thread
* Re: Visual cleanup for customize buffers 2006-01-14 16:14 ` Richard M. Stallman 2006-01-14 20:50 ` Lennart Borgman 2006-01-14 21:58 ` Drew Adams @ 2006-01-15 1:40 ` Luc Teirlinck 2006-01-15 23:08 ` Richard M. Stallman 2 siblings, 1 reply; 57+ messages in thread From: Luc Teirlinck @ 2006-01-15 1:40 UTC (permalink / raw) Cc: emacs-devel, storm Richard Stallman wrote: That is a valid argument that there is a flaw in this feature. For now, we could fix it by changing the text that the State line displays in this case, to something like SET: Value has been set for this session; CAN'T BE SAVED NOW because hidden That might be difficult to do and also might have some other problems. The State of hidden items his HIDDEN, not SET, even when the State would be SET when shown. On the other hand it would be trivial to change the text in front of the sequence of whole buffer buttons from: Operate on everything in this buffer: to: Operate on everything in this buffer except groups, HIDDEN items or items CHANGED outside Customize: Sincerely, Luc. ^ permalink raw reply [flat|nested] 57+ messages in thread
* Re: Visual cleanup for customize buffers 2006-01-15 1:40 ` Luc Teirlinck @ 2006-01-15 23:08 ` Richard M. Stallman 2006-01-16 4:19 ` Luc Teirlinck 2006-01-17 4:20 ` Luc Teirlinck 0 siblings, 2 replies; 57+ messages in thread From: Richard M. Stallman @ 2006-01-15 23:08 UTC (permalink / raw) Cc: storm, emacs-devel That might be difficult to do and also might have some other problems. The State of hidden items his HIDDEN, not SET, even when the State would be SET when shown. That is true. We could perhaps change that. I suggest a different solution: don't allow hiding a setting that is in state "SET". Or, if we decide that hiding such a setting is useful, we could query for confirmation before hiding such a setting. Operate on everything in this buffer except groups, HIDDEN items or items CHANGED outside Customize: Some sort of change there might be good, but that is too long. Maybe this: Operate on all settings in this buffer that aren't marked HIDDEN. We need not mention the ROGUE case here, because that's a different kind of issue: the operation _tries_ to operate on that setting, but it can't do so because the setting is not suitable to operate on. ^ permalink raw reply [flat|nested] 57+ messages in thread
* Re: Visual cleanup for customize buffers 2006-01-15 23:08 ` Richard M. Stallman @ 2006-01-16 4:19 ` Luc Teirlinck 2006-01-19 17:44 ` Richard M. Stallman 2006-01-17 4:20 ` Luc Teirlinck 1 sibling, 1 reply; 57+ messages in thread From: Luc Teirlinck @ 2006-01-16 4:19 UTC (permalink / raw) Cc: emacs-devel, storm Richard Stallman wrote: I suggest a different solution: don't allow hiding a setting that is in state "SET". That would be bad, because unlike EDITED items, SET items can _start out_ hidden when the group is first visited. If you unhide them, you should be able to hide them again without warning. There is _no way_ that these whole buffer buttons (in multi-option buffers) can operate in a sensible way with respect to SET items, hidden or not. The user could have set these items using the menu bar Options item or using `M-x customize-set-variable', without any intent to save them (both mark the item SET). But after quite a while, he searches for another item, which, by coincidence, turns out to be in the same group as one or more of the items he has set outside any Custom buffer. The group is huge, so he does not see this. He saves the one item he wants to save and inadvertently also saves the items he only wanted to set temporarily. The above is a way worse and way more likely problem than the user hiding an option he has set with a state button. Nobody knowing how to use a State button is going to use the whole buffer buttons in multi-option buffers anyway. If they do, and they hid an item, it most likely is because they did not want to save it, certainly if the text above the whole buffer buttons clearly points out that HIDDEN items will not be saved. Just clearly stating above the whole buffer buttons that they do not apply to HIDDEN items should, for now, eliminate user confusion about hidden items. Solving the other, more likely, problem I pointed out above could be discussed after the release. Maybe, after the release, it would be better to replace the current set of six whole buffer buttons with three: "Save Edited Items" "Undo Edits" "Kill buffer" "Save Edited Items" is analogous to "Apply", "Kill Buffer" to "Cancel" in other applications. I do not believe that there is a need in Emacs for the "OK" of other applications (which means "Save Edited Items and Kill Buffer"). As the name says, "Save Edited Items" would only save EDITED items. I believe that this is a lot safer for beginning users who are likely to have set items with the menu bar. If they want to save items set with the menu bar, they should use "Save Options" from the Menu bar. If they want to save items they have set with a State button, they should save them with the State button. If the whole buffer buttons _only_ affect EDITED items, then there is no problem with hidden options, because EDITED items can not be HIDDEN. Sincerely, Luc. ^ permalink raw reply [flat|nested] 57+ messages in thread
* Re: Visual cleanup for customize buffers 2006-01-16 4:19 ` Luc Teirlinck @ 2006-01-19 17:44 ` Richard M. Stallman 0 siblings, 0 replies; 57+ messages in thread From: Richard M. Stallman @ 2006-01-19 17:44 UTC (permalink / raw) Cc: emacs-devel, storm I suggest a different solution: don't allow hiding a setting that is in state "SET". That would be bad, because unlike EDITED items, SET items can _start out_ hidden when the group is first visited. We could change that too, if it makes things clearer. But after quite a while, he searches for another item, which, by coincidence, turns out to be in the same group as one or more of the items he has set outside any Custom buffer. The group is huge, so he does not see this. He saves the one item he wants to save and inadvertently also saves the items he only wanted to set temporarily. That is a good point, and it suggests that these multi-setting commands ought to display a list of the settings they are really going to operate on, when they ask for confirmation. Then it would not be cause special problem if SET settings are hidden. ^ permalink raw reply [flat|nested] 57+ messages in thread
* Re: Visual cleanup for customize buffers 2006-01-15 23:08 ` Richard M. Stallman 2006-01-16 4:19 ` Luc Teirlinck @ 2006-01-17 4:20 ` Luc Teirlinck 2006-01-17 20:00 ` Richard M. Stallman 1 sibling, 1 reply; 57+ messages in thread From: Luc Teirlinck @ 2006-01-17 4:20 UTC (permalink / raw) Cc: storm, emacs-devel Some sort of change there might be good, but that is too long. Maybe this: Operate on all settings in this buffer that aren't marked HIDDEN. That sounds OK. Sincerely, Luc. ^ permalink raw reply [flat|nested] 57+ messages in thread
* Re: Visual cleanup for customize buffers 2006-01-17 4:20 ` Luc Teirlinck @ 2006-01-17 20:00 ` Richard M. Stallman 2006-01-20 0:18 ` Luc Teirlinck 0 siblings, 1 reply; 57+ messages in thread From: Richard M. Stallman @ 2006-01-17 20:00 UTC (permalink / raw) Cc: storm, emacs-devel Operate on all settings in this buffer that aren't marked HIDDEN. That sounds OK. Would you please put that in? ^ permalink raw reply [flat|nested] 57+ messages in thread
* Re: Visual cleanup for customize buffers 2006-01-17 20:00 ` Richard M. Stallman @ 2006-01-20 0:18 ` Luc Teirlinck 0 siblings, 0 replies; 57+ messages in thread From: Luc Teirlinck @ 2006-01-20 0:18 UTC (permalink / raw) Cc: emacs-devel, storm Richard Stallman wrote: Operate on all settings in this buffer that aren't marked HIDDEN That sounds OK. Would you please put that in? Done. Sincerely, Luc. ^ permalink raw reply [flat|nested] 57+ messages in thread
* Re: Visual cleanup for customize buffers 2006-01-13 12:37 ` Kim F. Storm 2006-01-13 14:18 ` Luc Teirlinck @ 2006-01-13 16:40 ` Stefan Monnier 1 sibling, 0 replies; 57+ messages in thread From: Stefan Monnier @ 2006-01-13 16:40 UTC (permalink / raw) Cc: Luc Teirlinck, emacs-devel > HUH?? I just hide the face to remove the clutter -- not > because I didn't want to save it for future sessions. Agreed. The show/hide names even seem to imply that they only affect the display, not the behavior. Stefan ^ permalink raw reply [flat|nested] 57+ messages in thread
* Re: Visual cleanup for customize buffers 2006-01-12 23:45 ` Luc Teirlinck 2006-01-13 12:37 ` Kim F. Storm @ 2006-01-13 19:04 ` Bill Wohler 2006-01-14 1:28 ` Luc Teirlinck 2006-01-14 5:49 ` Richard M. Stallman 2 siblings, 1 reply; 57+ messages in thread From: Bill Wohler @ 2006-01-13 19:04 UTC (permalink / raw) Luc Teirlinck <teirllm@dms.auburn.edu> writes: > Kim Storm wrote: > > - Don't show the "Hide value" button for trivial values which > fit on one line initially. I don't see ANY reason why a > user would click on that button to, say, hide a boolean > or numeric value. > > To hide them from the whole buffer buttons, from key bindings that > operate on the whole buffer and from menu bar items that operate on > the whole buffer. (These operations ignore hidden options and faces.) You're kidding me. I'm with Kim. Even if this is documented, it is bad UI. To me, Hide means just that. Make it invisible. If I click on a whole buffer button, I'd expect it to effect all of my changes, visible or not. -- Bill Wohler <wohler@newt.com> http://www.newt.com/wohler/ GnuPG ID:610BD9AD Maintainer of comp.mail.mh FAQ and MH-E. Vote Libertarian! If you're passed on the right, you're in the wrong lane. ^ permalink raw reply [flat|nested] 57+ messages in thread
* Re: Visual cleanup for customize buffers 2006-01-13 19:04 ` Bill Wohler @ 2006-01-14 1:28 ` Luc Teirlinck 2006-01-14 1:46 ` Bill Wohler 0 siblings, 1 reply; 57+ messages in thread From: Luc Teirlinck @ 2006-01-14 1:28 UTC (permalink / raw) Cc: emacs-devel Bill Wohler wrote: You're kidding me. I'm with Kim. Even if this is documented, it is bad UI. The whole buffer buttons are a bad UI, with _or_ without the hidden button feature or misfeature. Even if you consider it a misfeature, the fact that the whole buffer buttons do not operate on hidden items is _not_ a regression. The whole buffer buttons have behaved like that ever since Custom was first introduced into Emacs, without any huge flurry of complaints until yesterday, when I pointed this behavior out. Getting rid of the feature would introduce at least two serious bugs, probably more. I believe that the feature was mainly introduced because Per believed that without it fixing those various bugs would be too complex. Those bugs _would_ be regressions. Ones other than the two I know about from reading the code will not be discovered before the release, because no one really uses these whole buffer buttons. Given this I believe that it would be a _really_ bad idea to mess with this stuff now, supposedly "shortly" before the release. After the release, the whole buffer buttons should either be discarded altogether in multiple option buffer buttons or fixed so that they only operate on "selected" items were the difference between "selected" and "hidden" is that nothing is selected by default. Use of Custom as a browser prevents hiding all options by default, which _would_ make the whole buffer buttons usable as is. (Faces and groups are already hidden by default.) Note that even if the whole buffer buttons _would_ operate on hidden items, they would still not operate on the entire buffer: they do not operate on items that are changed outside Custom or are otherwise rogue (and trying to change that would lead to some _really_ serious bugs). Sincerely, Luc. ^ permalink raw reply [flat|nested] 57+ messages in thread
* Re: Visual cleanup for customize buffers 2006-01-14 1:28 ` Luc Teirlinck @ 2006-01-14 1:46 ` Bill Wohler 0 siblings, 0 replies; 57+ messages in thread From: Bill Wohler @ 2006-01-14 1:46 UTC (permalink / raw) Cc: emacs-devel Luc Teirlinck <teirllm@dms.auburn.edu> wrote: > Given this I believe that it would be a _really_ bad idea to mess with > [the whole buffer buttons] now, supposedly "shortly" before the > release. > > After the release, the whole buffer buttons should either be discarded > altogether in multiple option buffer buttons or fixed Concur on both counts. -- Bill Wohler <wohler@newt.com> http://www.newt.com/wohler/ GnuPG ID:610BD9AD Maintainer of comp.mail.mh FAQ and MH-E. Vote Libertarian! If you're passed on the right, you're in the wrong lane. ^ permalink raw reply [flat|nested] 57+ messages in thread
* Re: Visual cleanup for customize buffers 2006-01-12 23:45 ` Luc Teirlinck 2006-01-13 12:37 ` Kim F. Storm 2006-01-13 19:04 ` Bill Wohler @ 2006-01-14 5:49 ` Richard M. Stallman 2006-01-14 15:28 ` Luc Teirlinck 2 siblings, 1 reply; 57+ messages in thread From: Richard M. Stallman @ 2006-01-14 5:49 UTC (permalink / raw) Cc: emacs-devel, storm To hide them from the whole buffer buttons, from key bindings that operate on the whole buffer and from menu bar items that operate on the whole buffer. (These operations ignore hidden options and faces.) Do they ignore options and faces whose _values_ are hidden? That is not the same thing as for the option itself to be hidden. ^ permalink raw reply [flat|nested] 57+ messages in thread
* Re: Visual cleanup for customize buffers 2006-01-14 5:49 ` Richard M. Stallman @ 2006-01-14 15:28 ` Luc Teirlinck 0 siblings, 0 replies; 57+ messages in thread From: Luc Teirlinck @ 2006-01-14 15:28 UTC (permalink / raw) Cc: storm, emacs-devel Richard Stallman wrote: To hide them from the whole buffer buttons, from key bindings that operate on the whole buffer and from menu bar items that operate on the whole buffer. (These operations ignore hidden options and faces.) Do they ignore options and faces whose _values_ are hidden? That is not the same thing as for the option itself to be hidden. They ignore options whose state is `hidden'. I do not know what you mean by the option itself to be hidden. The name of the option or face is always shown, even if the state is `hidden' (meaning that the value and sometimes some other stuff are hidden). Faces are `hidden' by default. So are groups. Sincerely, Luc. ^ permalink raw reply [flat|nested] 57+ messages in thread
* Re: Visual cleanup for customize buffers 2006-01-12 21:58 Visual cleanup for customize buffers Kim F. Storm 2006-01-12 23:45 ` Luc Teirlinck @ 2006-01-13 0:08 ` Luc Teirlinck 2006-01-13 15:24 ` Kim F. Storm 2006-01-13 0:24 ` Luc Teirlinck 2006-01-14 5:49 ` Richard M. Stallman 3 siblings, 1 reply; 57+ messages in thread From: Luc Teirlinck @ 2006-01-13 0:08 UTC (permalink / raw) Cc: emacs-devel Kim Storm wrote: - For choice values, replace the old [Value Menu] Value by the more common [Value v] (where v is a "pull down" icon) I personally find [Value Menu] clearer. - Remove the empty line between the [STATE] line and the documentation. That empty line was added between 21.3 and now. I do not know the reason for that. It might be because some people thought that the empty line made things look clearer, or it might be related to the fact that the widget library sometimes _needs_ blank lines between certain types of widgets to function properly. I personally ran into some not immediately obvious instances of that. (Though not with this particular empty line.) I think that it definitely would be a bad idea to remove the line without knowing why it was added. Is this really important enough to worry about? Sincerely, Luc. ^ permalink raw reply [flat|nested] 57+ messages in thread
* Re: Visual cleanup for customize buffers 2006-01-13 0:08 ` Luc Teirlinck @ 2006-01-13 15:24 ` Kim F. Storm 2006-01-13 19:33 ` martin rudalics 0 siblings, 1 reply; 57+ messages in thread From: Kim F. Storm @ 2006-01-13 15:24 UTC (permalink / raw) Cc: emacs-devel Luc Teirlinck <teirllm@dms.auburn.edu> writes: > Kim Storm wrote: > > - For choice values, replace the old [Value Menu] Value > by the more common [Value v] (where v is a "pull down" icon) > > I personally find [Value Menu] clearer. It is not clear to me at all. Quite often, it is NOT a "value menu", but rather a "type menu", where you select what type of value to assign to the variable. Did you try installing my patch and try my examples (before and after)? Notably, try M-x customize-option cua-normal-cursor-color and change the value to "color and type". > > - Remove the empty line between the [STATE] line and the documentation. > > That empty line was added between 21.3 and now. I do not know the > reason for that. It might be because some people thought that the > empty line made things look clearer, IMO, it doesn't... > or it might be related to the > fact that the widget library sometimes _needs_ blank lines between > certain types of widgets to function properly. Wouldn't a space be sufficient? > I personally ran into > some not immediately obvious instances of that. (Though not with this > particular empty line.) > > I think that it definitely would be a bad idea to remove the line > without knowing why it was added. Is this really important enough to > worry about? IMO, yes. -- Kim F. Storm <storm@cua.dk> http://www.cua.dk ^ permalink raw reply [flat|nested] 57+ messages in thread
* Re: Visual cleanup for customize buffers 2006-01-13 15:24 ` Kim F. Storm @ 2006-01-13 19:33 ` martin rudalics 0 siblings, 0 replies; 57+ messages in thread From: martin rudalics @ 2006-01-13 19:33 UTC (permalink / raw) Cc: Luc Teirlinck, emacs-devel > - Remove the empty line between the [STATE] line and the documentation. > Since my earlier reply, I noticed that the empty line was not added > for faces, which seems inconsequent at first view. But maybe the bug > that the empty line was supposed to fix (if any) does not apply to faces. What bug should "\n\n" fix that "\n" doesn't? I'm using Kim's approach for a couple of months already and didn't encounter any problems so far. Variables and faces are constructed differently in customization buffers. For variables the value is displayed first, followed by state and comment. For a face state and comment appear before the attributes. That's inherently distracting but presumably most people got used to it. I tried to construct faces in the variables' style but had considerable problems when adding / removing a comment. >>I think that it definitely would be a bad idea to remove the line >>without knowing why it was added. Is this really important enough to >>worry about? > > > IMO, yes. > I'd very much appreciate if the extra line were removed. ^ permalink raw reply [flat|nested] 57+ messages in thread
* Re: Visual cleanup for customize buffers 2006-01-12 21:58 Visual cleanup for customize buffers Kim F. Storm 2006-01-12 23:45 ` Luc Teirlinck 2006-01-13 0:08 ` Luc Teirlinck @ 2006-01-13 0:24 ` Luc Teirlinck 2006-01-14 5:48 ` Richard M. Stallman 2006-01-14 5:49 ` Richard M. Stallman 3 siblings, 1 reply; 57+ messages in thread From: Luc Teirlinck @ 2006-01-13 0:24 UTC (permalink / raw) Cc: emacs-devel Kim Storm wrote: - Remove the empty line between the [STATE] line and the documentation. Since my earlier reply, I noticed that the empty line was not added for faces, which seems inconsequent at first view. But maybe the bug that the empty line was supposed to fix (if any) does not apply to faces. Maybe somebody will remember why the empty line was added for variables. Sincerely, Luc. ^ permalink raw reply [flat|nested] 57+ messages in thread
* Re: Visual cleanup for customize buffers 2006-01-13 0:24 ` Luc Teirlinck @ 2006-01-14 5:48 ` Richard M. Stallman 0 siblings, 0 replies; 57+ messages in thread From: Richard M. Stallman @ 2006-01-14 5:48 UTC (permalink / raw) Cc: emacs-devel, storm Maybe somebody will remember why the empty line was added for variables. I think it was, so that the State line and the documentation string should not appear as a single paragraph. It would be hard to read that way. Maybe whoever did this just forgot to do it for faces. On the other hand, the doc for faces tends to be short, so perhaps the blank line is not needed for faces. ^ permalink raw reply [flat|nested] 57+ messages in thread
* Re: Visual cleanup for customize buffers 2006-01-12 21:58 Visual cleanup for customize buffers Kim F. Storm ` (2 preceding siblings ...) 2006-01-13 0:24 ` Luc Teirlinck @ 2006-01-14 5:49 ` Richard M. Stallman 2006-01-14 15:07 ` Luc Teirlinck ` (3 more replies) 3 siblings, 4 replies; 57+ messages in thread From: Richard M. Stallman @ 2006-01-14 5:49 UTC (permalink / raw) Cc: emacs-devel - Don't show the "Hide value" button for trivial values which fit on one line initially. I don't see ANY reason why a user would click on that button to, say, hide a boolean or numeric value. That seems ok to me, provided the problem Luc is concerned about is not a real problem. - For choice values, replace the old [Value Menu] Value by the more common [Value v] (where v is a "pull down" icon) That could be good if we do the same for State. Do we have a suitable pull-down icon yet? - Remove the empty line between the [STATE] line and the documentation. Please don't do that. ^ permalink raw reply [flat|nested] 57+ messages in thread
* Re: Visual cleanup for customize buffers 2006-01-14 5:49 ` Richard M. Stallman @ 2006-01-14 15:07 ` Luc Teirlinck 2006-01-14 23:05 ` Luc Teirlinck ` (2 subsequent siblings) 3 siblings, 0 replies; 57+ messages in thread From: Luc Teirlinck @ 2006-01-14 15:07 UTC (permalink / raw) Cc: emacs-devel, storm Richard Stallman wrote: - Don't show the "Hide value" button for trivial values which fit on one line initially. I don't see ANY reason why a user would click on that button to, say, hide a boolean or numeric value. That seems ok to me, provided the problem Luc is concerned about is not a real problem. There also is another problem: Kim's change would not allow you to hide anything that is not an atom. That may include large strings or vectors. For instance, you would no longer be able to hide the value of initial-scratch-message. That value hinders navigation in the buffer. For instance, if you do `emacs -q', then `M-x customize-group initialization', and then position point say between Initial and Message in "Initial Scratch Message", then do `C-n', you will see that point gets stuck. Sincerely, Luc. ^ permalink raw reply [flat|nested] 57+ messages in thread
* Re: Visual cleanup for customize buffers 2006-01-14 5:49 ` Richard M. Stallman 2006-01-14 15:07 ` Luc Teirlinck @ 2006-01-14 23:05 ` Luc Teirlinck 2006-01-15 4:40 ` Luc Teirlinck 2006-02-05 0:07 ` Kim F. Storm 2006-01-14 23:27 ` Luc Teirlinck 2006-01-15 4:17 ` Luc Teirlinck 3 siblings, 2 replies; 57+ messages in thread From: Luc Teirlinck @ 2006-01-14 23:05 UTC (permalink / raw) Cc: emacs-devel, storm - Don't show the "Hide value" button for trivial values which fit on one line initially. I don't see ANY reason why a user would click on that button to, say, hide a boolean or numeric value. That seems ok to me, provided the problem Luc is concerned about is not a real problem. Now I have some additional concerns which are definitely real problems. This is not the type of change that should be attempted shortly (one can always hope) before a release and maybe even never. It might look small and harmless at first view but it definitely is not. I installed Kim's two patches. Somehow, after that _all_ options started out hidden. I believe that _must_ be due to the fact that I did something wrong. However, I believe that the following bug is definitely real and not due to some bad application of patches (I guessed this bug would occur from reading the code). Evaluate: (defcustom long-var "1111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111" "Great doc." :group 'help-at-pt :type 'string) Do `M-x customize-group RET help-at-pt'. With or without Kim's patch this option starts out hidden. Without Kim's patch, if I unhide it, I can hide it again, as I clearly should be able to do. With Kim's patch, there is no button to hide it. Kim uses a different criterion for putting in a Show/Hide button than Custom does. This obviously leads to bugs. Even if Kim somehow managed to use exactly the same criteria as Custom does (which seem to be not completely trivial and spread out over the code), we would keep the following two problems (as well as others): 1. The criteria Custom uses are heuristic and occasionally may show very long values that the user _definitely_ may want to hide. 2. There would be the continuous danger of the two conditions getting out of sync at any moment whatsoever, leading to very annoying bugs. Sincerely, Luc. ^ permalink raw reply [flat|nested] 57+ messages in thread
* Re: Visual cleanup for customize buffers 2006-01-14 23:05 ` Luc Teirlinck @ 2006-01-15 4:40 ` Luc Teirlinck 2006-02-05 0:07 ` Kim F. Storm 1 sibling, 0 replies; 57+ messages in thread From: Luc Teirlinck @ 2006-01-15 4:40 UTC (permalink / raw) Cc: storm, rms, emacs-devel >From my previous message: I installed Kim's two patches. Somehow, after that _all_ options started out hidden. I believe that _must_ be due to the fact that I did something wrong. That all options started out hidden must indeed have been the result of me doing something strange. After rechecking, this particular bug did not re-occur. But all the other bugs I mentioned are still there. In addition to help-at-pt-display-when-idle, another example of a very strange looking "new style" [Value v] button can be seen by doing `M-x customize-group initialization' and looking at initial-scratch-message. Sincerely, Luc. ^ permalink raw reply [flat|nested] 57+ messages in thread
* Re: Visual cleanup for customize buffers 2006-01-14 23:05 ` Luc Teirlinck 2006-01-15 4:40 ` Luc Teirlinck @ 2006-02-05 0:07 ` Kim F. Storm 2006-02-06 2:07 ` Richard M. Stallman 2006-02-06 4:30 ` Luc Teirlinck 1 sibling, 2 replies; 57+ messages in thread From: Kim F. Storm @ 2006-02-05 0:07 UTC (permalink / raw) Cc: rms, emacs-devel I have worked a little more on this to address the bugs that Luc reported, as well as the concerns about omitting show/hide buttons. A new patch is included at the end of this mail. I really think that the new look of this is quite good -- much better than the old look IMVHO! It uses a "familiar" icon to indicate a choice field. Please try it out and tell me what you think. Luc Teirlinck <teirllm@dms.auburn.edu> writes: > This is not the type of change that should be attempted shortly (one > can always hope) before a release and maybe even never. It might look > small and harmless at first view but it definitely is not. YMMV, but I think the new patch is quite harmless. > However, I believe that the following bug is definitely real and not > due to some bad application of patches (I guessed this bug would occur > from reading the code). Evaluate: > > (defcustom long-var > "1111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111" > "Great doc." > :group 'help-at-pt > :type 'string) > > Do `M-x customize-group RET help-at-pt'. > > With or without Kim's patch this option starts out hidden. Without > Kim's patch, if I unhide it, I can hide it again, as I clearly should > be able to do. With Kim's patch, there is no button to hide it. I fixed this [trivial]. I also fixed other problems reported by Luc with that page. > > 1. The criteria Custom uses are heuristic and occasionally may show > very long values that the user _definitely_ may want to hide. > > 2. There would be the continuous danger of the two conditions getting > out of sync at any moment whatsoever, leading to very annoying bugs. These concerns a valid, so I added a new custom-reduce-show-hide-buttons option (default nil) for user who want to do this. If this is still controversial, we can omit that part of the patch entirely! Here are the patches: Index: cus-edit.el =================================================================== RCS file: /cvsroot/emacs/emacs/lisp/cus-edit.el,v retrieving revision 1.281 diff -c -r1.281 cus-edit.el *** cus-edit.el 26 Jan 2006 18:00:29 -0000 1.281 --- cus-edit.el 4 Feb 2006 23:57:27 -0000 *************** *** 1422,1427 **** --- 1422,1434 ---- :type 'boolean :group 'custom-buffer) + (defcustom custom-reduce-show-hide-buttons nil + "If non-nil, only display show/hide buttons for complex values. + This also means that you cannot hide non-complex values from actions + initiated by the buttons which operate on the whole customize buffer." + :type 'boolean + :group 'custom-buffer) + (defun Custom-buffer-done (&rest ignore) "Exit current Custom buffer according to `custom-buffer-done-kill'." (interactive) *************** *** 2514,2527 **** tag) buttons) (insert " ") ! (push (widget-create-child-and-convert ! widget 'visibility ! :help-echo "Hide the value of this option." ! :on "Hide Value" ! :off "Show Value" ! :action 'custom-toggle-parent ! t) ! buttons) (push (widget-create-child-and-convert widget type :format value-format --- 2521,2537 ---- tag) buttons) (insert " ") ! (unless (and custom-reduce-show-hide-buttons ! (atom value) ! (custom-show type value)) ! (push (widget-create-child-and-convert ! widget 'visibility ! :help-echo "Hide the value of this option." ! :on "Hide Value" ! :off "Show Value" ! :action 'custom-toggle-parent ! t) ! buttons)) (push (widget-create-child-and-convert widget type :format value-format *************** *** 2541,2547 **** ;; this anyway. The doc string widget should be added like the others. ;; --dv (widget-put widget :buttons buttons) ! (insert "\n") ;; Insert documentation. (widget-default-format-handler widget ?h) --- 2551,2558 ---- ;; this anyway. The doc string widget should be added like the others. ;; --dv (widget-put widget :buttons buttons) ! (unless (eq (preceding-char) ?\n) ! (insert "\n")) ;; Insert documentation. (widget-default-format-handler widget ?h) *************** *** 2876,2882 **** (define-widget 'custom-face-edit 'checklist "Edit face attributes." ! :format "%t: %v" :tag "Attributes" :extra-offset 13 :button-args '(:help-echo "Control whether this attribute has any effect.") --- 2887,2893 ---- (define-widget 'custom-face-edit 'checklist "Edit face attributes." ! :format "%t:\n %v" :tag "Attributes" :extra-offset 13 :button-args '(:help-echo "Control whether this attribute has any effect.") *************** *** 3122,3145 **** (define-widget 'custom-face-selected 'group "Edit the attributes of the selected display in a face specification." ! :args '((choice :inline t (group :tag "With Defaults" :inline t ! (group (const :tag "" default) ! (custom-face-edit :tag " Default\n Attributes")) ! (repeat :format "" ! :inline t ! (group custom-display-unselected sexp)) ! (group (sexp :format "") ! (custom-face-edit :tag " Overriding\n Attributes")) ! (repeat :format "" ! :inline t ! sexp)) ! (group :tag "No Defaults" :inline t (repeat :format "" :inline t (group custom-display-unselected sexp)) (group (sexp :format "") ! (custom-face-edit :tag "\n Attributes")) (repeat :format "" :inline t sexp))))) --- 3133,3156 ---- (define-widget 'custom-face-selected 'group "Edit the attributes of the selected display in a face specification." ! :args '((choice :tag "Attributes" :inline t (group :tag "With Defaults" :inline t ! (group (const :tag "" :format "%t" default) ! (custom-face-edit :tag "With Defaults")) (repeat :format "" :inline t (group custom-display-unselected sexp)) (group (sexp :format "") ! (custom-face-edit :tag "Overriding Attributes")) ! (repeat :format "" ! :inline t ! sexp)) ! (group :tag "No Defaults" :inline t ! (group (sexp :format "") ! (custom-face-edit :tag "No Defaults")) ! (repeat :format "" ! :inline t ! (group custom-display-unselected sexp)) (repeat :format "" :inline t sexp))))) *************** *** 3287,3300 **** (cond ((and (eq form 'selected) (widget-apply custom-face-selected :match spec)) ! (when indent (insert-char ?\ indent)) 'custom-face-selected) ((and (not (eq form 'lisp)) (widget-apply custom-face-all :match spec)) 'custom-face-all) (t ! (when indent (insert-char ?\ indent)) 'sexp)) :value spec)) (custom-face-state-set widget) --- 3298,3312 ---- (cond ((and (eq form 'selected) (widget-apply custom-face-selected :match spec)) ! (when indent (insert-char ?\s indent)) 'custom-face-selected) ((and (not (eq form 'lisp)) (widget-apply custom-face-all :match spec)) + (when indent (insert-char ?\s indent)) 'custom-face-all) (t ! (when indent (insert-char ?\s indent)) 'sexp)) :value spec)) (custom-face-state-set widget) Index: wid-edit.el =================================================================== RCS file: /cvsroot/emacs/emacs/lisp/wid-edit.el,v retrieving revision 1.162 diff -c -r1.162 wid-edit.el *** wid-edit.el 26 Jan 2006 17:59:01 -0000 1.162 --- wid-edit.el 5 Feb 2006 00:05:51 -0000 *************** *** 403,409 **** ;; We want to avoid the face with image buttons. (unless (widget-get widget :suppress-face) (overlay-put overlay 'face (widget-apply widget :button-face-get)) ! (overlay-put overlay 'mouse-face (widget-apply widget :mouse-face-get))) (overlay-put overlay 'pointer 'hand) (overlay-put overlay 'follow-link follow-link) --- 403,409 ---- ;; We want to avoid the face with image buttons. (unless (widget-get widget :suppress-face) (overlay-put overlay 'face (widget-apply widget :button-face-get)) ! (overlay-put overlay 'mouse-face (widget-apply widget :mouse-face-get))) (overlay-put overlay 'pointer 'hand) (overlay-put overlay 'follow-link follow-link) *************** *** 1421,1426 **** --- 1421,1428 ---- (call-interactively (or (widget-get widget :complete-function) widget-complete-field))) + (defvar widget-choice-menu-image nil) + (defun widget-default-create (widget) "Create WIDGET at point in the current buffer." (widget-specify-insert *************** *** 1428,1434 **** button-begin button-end sample-begin sample-end doc-begin doc-end ! value-pos) (insert (widget-get widget :format)) (goto-char from) ;; Parse escapes in format. --- 1430,1436 ---- button-begin button-end sample-begin sample-end doc-begin doc-end ! value-pos value-choice-button) (insert (widget-get widget :format)) (goto-char from) ;; Parse escapes in format. *************** *** 1441,1448 **** (setq button-begin (point)) (insert (widget-get-indirect widget :button-prefix))) ((eq escape ?\]) ! (insert (widget-get-indirect widget :button-suffix)) ! (setq button-end (point))) ((eq escape ?\{) (setq sample-begin (point))) ((eq escape ?\}) --- 1443,1476 ---- (setq button-begin (point)) (insert (widget-get-indirect widget :button-prefix))) ((eq escape ?\]) ! (save-excursion ! (setq button-end (point)) ! (when value-choice-button ! (goto-char button-begin) ! (when (re-search-forward "[:\n]" button-end t) ! (setq button-end (1- (point)))) ! (goto-char button-end) ! (when (eq (preceding-char) ?\n) ! (backward-char 1)) ! (insert " ") ! (if (display-graphic-p) ! (insert-image ! (or widget-choice-menu-image ! (setq widget-choice-menu-image ! (create-image "\377\176\176\074\074\030\030\377" ! 'xbm t :width 8 :height 8 ! :foreground ! (if (facep 'custom-button) ! (face-foreground 'custom-button) ! "black") ! :background ! (if (facep 'custom-button) ! (face-background 'custom-button) ! "lightgrey") ! :ascent 'center))) ">") ! (insert (propertize "?>" ))) ! (setq button-end (point))) ! (insert (widget-get-indirect widget :button-suffix)))) ((eq escape ?\{) (setq sample-begin (point))) ((eq escape ?\}) *************** *** 1474,1479 **** --- 1502,1510 ---- (if (and button-begin (not button-end)) (widget-apply widget :value-create) (setq value-pos (point)))) + ((eq escape ?V) + (widget-apply widget :value-create) + (setq value-choice-button t)) (t (widget-apply widget :format-handler escape))))) ;; Specify button, sample, and doc, and insert value. *************** *** 3565,3571 **** (define-widget 'choice 'menu-choice "A union of several sexp types." :tag "Choice" ! :format "%{%t%}: %[Value Menu%] %v" :button-prefix 'widget-push-button-prefix :button-suffix 'widget-push-button-suffix :prompt-value 'widget-choice-prompt-value) --- 3596,3602 ---- (define-widget 'choice 'menu-choice "A union of several sexp types." :tag "Choice" ! :format "%{%t%}: %[%V%]" :button-prefix 'widget-push-button-prefix :button-suffix 'widget-push-button-suffix :prompt-value 'widget-choice-prompt-value) *************** *** 3634,3640 **** :prompt-value 'widget-boolean-prompt-value :button-prefix 'widget-push-button-prefix :button-suffix 'widget-push-button-suffix ! :format "%{%t%}: %[Toggle%] %v\n" :on "on (non-nil)" :off "off (nil)") --- 3665,3671 ---- :prompt-value 'widget-boolean-prompt-value :button-prefix 'widget-push-button-prefix :button-suffix 'widget-push-button-suffix ! :format "%{%t%}: %v %[Toggle%]\n" :on "on (non-nil)" :off "off (nil)") -- Kim F. Storm <storm@cua.dk> http://www.cua.dk ^ permalink raw reply [flat|nested] 57+ messages in thread
* Re: Visual cleanup for customize buffers 2006-02-05 0:07 ` Kim F. Storm @ 2006-02-06 2:07 ` Richard M. Stallman 2006-02-06 4:30 ` Luc Teirlinck 1 sibling, 0 replies; 57+ messages in thread From: Richard M. Stallman @ 2006-02-06 2:07 UTC (permalink / raw) Cc: teirllm, emacs-devel --- 2551,2558 ---- ;; this anyway. The doc string widget should be added like the others. ;; --dv (widget-put widget :buttons buttons) ! (unless (eq (preceding-char) ?\n) ! (insert "\n")) ;; Insert documentation. (widget-default-format-handler widget ?h) If this deletes the blank line after the STATE line, I am against it, for reasons I stated here before. (define-widget 'custom-face-edit 'checklist "Edit face attributes." ! :format "%t:\n %v" :tag "Attributes" :extra-offset 13 :button-args '(:help-echo "Control whether this attribute has any effect.") What is the user-visible effect of that? ((eq escape ?\]) ! (save-excursion ! (setq button-end (point)) ! (when value-choice-button ! (goto-char button-begin) ! (when (re-search-forward "[:\n]" button-end t) ! (setq button-end (1- (point)))) ! (goto-char button-end) ! (when (eq (preceding-char) ?\n) ! (backward-char 1)) ! (insert " ") ! (if (display-graphic-p) ! (insert-image ! (or widget-choice-menu-image ! (setq widget-choice-menu-image ! (create-image "\377\176\176\074\074\030\030\377" ! 'xbm t :width 8 :height 8 ! :foreground ! (if (facep 'custom-button) ! (face-foreground 'custom-button) ! "black") ! :background ! (if (facep 'custom-button) ! (face-background 'custom-button) ! "lightgrey") ! :ascent 'center))) ">") ! (insert (propertize "?>" ))) ! (setq button-end (point))) ! (insert (widget-get-indirect widget :button-suffix)))) ((eq escape ?\{) (setq sample-begin (point))) ((eq escape ?\}) What does that do? (It needs comments!) --- 3596,3602 ---- (define-widget 'choice 'menu-choice "A union of several sexp types." :tag "Choice" ! :format "%{%t%}: %[%V%]" :button-prefix 'widget-push-button-prefix :button-suffix 'widget-push-button-suffix :prompt-value 'widget-choice-prompt-value) What user-visible change does that make? ^ permalink raw reply [flat|nested] 57+ messages in thread
* Re: Visual cleanup for customize buffers 2006-02-05 0:07 ` Kim F. Storm 2006-02-06 2:07 ` Richard M. Stallman @ 2006-02-06 4:30 ` Luc Teirlinck 2006-02-06 7:21 ` Eli Zaretskii 1 sibling, 1 reply; 57+ messages in thread From: Luc Teirlinck @ 2006-02-06 4:30 UTC (permalink / raw) Cc: rms, emacs-devel Kim Storm wrote: I have worked a little more on this to address the bugs that Luc reported, Your patch addresses only _some manifestations_ of the bugs. You did not even fix all examples that I reported. For instance, a manifestation of the bug that is still present is that the "Value Menu" for initial-scratch-message says: ";; This buffer is for notes you don't want to save, and for Lisp evaluation." whereas it should be saying: "Message". I already reported this while discussing your earlier patch. Your "Value Menu" for initial-scratch-message is _also_ part of the _value_ and hence can be edited and is _meant_ to be edited. If you do C-k at the beginning of it, the value menu is _gone_. It is a complete mess. YMMV, but I think the new patch is quite harmless. This has nothing to do with varying mileage. You said this once before about your earlier patch and you were very wrong. Now you say it a second time and you are very wrong again. I would *very much* appreciate if you could wait till after the release before submitting any more "quite harmless" patches on this. Right now, one should concentrate on fixing existing bugs. I know that there are problems with the "feature freeze", but this is no reason to make a complete mockery out of it. There are still many known bugs related to Custom that need to be fixed. Each time somebody tries to implement a new feature in Custom, like you are trying to implement, or starts yet another discussion about Custom that could wait till after the release, people have to spend time finding the bugs in these new features and reporting them and participating in long discussions. As a result, numerous bugs related to Custom that could otherwise have fixed during all that time will now find their way into the release. Sincerely, Luc. ^ permalink raw reply [flat|nested] 57+ messages in thread
* Re: Visual cleanup for customize buffers 2006-02-06 4:30 ` Luc Teirlinck @ 2006-02-06 7:21 ` Eli Zaretskii 2006-02-06 17:35 ` Luc Teirlinck 0 siblings, 1 reply; 57+ messages in thread From: Eli Zaretskii @ 2006-02-06 7:21 UTC (permalink / raw) Cc: emacs-devel, rms, storm > Date: Sun, 5 Feb 2006 22:30:11 -0600 (CST) > From: Luc Teirlinck <teirllm@dms.auburn.edu> > Cc: rms@gnu.org, emacs-devel@gnu.org > > Kim Storm wrote: > > I have worked a little more on this to address the bugs that Luc > reported, > > Your patch addresses only _some manifestations_ of the bugs. You did > not even fix all examples that I reported. For instance, a > manifestation of the bug that is still present is that the "Value Menu" > for initial-scratch-message says: Is this some new way of saying thank you? ^ permalink raw reply [flat|nested] 57+ messages in thread
* Re: Visual cleanup for customize buffers 2006-02-06 7:21 ` Eli Zaretskii @ 2006-02-06 17:35 ` Luc Teirlinck 0 siblings, 0 replies; 57+ messages in thread From: Luc Teirlinck @ 2006-02-06 17:35 UTC (permalink / raw) Cc: emacs-devel, rms, storm Eli Zaretskii wrote: > Date: Sun, 5 Feb 2006 22:30:11 -0600 (CST) > From: Luc Teirlinck <teirllm@dms.auburn.edu> > Cc: rms@gnu.org, emacs-devel@gnu.org > > Kim Storm wrote: > > I have worked a little more on this to address the bugs that Luc > reported, > > Your patch addresses only _some manifestations_ of the bugs. You did > not even fix all examples that I reported. For instance, a > manifestation of the bug that is still present is that the "Value Menu" > for initial-scratch-message says: Is this some new way of saying thank you? It is a way of repeating what I said before: this should not be messed with before the release. I was talking about bugs in a _new feature_. Right now, I should not have to test various new features and report bugs on them. Supposedly, we are in a feature freeze. Sincerely, Luc. ^ permalink raw reply [flat|nested] 57+ messages in thread
* Re: Visual cleanup for customize buffers 2006-01-14 5:49 ` Richard M. Stallman 2006-01-14 15:07 ` Luc Teirlinck 2006-01-14 23:05 ` Luc Teirlinck @ 2006-01-14 23:27 ` Luc Teirlinck 2006-01-14 23:45 ` Drew Adams 2006-01-15 18:59 ` Kim F. Storm 2006-01-15 4:17 ` Luc Teirlinck 3 siblings, 2 replies; 57+ messages in thread From: Luc Teirlinck @ 2006-01-14 23:27 UTC (permalink / raw) Cc: emacs-devel, storm Richard Stallman wrote: - For choice values, replace the old [Value Menu] Value by the more common [Value v] (where v is a "pull down" icon) That could be good if we do the same for State. Do we have a suitable pull-down icon yet? Please, unless I somehow misapplied these patches, let us not install this. The [Value Menu] button does apparently not get replaced by a [Value v] button, but by "strange stuff". We had already to do `M-x customize-group help-at-pt', to look at the previous problem I reported. After clicking "Show value' on help-at-pt-display-when-idle we get: help-at-pt-display-when-idle: Never This choice normally disables buffer local values. More v The entire text between Never and v, that is value _and_ first line of doc, are the _button text_ that replaces [Value Menu]. You can correct the situation by clicking on [More] (although it gets rid of the v), but still. Did I somehow misinstall these patches? If not, let us just put off making these unnecessary "limited" changes to Custom till after the release. Prior to the release, we should fix existing bugs in Custom rather than risk introducing new ones. Custom is much more complex than people believe. There are always more situations and much more complex situations to take into account than people usually do think of. Sincerely, Luc. ^ permalink raw reply [flat|nested] 57+ messages in thread
* RE: Visual cleanup for customize buffers 2006-01-14 23:27 ` Luc Teirlinck @ 2006-01-14 23:45 ` Drew Adams 2006-01-15 18:59 ` Kim F. Storm 1 sibling, 0 replies; 57+ messages in thread From: Drew Adams @ 2006-01-14 23:45 UTC (permalink / raw) Custom is much more complex than people believe. There are always more situations and much more complex situations to take into account than people usually do think of. How about this as a motto for Custom: "Custom is much more complex than you believe, even if you believe that Custom is much more complex than you believe." Anyway, I second the idea of not changing too much (if anything) in Custom before the release. There is (IMO) so much about Custom to rework after the release; I don't see much point in trying to improve it before the release. And I believe Luc when he suggests that it's easy for seemingly minor tweaks to wreak havoc or to have silent but nasty effects. Custom is far from transparent and understandable, but it seems to be telling us this clearly: "Leave well enough alone, for now." ^ permalink raw reply [flat|nested] 57+ messages in thread
* Re: Visual cleanup for customize buffers 2006-01-14 23:27 ` Luc Teirlinck 2006-01-14 23:45 ` Drew Adams @ 2006-01-15 18:59 ` Kim F. Storm 1 sibling, 0 replies; 57+ messages in thread From: Kim F. Storm @ 2006-01-15 18:59 UTC (permalink / raw) Cc: rms, emacs-devel Luc Teirlinck <teirllm@dms.auburn.edu> writes: > Did I somehow misinstall these patches? I see the same problem ... > If not, let us just put off > making these unnecessary "limited" changes to Custom till after the > release. Prior to the release, we should fix existing bugs in Custom > rather than risk introducing new ones. I guess it depends on what you consider are bugs... > Custom is much more complex than people believe. There are always > more situations and much more complex situations to take into account > than people usually do think of. Too bad! -- Kim F. Storm <storm@cua.dk> http://www.cua.dk ^ permalink raw reply [flat|nested] 57+ messages in thread
* Re: Visual cleanup for customize buffers 2006-01-14 5:49 ` Richard M. Stallman ` (2 preceding siblings ...) 2006-01-14 23:27 ` Luc Teirlinck @ 2006-01-15 4:17 ` Luc Teirlinck 2006-01-15 23:08 ` Richard M. Stallman 3 siblings, 1 reply; 57+ messages in thread From: Luc Teirlinck @ 2006-01-15 4:17 UTC (permalink / raw) Cc: emacs-devel, storm >From my previous reply: I installed Kim's two patches. That was formulated in a confusing way. I meant that I privately applied them. I did _not_ mean that I installed them in Emacs CVS. For reasons explained in my prior messages, I do not recommend installing them in Emacs CVS. Sincerely, Luc. ^ permalink raw reply [flat|nested] 57+ messages in thread
* Re: Visual cleanup for customize buffers 2006-01-15 4:17 ` Luc Teirlinck @ 2006-01-15 23:08 ` Richard M. Stallman 0 siblings, 0 replies; 57+ messages in thread From: Richard M. Stallman @ 2006-01-15 23:08 UTC (permalink / raw) Cc: storm, emacs-devel That was formulated in a confusing way. I meant that I privately applied them. I did _not_ mean that I installed them in Emacs CVS. Thanks for the clarification. It is better to say "I am testing Kim's patches". ^ permalink raw reply [flat|nested] 57+ messages in thread
end of thread, other threads:[~2006-02-06 17:35 UTC | newest] Thread overview: 57+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2006-01-12 21:58 Visual cleanup for customize buffers Kim F. Storm 2006-01-12 23:45 ` Luc Teirlinck 2006-01-13 12:37 ` Kim F. Storm 2006-01-13 14:18 ` Luc Teirlinck 2006-01-13 15:16 ` Kim F. Storm 2006-01-13 19:05 ` Drew Adams 2006-01-13 19:16 ` David Kastrup 2006-01-13 23:28 ` Luc Teirlinck 2006-01-13 23:34 ` Luc Teirlinck 2006-01-14 16:14 ` Richard M. Stallman 2006-01-14 0:08 ` Luc Teirlinck 2006-01-14 0:44 ` Luc Teirlinck 2006-01-14 1:56 ` Kim F. Storm 2006-01-14 2:58 ` Chong Yidong 2006-01-14 6:10 ` Drew Adams 2006-01-14 16:14 ` Richard M. Stallman 2006-01-14 16:14 ` Richard M. Stallman 2006-01-14 20:50 ` Lennart Borgman 2006-01-14 21:32 ` Luc Teirlinck 2006-01-14 21:47 ` Lennart Borgman 2006-01-15 18:09 ` Luc Teirlinck 2006-01-15 18:41 ` Kim F. Storm 2006-01-15 19:59 ` Luc Teirlinck 2006-01-14 21:58 ` Drew Adams 2006-01-14 22:17 ` Drew Adams 2006-01-15 1:40 ` Luc Teirlinck 2006-01-15 23:08 ` Richard M. Stallman 2006-01-16 4:19 ` Luc Teirlinck 2006-01-19 17:44 ` Richard M. Stallman 2006-01-17 4:20 ` Luc Teirlinck 2006-01-17 20:00 ` Richard M. Stallman 2006-01-20 0:18 ` Luc Teirlinck 2006-01-13 16:40 ` Stefan Monnier 2006-01-13 19:04 ` Bill Wohler 2006-01-14 1:28 ` Luc Teirlinck 2006-01-14 1:46 ` Bill Wohler 2006-01-14 5:49 ` Richard M. Stallman 2006-01-14 15:28 ` Luc Teirlinck 2006-01-13 0:08 ` Luc Teirlinck 2006-01-13 15:24 ` Kim F. Storm 2006-01-13 19:33 ` martin rudalics 2006-01-13 0:24 ` Luc Teirlinck 2006-01-14 5:48 ` Richard M. Stallman 2006-01-14 5:49 ` Richard M. Stallman 2006-01-14 15:07 ` Luc Teirlinck 2006-01-14 23:05 ` Luc Teirlinck 2006-01-15 4:40 ` Luc Teirlinck 2006-02-05 0:07 ` Kim F. Storm 2006-02-06 2:07 ` Richard M. Stallman 2006-02-06 4:30 ` Luc Teirlinck 2006-02-06 7:21 ` Eli Zaretskii 2006-02-06 17:35 ` Luc Teirlinck 2006-01-14 23:27 ` Luc Teirlinck 2006-01-14 23:45 ` Drew Adams 2006-01-15 18:59 ` Kim F. Storm 2006-01-15 4:17 ` Luc Teirlinck 2006-01-15 23:08 ` Richard M. Stallman
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.