emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: Visual cleanup for customize buffers


From: Drew Adams
Subject: RE: Visual cleanup for customize buffers
Date: Sat, 14 Jan 2006 13:58:05 -0800

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





reply via email to

[Prev in Thread] Current Thread [Next in Thread]