Maybe the "Customize" menu could have a simple check-box option for
"Show per-option action buttons". The inquisitive emacs user will
surely find it :-)
I agree that if a user enabled this, the global buttons should not
be shown.
This is a compromise that gives both approache
Look, I am not participating in this discussion because it is not
relevant for Emacs-22.1. We have spent enough time on it already.
I have _tried_ to tell that a couple of times much earlier in the
discussion. But at a given moment, I felt that I _had_ to
participate, because it looked lik
[EMAIL PROTECTED] (Kim F. Storm) writes:
> Luc Teirlinck <[EMAIL PROTECTED]> writes:
[Buttons, buttons, buttons]
Look, I am not participating in this discussion because it is not
relevant for Emacs-22.1. We have spent enough time on it already.
The right way of resolving it will be to check in
Luc Teirlinck <[EMAIL PROTECTED]> writes:
> People can put in these Gnome style whole buffer buttons that Kim
> proposed. That is OK, I do not care.
>
> But _why_ on earth does anybody want to _hide_ that small State button,
> that barely takes any space? How can this _confuse_ people?
Becaus
>From my previous message:
They will very quickly become experts, not only at using Custom,
but at using Emacs.
To avoid having this interpreted in a silly way: I meant that they
will quickly become experts because they are inquisitive and willing
to try out things. (_Obviously_ not just b
People can put in these Gnome style whole buffer buttons that Kim
proposed. That is OK, I do not care.
But _why_ on earth does anybody want to _hide_ that small State button,
that barely takes any space? How can this _confuse_ people? There is
a help echo saying "Change the state of this item".
- Original Message -
From: "Richard Stallman" <[EMAIL PROTECTED]>
To: "Kim F. Storm" <[EMAIL PROTECTED]>
> My claim is that he is familiar with an interface where a page has:
>
> - N different options (N > 1)
>
> - an "Apply" button which saves and activates the changes,
>
Kim Storm wrote:
I think I have understood your idea of "typical usage pattern",
I do not believe so. I use Custom extensively as a _browser_ and
_documentation tool_, but when I see an option I want to change and
save, I do so. In my use of Custom as a browser and source of info, I
often cl
Luc Teirlinck <[EMAIL PROTECTED]> writes:
> Currently, getting 22 released seems more urgent.
I agree 100% with _that_ :-)
--
Kim F. Storm <[EMAIL PROTECTED]> http://www.cua.dk
___
Emacs-devel mailing list
Emacs-devel@gnu.org
http://lists.gnu.org/m
Luc Teirlinck <[EMAIL PROTECTED]> writes:
> You completely misunderstand again.
I think I have understood your idea of "typical usage pattern",
I just disagree that it is "typical".
> I am talking about just _looking_
> at items in a "Value Menu", not about
My claim is that he is familiar with an interface where a page has:
- N different options (N > 1)
- an "Apply" button which saves and activates the changes,
but keep the page open.
- an "Ok", "Save" or "Finish" button which saves and activates the
changes, and c
When you
click on a choice of the Value Menu, the default value _for that choice_
appears in the widget and a separate docstring for that choice may
appear, which you may want to read. You may _only_ have clicked on
that choice for information purposes.
Regardless of your mo
Richard Stallman wrote:
This means rejecting the goal that it should be able to do
"whatever the user might want to do".
I was only talking about a user who wanted to look at the choices he
had in a Value Menu (and maybe read their docstrings), did not want to
save or set anything, and forg
Why don't we simply introduce a "customize-expert" option that is off
by default, but can be turned on when the user gains more experience.
It might be a good idea, if this allows us to disconnect the goals for
convenience for experts from the goals for simplicity for beginners.
But the problem is exactly that he may _not_ be satisfied with all the
current "settings" (widget values). He may just have wanted to set
them, or even more likely, just has been looking at them.
The arguments you are making are arguments for complexity. That is
the wrong approach fo
I give a summary of my proposal to meet some of the objections
leveled against Customize. I personally _only_ have problems with
the whole buffer buttons, but I have tried to take other people's
objections into account (which I understood to be that that the State
button implementation is too unin
The button I called RESET TO SAVED in my previous message could also
be called: UNDO EDITS.
Sincerely,
Luc.
___
Emacs-devel mailing list
Emacs-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-devel
I lost the CC's im my original reply to Lennart:
Lennart Borgman wrote:
I agree with your points, but is not this the case with most options
dialoges? I myself have often found that I have lost track of what I am
doing in those dialoges in other applications. To be sure to avoid trouble
>From my previous message:
You completely misunderstand again. I am talking about just _looking_
at items in a "Value Menu", not about setting anything.
Well actually I said:
He may just have wanted to set them, or even more likely, just has
been looking at them.
So I did talk abou
- Original Message -
From: "Luc Teirlinck" <[EMAIL PROTECTED]>
> So I did talk about "setting" _in addition_ to looking at the choices,
> without setting anything. But the point remains that just looking at
> the possible choices for an option, without setting anything, poses a
> danger
Kim Storm wrote:
The confusion arises when you have the option to "set but not save"
some options, and later on you do "save" -- that will save all options
including those you only "set".
No, you completely misunderstand. Getting rid of the Save-Set
distinction would _in no way whatsoev
Luc Teirlinck <[EMAIL PROTECTED]> writes:
> Kim Storm wrote:
I wrote, you wrote, Lennart wrote, RMS wrote, bla bla bla :-)
Seriously, we seem to _completely_ disagree what an ordinary (novice) user
would expect from a customization interface.
My claim is that he is familiar with an interface wh
Kim Storm wrote:
IMHO, this is _expert_ behaviour.
I think that most novice users will very rarely mix and match setting
some options and saving others.
Rarely, but sometimes. Why confuse them badly if they do? Moreover,
it is not just setting and saving. It is also about looking at
What is the reason that we must choose and not have both local and global
actions? Is it to simplify the UI?
I am considering the idea of eliminating one of them in order to
simplify the interface. It seems to be far too complex now.
___
Emac
- Original Message -
From: "Kim F. Storm" <[EMAIL PROTECTED]>
> Why don't we simply introduce a "customize-expert" option that is off
> by default, but can be turned on when the user gains more experience.
>
> When off, it can limit the features of the customize interface to
> those featu
Luc Teirlinck <[EMAIL PROTECTED]> writes:
> Kim Storm wrote:
>
>Both of us seem to primarily customize one option at a time --
>so it's mostly a matter of how far you have to move the mouse
>to active that changes...
>
> We all seem to usually set one option at a time. There is no nee
Kim Storm wrote:
Both of us seem to primarily customize one option at a time --
so it's mostly a matter of how far you have to move the mouse
to active that changes...
We all seem to usually set one option at a time. There is no need in
that case to have to worry about thirty other opti
- Original Message -
From: "Kim F. Storm" <[EMAIL PROTECTED]>
> > But of course, you cannot activate it with your mouse.
> >
> > We could make the header line mouse-sensitive, as in Info.
> >
>
> That was the intention -- I meant "keyboard" not "mouse".
Hm. I never noticed this befor
"Drew Adams" <[EMAIL PROTECTED]> writes:
>
> But of course, you cannot activate it with your mouse.
>
> We could make the header line mouse-sensitive, as in Info.
>
That was the intention -- I meant "keyboard" not "mouse".
--
Kim F. Storm <[EMAIL PROTECTED]> http://www.cua.dk
___
[EMAIL PROTECTED] (Kim F. Storm) writes:
> "Lennart Borgman" <[EMAIL PROTECTED]> writes:
>
>>
>>> A simpler interface with a "one line" button bar (prefeably in
>>> the header line when supported) like this
>>>
>>> [Set] [Save] [Load] [Finish]
>>>
>>> would be ideal IMO.
>>
>> Most other ap
The reason the header line is nice is that it will remain on
the screen even when you scroll the customize window.
Yes. Of course, the same operations are also available in the menu-bar
menu, which stays put like a header line.
But of course, you cannot activate it with your mouse.
the whole-buffer buttons are _very_ seldom used.
We could poll the users and see. If users generally use the
single-item button and not the whole-buffer buttons, I would
not mind simplifying things by eliminating the latter.
For the poll - Like Luc, I use the single-item oper
"Lennart Borgman" <[EMAIL PROTECTED]> writes:
>
>> A simpler interface with a "one line" button bar (prefeably in
>> the header line when supported) like this
>>
>> [Set] [Save] [Load] [Finish]
>>
>> would be ideal IMO.
>
> Most other applications have the buttons at the bottom. The idea as
- Original Message -
From: "Kim F. Storm" <[EMAIL PROTECTED]>
> My main objection to the customize interface is the long babble
> at the start of the buffer and the long text on the buttons.
>
> IMO, this is VERY dissimilar to other applications, and sort of
> indicates to the movice user
Richard Stallman <[EMAIL PROTECTED]> writes:
> Here's a case of someone who really wants the whole-buffer buttons.
>
> If the two of you can figure out what basic difference leads you to
> prefer these different modes of use, we might learn something from
> that.
Both of us seem to primarily cust
I think that it would be a very bad idea to move away from being able to
manipulate (e.g. edit, set, reset, & save) individual options. A given
custom buffer will perhaps have many options in several different states.
There must be a way to save one or more options in the buffer but
I would guess that the whole-buffer
buttons are _very_ seldom used.
We could poll the users and see. If users generally use the
single-item button and not the whole-buffer buttons, I would
not mind simplifying things by eliminating the latter.
Most often, I just customize a specific
I like the _current_ Custom interface. I believe that its _general
design_, including the button structure, is hard to improve on.
I can't argue with your taste, but there seems to be a lot of indication
that it is too complex and hard to understand for beginners.
__
Lennart Borgman wrote:
I thought that every option would require confirmation.
You mean every whole-buffer button? It would be really annoying if
just setting or saving an individual option would ask for confirmation.
Sincerely,
Luc.
___
Emacs-d
- Original Message -
From: "Richard Stallman" <[EMAIL PROTECTED]>
> > One possible solution for that is to discourage, or even get rid of,
> > of the per-variable command button. If there is only the
whole-buffer
> > Set and the whole-buffer Save, this confusion won't happen.
> One possible solution for that is to discourage, or even get rid of,
> of the per-variable command button. If there is only the whole-buffer
> Set and the whole-buffer Save, this confusion won't happen.
I do not think that is a good solution because the customization buffer
Richard Stallman wrote:
The concept of "exiting" does not make sense for a Custom buffer, but
there could be a buffer-wide Activate command, "Put this in effect",
which combines Set and Save. If that were the only way to make values
take effect, it would be a lot simpler than the curr
Kim Storm wrote:
Most often, I just customize a specific variable or face,
So do I.
So I use the "whole-buffer" action buttons at the top of the
customize buffer.
I personally do not see the need to go to the top of the buffer to do
that, if you have a button right next to you. (In la
Luc Teirlinck <[EMAIL PROTECTED]> writes:
> I would guess that the whole-buffer
> buttons are _very_ seldom used. It is much safer and much more
> convenient to set or save options one by one.
My "guess" is exactly the opposite...
Most often, I just customize a spe
Richard Stallman wrote:
One possible solution for that is to discourage, or even get rid of,
of the per-variable command button.
I use Custom extensively. The per-variable command buttons are the
_only_ ones I use. Getting rid of them would make Custom unusable in
as far as I am concerned
I said:
We might want to let users select a set of individual options
(e.g. using checkboxes or by dragging a region) and then
operate on the selection. That would provide a shortcut to
operating individually on each item in the set, and could help
make it clear which options w
The big problem is that if the user sets option X on a page and does
"F => C", and then (sometime later) sets option Y on the same
page, and then does "F => C,S", the effect is that the change
to X is also saved. This may be highly confusing to a user.
This is co
- Original Message -
From: "Richard Stallman" <[EMAIL PROTECTED]>
> One possible solution for that is to discourage, or even get rid of,
> of the per-variable command button. If there is only the whole-buffer
> Set and the whole-buffer Save, this confusion won't happen.
I do not think t
In contrast, most other applications only have these states:
F * the field value
A * the active (current/saved) value
D * the default value
...
The big problem is that if the user sets option X on a page and does
"F => C", and then (sometime later) sets option Y on th
Another idea is this:
Reset to Saved (S => F,C)
This interface is not necessary and is a bit confusing. The following
interface wording is better:
Set All (F => C)
Save All (F => C,S)
Get All that can be automatically written by custom-set-*
Set All (F => C)
Save All (F => C,S)
Get All
Standard (D => F)
Saved (S => F)
Current(C => F)
This is clean and symmetric, and I agree with the plan to replace
Erase Customizations with Get All Standard Values. However, t
51 matches
Mail list logo
