From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Christoph Wedler Newsgroups: gmane.emacs.help Subject: Re: In defense of Customize [was: Trying to right-align my window on startup] Date: Thu, 30 Jan 2014 11:14:04 +0100 Organization: SAP AG Message-ID: <6hr38k5rd3n.fsf@sap.com> References: <3cec217d-8adb-4e6c-b239-eff0c8b520c9@googlegroups.com> <6hrwqhkjfv6.fsf@sap.com> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1391077217 8619 80.91.229.3 (30 Jan 2014 10:20:17 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 30 Jan 2014 10:20:17 +0000 (UTC) To: help-gnu-emacs@gnu.org Original-X-From: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Thu Jan 30 11:20:26 2014 Return-path: Envelope-to: geh-help-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1W8ojQ-0003qq-IT for geh-help-gnu-emacs@m.gmane.org; Thu, 30 Jan 2014 11:20:24 +0100 Original-Received: from localhost ([::1]:47368 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W8ojQ-0007un-4s for geh-help-gnu-emacs@m.gmane.org; Thu, 30 Jan 2014 05:20:24 -0500 Original-Path: usenet.stanford.edu!goblin2!goblin.stu.neva.ru!weretis.net!feeder4.news.weretis.net!news1.dtag.de!news.sap-ag.de!news1!news.sap-ag.de!not-for-mail Original-Newsgroups: gnu.emacs.help Original-Lines: 206 Original-NNTP-Posting-Host: nKU7bvDXFB5LzogK6rDeaQ.news.sap-ag.de Original-X-Trace: news.sap-ag.de 1391076845 11012 nKU7bvDXFB5LzogK6rDeaQ.news.sap-ag.de (30 Jan 2014 10:14:05 GMT) Original-X-Complaints-To: newsmaster@sap.com Original-NNTP-Posting-Date: Thu, 30 Jan 2014 10:14:05 +0000 (UTC) Cancel-Lock: sha1:qaNLUlixWm6aDjVtN5YW8Ed8Ccc= User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (windows-nt) Original-Xref: usenet.stanford.edu gnu.emacs.help:203521 X-BeenThere: help-gnu-emacs@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Users list for the GNU Emacs text editor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Original-Sender: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.help:95789 Archived-At: Drew Adams 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