unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: storm@cua.dk (Kim F. Storm)
Cc: emacs-devel@gnu.org
Subject: Re: Visual cleanup for customize buffers
Date: Sat, 14 Jan 2006 02:56:19 +0100	[thread overview]
Message-ID: <m3bqyf4loc.fsf@kfs-l.imdomain.dk> (raw)
In-Reply-To: <200601140044.k0E0iaF07171@raven.dms.auburn.edu> (Luc Teirlinck's message of "Fri, 13 Jan 2006 18:44:36 -0600 (CST)")

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

  reply	other threads:[~2006-01-14  1:56 UTC|newest]

Thread overview: 57+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-01-12 21:58 Visual cleanup for customize buffers Kim F. Storm
2006-01-12 23:45 ` Luc Teirlinck
2006-01-13 12:37   ` Kim F. Storm
2006-01-13 14:18     ` Luc Teirlinck
2006-01-13 15:16       ` Kim F. Storm
2006-01-13 19:05         ` Drew Adams
2006-01-13 19:16         ` David Kastrup
2006-01-13 23:28         ` Luc Teirlinck
2006-01-13 23:34           ` Luc Teirlinck
2006-01-14 16:14           ` Richard M. Stallman
2006-01-14  0:08         ` Luc Teirlinck
2006-01-14  0:44         ` Luc Teirlinck
2006-01-14  1:56           ` Kim F. Storm [this message]
2006-01-14  2:58             ` Chong Yidong
2006-01-14  6:10             ` Drew Adams
2006-01-14 16:14           ` Richard M. Stallman
2006-01-14 16:14         ` Richard M. Stallman
2006-01-14 20:50           ` Lennart Borgman
2006-01-14 21:32             ` Luc Teirlinck
2006-01-14 21:47               ` Lennart Borgman
2006-01-15 18:09                 ` Luc Teirlinck
2006-01-15 18:41                 ` Kim F. Storm
2006-01-15 19:59                   ` Luc Teirlinck
2006-01-14 21:58           ` Drew Adams
2006-01-14 22:17             ` Drew Adams
2006-01-15  1:40           ` Luc Teirlinck
2006-01-15 23:08             ` Richard M. Stallman
2006-01-16  4:19               ` Luc Teirlinck
2006-01-19 17:44                 ` Richard M. Stallman
2006-01-17  4:20               ` Luc Teirlinck
2006-01-17 20:00                 ` Richard M. Stallman
2006-01-20  0:18                   ` Luc Teirlinck
2006-01-13 16:40     ` Stefan Monnier
2006-01-13 19:04   ` Bill Wohler
2006-01-14  1:28     ` Luc Teirlinck
2006-01-14  1:46       ` Bill Wohler
2006-01-14  5:49   ` Richard M. Stallman
2006-01-14 15:28     ` Luc Teirlinck
2006-01-13  0:08 ` Luc Teirlinck
2006-01-13 15:24   ` Kim F. Storm
2006-01-13 19:33     ` martin rudalics
2006-01-13  0:24 ` Luc Teirlinck
2006-01-14  5:48   ` Richard M. Stallman
2006-01-14  5:49 ` Richard M. Stallman
2006-01-14 15:07   ` Luc Teirlinck
2006-01-14 23:05   ` Luc Teirlinck
2006-01-15  4:40     ` Luc Teirlinck
2006-02-05  0:07     ` Kim F. Storm
2006-02-06  2:07       ` Richard M. Stallman
2006-02-06  4:30       ` Luc Teirlinck
2006-02-06  7:21         ` Eli Zaretskii
2006-02-06 17:35           ` Luc Teirlinck
2006-01-14 23:27   ` Luc Teirlinck
2006-01-14 23:45     ` Drew Adams
2006-01-15 18:59     ` Kim F. Storm
2006-01-15  4:17   ` Luc Teirlinck
2006-01-15 23:08     ` Richard M. Stallman

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=m3bqyf4loc.fsf@kfs-l.imdomain.dk \
    --to=storm@cua.dk \
    --cc=emacs-devel@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).