[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Visual cleanup for customize buffers
From: |
Kim F. Storm |
Subject: |
Re: Visual cleanup for customize buffers |
Date: |
Sat, 14 Jan 2006 02:56:19 +0100 |
User-agent: |
Gnus/5.11 (Gnus v5.11) Emacs/22.0.50 (gnu/linux) |
Luc Teirlinck <address@hidden> 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 <address@hidden> http://www.cua.dk
- Re: Visual cleanup for customize buffers, (continued)
- Re: Visual cleanup for customize buffers, Kim F. Storm, 2006/01/13
- Re: Visual cleanup for customize buffers, Luc Teirlinck, 2006/01/13
- Re: Visual cleanup for customize buffers, Kim F. Storm, 2006/01/13
- RE: Visual cleanup for customize buffers, Drew Adams, 2006/01/13
- Re: Visual cleanup for customize buffers, David Kastrup, 2006/01/13
- Re: Visual cleanup for customize buffers, Luc Teirlinck, 2006/01/13
- Re: Visual cleanup for customize buffers, Luc Teirlinck, 2006/01/13
- Re: Visual cleanup for customize buffers, Richard M. Stallman, 2006/01/14
- Re: Visual cleanup for customize buffers, Luc Teirlinck, 2006/01/13
- Re: Visual cleanup for customize buffers, Luc Teirlinck, 2006/01/13
- Re: Visual cleanup for customize buffers,
Kim F. Storm <=
- Re: Visual cleanup for customize buffers, Chong Yidong, 2006/01/13
- RE: Visual cleanup for customize buffers, Drew Adams, 2006/01/14
- Re: Visual cleanup for customize buffers, Richard M. Stallman, 2006/01/14
- Re: Visual cleanup for customize buffers, Richard M. Stallman, 2006/01/14
- Re: Visual cleanup for customize buffers, Lennart Borgman, 2006/01/14
- Re: Visual cleanup for customize buffers, Luc Teirlinck, 2006/01/14
- Re: Visual cleanup for customize buffers, Lennart Borgman, 2006/01/14
- Re: Visual cleanup for customize buffers, Luc Teirlinck, 2006/01/15
- Re: Visual cleanup for customize buffers, Kim F. Storm, 2006/01/15
- Re: Visual cleanup for customize buffers, Luc Teirlinck, 2006/01/15