Re: Visual cleanup for customize buffers

[Kim F. Storm]

Luc Teirlinck <address@hidden> 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 <address@hidden> http://www.cua.dk