help-gnu-emacs
[Top][All Lists]
Advanced

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

Re: In defense of Customize [was: Trying to right-align my window on sta


From: Christoph Wedler
Subject: Re: In defense of Customize [was: Trying to right-align my window on startup]
Date: Thu, 30 Jan 2014 11:14:04 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (windows-nt)

Drew Adams <drew.adams@oracle.com> writes:

>> >> > I just hate its UI.
>> 
>> I do not hate Customize, but I think that Customize does not solve
>> the main problems many users had and have with customizing Emacs.
>
> It certainly does not solve all customization needs.  Nor does
> anyone claim otherwise.

Actually, it does not solve customization needs, which could be called
basic, like binding keys to commands.  But people always mention the UI
as the main custom problem - I now believe the UI is a distraction (at
least for the moment).

>> Which issues does custom.el solve?
>> 
>>  1. Number of options: well, nothing has changed. People are still
>>     overwhelmed by the sheer number of options.

> I would consider that mainly a Customize UI problem.

I do not agree.  The problem is that we did not really define for what
we want to use Custom.  In Emacs, Emacs Lisp provides a very powerful
possibility to do the most advanced customizations.  Surely, nobody want
to define some UI-based customization functionality offering the same
amount of possibilities.

Therefore:

 - define what basic customization needs are (key binding are definitely
   part of that) - these customization should (in the end) be influenced
   by some customization UI.

 - make the customization functionilty co-exist with Emacs Lisp - if
   people have more advanced customization needs, we should _encourage_
   them to use Emacs Lisp.

   Changing gc-cons-threshold is surely an advanced customization.  And
   a lot of other options - we could de-customize all these and a casual
   user sees less customization options

We have not done that for custom.  Therefore, we do not have a
user-centric decision (which should be covered by custom, which not),
but an implementation-based one (which kind of settings are easy to
implement).
>
>>  2. Positive: face customizations became easier.
>>     Otherwise: nothing has changed much.  Yes, there is some type
>>     checking on the values now.  But to be honest, I do not see the
>>     point that people do not have to use Lisp to set the value of
>>     some option to some Lisp function or even sexpr.
>
> Some type-checking?  There is a _lot_ of type-checking.
>
> Or rather, the type-checking done corresponds to the :type defined.
> If the writer of the defcustom was lazy and did not write a :type
> declaration that specifies a type that is sufficiently narrow, then
> the type-checking will be correspondingly loose. That is the main
> problem with many option definitions, IMO: lazy typing.
>
> And that can be due insufficient familiarity with :type sexps.

I think I'm familar with that - see e.g.
   M-x customize-variable RET antlr-indent-comment RET

> And there is not only type-checking but also other handling wrt
> initializing and updating values, e.g., handling of :initialize
> and :set triggers.

Right, these two are useful.  Actually, :require is also (almost)
useful.  It would be good to have an :require-unless-nil and use that
not as part of the customization settings, but have autoload.el put that
info into some loaddefs.el.

>>     Defining key and menu bindings: nothing, let alone
>>     for something like the mode-line, ...
>
> Menus, no.  Keys, yes.  There are plenty of options that let
> users specify key bindings.  See :type keyword `key-sequence',
> for a start.
>
> [I use my own widget (keyword) for this, which lets you specify
> a command and a key sequence to bind to it or another command to
> remap to it (for the minor mode).
> http://www.emacswiki.org/Icicles_-_Key_Bindings#IciclesCustomizingKeysScreenshot]

Yes, nice packages could make use of that - but how does that affect the
global-map or c-mode-map without some Lisp code?

>>  3. Positive: custom-themes could be a step in the right direction
>
> Yes and no.  The real "customization" in that case is done by
> the person defining the theme.  Applying a theme is only
> "customization" in the weakest sense.  It counts as such, but
> saying that really misses the point.
>
> What is really missing wrt Customize here is help for _defining_
> themes.  In particular, incremental, direct-manipulation ways of
> turning knobs to get the colors, fonts, etc. that you want here
> and there, and then pushing a button to save what you created as
> a theme.  And ways to compare themes, blend them (WYSIWYG), and
> undo their effects, all components together, and sets of
> components, and components individually.

I do not agree - Lisp code for custom themes are completly ok -
actually, I do my settings by defining some custom themes (as far as
that is possible) via Lisp code.

> Such generated code should of course be kept out of user init
> files.  All users who use Customize at all should define option
> `custom-file', to prevent Customize from using their init file.
> (That should be required by Emacs, for Customize to save anything.
> Emacs not doing that is asking for trouble and not doing users any
> favor, IMO.)

Agreed.  Now everybody must set `custom-file'.

>>  - `gc-cons-threshold' is customizable (which non-Lisper should
>>    change that?), but
>
> Any of them might - why not?  But what's the point?  That it is
> too easy to do that without Customize?  That it is too advanced
> or too hard for non-Lispers to do that?  I don't follow, here.

