Visual cleanup for customize buffers

Visual cleanup for customize buffers

[Kim F. Storm]

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

Re: Visual cleanup for customize buffers

[Luc Teirlinck]

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.

Re: Visual cleanup for customize buffers

[Kim F. Storm]

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

Re: Visual cleanup for customize buffers

[Luc Teirlinck]

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.

Re: Visual cleanup for customize buffers

[Kim F. Storm]

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

RE: Visual cleanup for customize buffers

[Drew Adams]

    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.

Re: Visual cleanup for customize buffers

[David Kastrup]

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

Re: Visual cleanup for customize buffers

[Luc Teirlinck]

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.

Re: Visual cleanup for customize buffers

[Luc Teirlinck]

>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.

Re: Visual cleanup for customize buffers

[Richard M. Stallman]

	 * 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.

Re: Visual cleanup for customize buffers

[Luc Teirlinck]

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.

Re: Visual cleanup for customize buffers

[Luc Teirlinck]

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.

Re: Visual cleanup for customize buffers

[Kim F. Storm]

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

Re: Visual cleanup for customize buffers

[Chong Yidong]

> 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.

RE: Visual cleanup for customize buffers

[Drew Adams]

    > 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.

Re: Visual cleanup for customize buffers

[Richard M. Stallman]

We are not going to eliminate the individual State buttons.

Re: Visual cleanup for customize buffers

[Richard M. Stallman]

      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.

Re: Visual cleanup for customize buffers

[Lennart Borgman]

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.

Re: Visual cleanup for customize buffers

[Luc Teirlinck]

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.

Re: Visual cleanup for customize buffers

[Lennart Borgman]

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.

Re: Visual cleanup for customize buffers

[Luc Teirlinck]

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.

Re: Visual cleanup for customize buffers

[Kim F. Storm]

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

Re: Visual cleanup for customize buffers

[Luc Teirlinck]

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.

RE: Visual cleanup for customize buffers

[Drew Adams]

        - 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.

RE: Visual cleanup for customize buffers

[Drew Adams]

    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.

Re: Visual cleanup for customize buffers

[Luc Teirlinck]

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.

Re: Visual cleanup for customize buffers

[Richard M. Stallman]

    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.

Re: Visual cleanup for customize buffers

[Luc Teirlinck]

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.

Re: Visual cleanup for customize buffers

[Richard M. Stallman]

       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.

Re: Visual cleanup for customize buffers

[Luc Teirlinck]

   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.

Re: Visual cleanup for customize buffers

[Richard M. Stallman]

	   Operate on all settings in this buffer that aren't marked HIDDEN.

    That sounds OK.

Would you please put that in?

Re: Visual cleanup for customize buffers

[Luc Teirlinck]

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.

Re: Visual cleanup for customize buffers

[Stefan Monnier]

> 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

Re: Visual cleanup for customize buffers

[Bill Wohler]

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.

Re: Visual cleanup for customize buffers

[Luc Teirlinck]

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.

Re: Visual cleanup for customize buffers

[Bill Wohler]

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.

Re: Visual cleanup for customize buffers

[Richard M. Stallman]

    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.

Re: Visual cleanup for customize buffers

[Luc Teirlinck]

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.

Re: Visual cleanup for customize buffers

[Luc Teirlinck]

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.

Re: Visual cleanup for customize buffers

[Kim F. Storm]

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

Re: Visual cleanup for customize buffers

[martin rudalics]

 > - 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.

Re: Visual cleanup for customize buffers

[Luc Teirlinck]

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.

Re: Visual cleanup for customize buffers

[Richard M. Stallman]

    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.

Re: Visual cleanup for customize buffers

[Richard M. Stallman]

    - 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.

Re: Visual cleanup for customize buffers

[Luc Teirlinck]

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.

Re: Visual cleanup for customize buffers

[Luc Teirlinck]

       - 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.

Re: Visual cleanup for customize buffers

[Luc Teirlinck]

>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.

Re: Visual cleanup for customize buffers

[Kim F. Storm]

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

Re: Visual cleanup for customize buffers

[Richard M. Stallman]

    --- 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?

Re: Visual cleanup for customize buffers

[Luc Teirlinck]

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.

Re: Visual cleanup for customize buffers

[Eli Zaretskii]

> 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?

Re: Visual cleanup for customize buffers

[Luc Teirlinck]

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.

Re: Visual cleanup for customize buffers

[Luc Teirlinck]

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.

RE: Visual cleanup for customize buffers

[Drew Adams]

    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."

Re: Visual cleanup for customize buffers

[Kim F. Storm]

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

Re: Visual cleanup for customize buffers

[Luc Teirlinck]

>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.

Re: Visual cleanup for customize buffers

[Richard M. Stallman]

    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".