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.