People who want to change that are somehow interest in Lisp - what is
wrong when they use Lisp to change that value?

>>  - defining a keybinding for C programming requires to define a
>>    function which has to be added to some hook...
>
> Why?  I don't program in C anymore, but isn't there a keymap for
> C mode that you can define the key in?
>
> If you want to define a key in Emacs Lisp mode, you just use
> (define-key THE-KEY emacs-lisp-mode-map).  No defining a function.
> No use of any hook.  (Although I have seen users jump through such
> hoops even when it was not necessary.)

Exactly.  People can often forget about such hooks if they do a
require.  But then the autoloads are bit useless...

Hooks are still necessary for things like imenu-add-to-menubar.

>
> Yes, sometimes the mode map does not exist up front, so you might
> need to do as you say.  But that's not such a big deal, is it?
>
>> So instead of spending time on some UI, things would IMHO improve
>> by the following (doing the UI later)
>
> No one is spending time working on the Customize UI, AFAIK.
> That's one reason it is still so rudimentary or "old-fashioned".
> And as I said earlier, one reason that no one works on it is that
> its code is hard to work with (including debugging).
>
>>  - Define top-level forms for customizations which many people
>>    want to do - something like
>>       (cus-set 'indent-tabs-mode t)
>>       (cus-set 'indent-tabs-mode nil :mode prog-mode)
>>       (cus-define-key "some binding" command :mode c-mode)
>
> Go for it.
>
> To me, that would be precisely "ma[king] things a bit easier which
> were easy before and do[ing] little to help with the others."

Then show me the easy code for setting indent-tabs-mode to t in general
and to nil in all programming modes.

>>  - To handle issue 1: make less options customizable: make package
>>    authors define 5 good customization options, do not propose to
>>    make their 30 variables (user options) customizable.  These
>>    customization option just contain "easy" values: integer,
>>    string value, or a enum-like use of symbols, or a simple list
>>    consisting of these types.

> [...]
> If you are just making a plea for fewer user options, and think
> that many of them should instead be internal variables (presumably
> not just a few bad 3rd-party packages but even options delivered
> with Emacs?) then I would disagree.

No, I do not propose to deliever fewer user options which users could
change via Lisp.  I say that not all are useful to expose to some
customization UI.

So, that is basically a third category of global vars,.

>>    Most of these options could actually influence the values
>>    of some variables - something like custom-sub-themes
>>    (defined in the package) or something like c-style.
>
> Too vague to usefully respond to.  But IIUC, nothing wrong
> with doing that.

Look into cc-styles.cc.  c-offsets-alist, c-hanging-braces-alist etc are
all user options (they are currently customizable, too), but their
values or mostly constrolled by styles.

Generalized, I would propose that variables like these are user options,
but not customizable; in the custom UI, the user can choose a style
which then sets to above mentioned variables.

Regards,
Christoph


reply via email to

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