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: Tue, 28 Jan 2014 16:17:01 +0100 Organization: SAP AG Message-ID: <6hrwqhkjfv6.fsf@sap.com> References: <3cec217d-8adb-4e6c-b239-eff0c8b520c9@googlegroups.com> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1390927463 16697 80.91.229.3 (28 Jan 2014 16:44:23 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 28 Jan 2014 16:44:23 +0000 (UTC) To: help-gnu-emacs@gnu.org Original-X-From: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Tue Jan 28 17:44:32 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 1W8Bm3-00053f-GC for geh-help-gnu-emacs@m.gmane.org; Tue, 28 Jan 2014 17:44:31 +0100 Original-Received: from localhost ([::1]:38218 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W8Bm3-00022M-4r for geh-help-gnu-emacs@m.gmane.org; Tue, 28 Jan 2014 11:44:31 -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: 126 Original-NNTP-Posting-Host: nKU7bvDXFB5LzogK6rDeaQ.news.sap-ag.de Original-X-Trace: news.sap-ag.de 1390922221 26904 nKU7bvDXFB5LzogK6rDeaQ.news.sap-ag.de (28 Jan 2014 15:17:01 GMT) Original-X-Complaints-To: newsmaster@sap.com Original-NNTP-Posting-Date: Tue, 28 Jan 2014 15:17:01 +0000 (UTC) Cancel-Lock: sha1:yf+Ieafkxo4yi7M3Aw2t/V/RfgU= User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (windows-nt) Original-Xref: usenet.stanford.edu gnu.emacs.help:203464 X-Mailman-Approved-At: Tue, 28 Jan 2014 11:44:20 -0500 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:95735 Archived-At: Drew Adams writes: [...sequence of citation does not match sequence in cited article...] > I hardly think that Per Abrahamsen is a wimp, wrt Lisp or Emacs, > at least. http://www.emacswiki.org/PerAbrahamsen Just to put the rest of this posting into context: neither do I. Everybody who has written LaTeX documents knows that Per has done an excellent job with AucTeX - just one example... >> > > But (IMHO) too many people ignore Customize, often because >> > > they've gotten the impression somehow that it is for non-Lispers >> > > or wimps. >> > >> > 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. The UI is just a minor point. So which were the issues most users had with customizing Emacs before the advent of custom.el: 1. Exploring customization options. There were too many customization option to grasp (I'm not against having many options!), and one could not easily grasp the interdependence between different options. 2. Doing the customization. Users had no problems using a `setq' in combination with an boolean, integer, string value, or a enum-like use of symbols, or a simple list consisting of these types. `global-set-key' was also almost ok. They had (and have - that is the point!) a problem with having to define a function/form which contains the necessary customizations and having to add this to some hook, provide it to eval-after-load, or ... 3. Re-using customization (parts) of other Emacs users (or own on other machine) Many users re-used parts of the ~/.emacs files of others. The problem was that these settings were a mixture of personal setting (e.g. user-full-name), local / system-dependent settings (grep-find-command), questions of taste (face colors), etc and tended to grow old. Which issues does custom.el solve? 1. Number of options: well, nothing has changed. People are still overwhelmed by the sheer number of options. People are also puzzled if changing some option does not have any effect, because it depends on other options to be set to a specific value... Yes, custom helps a bit with exploring these options, but actually mainly on the intra-package level (which Lispers could do for themselves by looking at the defvar in the el file). If I'm interested in the possibilities for auto-completing some symbol/word, I still have to know them: abbrev-mode, dabbrev-expand, complete-tag (but no corresponding imenu-...), and in a wider sense: ido, ... To be fair: this is diffucult. 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. Setting some values in specific mode (or mode groups) is not possible. Defining key and menu bindings: nothing, let alone for something like the mode-line, ... 3. Positive: custom-themes could be a step in the right direction Negative: sharing customization settings is now actually more difficult, because auto-generated custom files lack comments which explain why default values have been changed, and because they are ordered alphabetically and not topic-wise. Settings which work on different machines are harder to do. In short: custom.el made things a bit easier which were easy before and does little to help with the others (and unfortunately these two are not synonyms for "many users want to change it" and "should be left to advanced users") - `gc-cons-threshold' is customizable (which non-Lisper should change that?), but - defining a keybinding for C programming requires to define a function which has to be added to some hook... So instead of spending time on some UI, things would IMHO improve by the following (doing the UI later) - 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) Currently, many (mostly minor-mode) packages define their own way of offering something like that (see e.g. font-lock-maximum-decoration). Otherwise, people have to add some function to some hook. - 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. 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. Advanced users could easily define their own custom-sub-themes / styles - "custom" and stand Elisp co-exist nicely. Regards, Christoph