emacs-devel
[Top][All Lists]
Advanced

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

Re: Customize buttons that change user's custom fileshouldaskforconfirma


From: David Kastrup
Subject: Re: Customize buttons that change user's custom fileshouldaskforconfirmation
Date: Thu, 17 Feb 2005 18:27:31 +0100
User-agent: Gnus/5.11 (Gnus v5.11) Emacs/22.0.50 (gnu/linux)

address@hidden (Kim F. Storm) writes:

> "Lennart Borgman" <address@hidden> 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 far as I
>> understand it is to have the field and buttons ordered so that what is used
>> first comes first. This is both a visual ordering and a keyboard ordering.
>> You get used to press TAB to go to the button or field you need next. (I
>> think we should encourage keyboard use. Accessability and health.)
>
> The reason the header line is nice is that it will remain on the screen
> even when you scroll the customize window.  But of course, you cannot
> activate it with your mouse.
>
> But it would make sense if C-x C-s saved the settings, while C-c C-c
> just set them.

In that case it would be more intuitive if the buffer would get its
modification flag set for any changed options, was treated to the same
"`*Customize settings*' not saved" dialog as other unsaved buffers
when exiting Emacs, and we should have a button "don't save" (which
would then exempt the option from influencing the buffer modified flag
and from getting saved as long as the buffer remains intact) for
options.

That would enable options to be changed temporarily, it would make the
default of option changes permanent (like users are accustomed to),
but if one is unsure about a setting, one simply does not save the
option buffer, and then one will get reminded when exiting Emacs that
options (that are not marked "Don't save" explicitly) might get lost.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum




reply via email to

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