From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Drew Adams 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:47:50 -0800 (PST) Message-ID: <4b1a3e90-5099-4e60-8739-5a80b463dd86@default> 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; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Trace: ger.gmane.org 1390956500 14966 80.91.229.3 (29 Jan 2014 00:48:20 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 29 Jan 2014 00:48:20 +0000 (UTC) To: Christoph Wedler , help-gnu-emacs@gnu.org Original-X-From: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Wed Jan 29 01:48:25 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 1W8JKJ-0001xX-En for geh-help-gnu-emacs@m.gmane.org; Wed, 29 Jan 2014 01:48:23 +0100 Original-Received: from localhost ([::1]:40054 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W8JKI-0007pO-6W for geh-help-gnu-emacs@m.gmane.org; Tue, 28 Jan 2014 19:48:22 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:36177) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W8JJz-0007pD-4M for help-gnu-emacs@gnu.org; Tue, 28 Jan 2014 19:48:10 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1W8JJs-0006fI-8W for help-gnu-emacs@gnu.org; Tue, 28 Jan 2014 19:48:03 -0500 Original-Received: from userp1040.oracle.com ([156.151.31.81]:29188) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W8JJr-0006fC-TI for help-gnu-emacs@gnu.org; Tue, 28 Jan 2014 19:47:56 -0500 Original-Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id s0T0lq27003171 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 29 Jan 2014 00:47:54 GMT Original-Received: from userz7021.oracle.com (userz7021.oracle.com [156.151.31.85]) by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id s0T0lp6B025159 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 29 Jan 2014 00:47:52 GMT Original-Received: from abhmp0006.oracle.com (abhmp0006.oracle.com [141.146.116.12]) by userz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id s0T0lplv008694; Wed, 29 Jan 2014 00:47:51 GMT In-Reply-To: <6hrwqhkjfv6.fsf@sap.com> X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.8 (707110) [OL 12.0.6680.5000 (x86)] X-Source-IP: acsinet22.oracle.com [141.146.126.238] X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.4.x-2.6.x [generic] X-Received-From: 156.151.31.81 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:95741 Archived-At: > > I hardly think that Per Abrahamsen is a wimp, wrt Lisp or Emacs, > > at least. http://www.emacswiki.org/PerAbrahamsen >=20 > 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... >=20 > >> > > 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. >=20 > 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. > The UI is just a minor point. So which were the issues most users > had with customizing Emacs before the advent of custom.el: >=20 > 1. Exploring customization options. >=20 > 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. >=20 > 2. Doing the customization. >=20 > 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. >=20 > 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 ... >=20 > 3. Re-using customization (parts) of other Emacs users (or own on > other machine) >=20 > 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. >=20 > Which issues does custom.el solve? >=20 > 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. Customize does not provide the greatest preferences browser. But the various `customize-apropos*' commands help. I suspect that not enough users take advantage of these commands, or are even aware of them. [FWIW, in Icicle mode, Emacs commands that let you choose an option become essentially Customize browsers. Each command invocation provides access to any number of options and information about them. You can match options using multiple patterns, each of which can be a substring or regexp. And you can show the doc for any options you choose, on the fly while matching.] > 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... That's not that common a problem, IMO, but it can be a real problem nonetheless. At least the doc of an option that depends on other options should, and usually does, call this out. That's not a real solution, but it helps. > 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). I agree that Customize does not help a lot wrt exploring options (browsing, discovering). I don't understand, however, why you say that its limited help is mainly for options in the same package. > 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. Not sure what you're saying here. Are you just saying that it is not always enough to be able to match option (or command) _names_? That's certainly true, given that the names of some are not ideal, and especially given that different users can think in terms of different words about them (e.g., "abbrev", "expand", "complete"). In that regard, for vanilla Emacs I would mention `apropos-doc', which matches doc strings. Not a panacea, but worth knowing about. [Icicles multi-command `icicle-vardoc' does a better job of matching doc strings and/or names of variables.] Besides matching option names and doc strings, exploring can benefit from being able to match custom _types_. Matching here can mean several things. [There are several Icicles multi-commands (browsers) that let you do this, each letting you type-match in different ways. Each lets you match the option name at the same time as the type: * `icicle-describe-option-of-type' (show doc) * `icicle-customize-apropos-options-of-type' (customize) * `icicle-apropos-options-of-type' (list) See http://www.emacswiki.org/emacs/Icicles_-_A_Propos_d'Apropos.] > 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. And there is not only type-checking but also other handling wrt initializing and updating values, e.g., handling of :initialize and :set triggers. Of the problems I see users asking about wrt setting option values, the vast majority have to do with them using setq either to set the value to something that conflicts with the type or without also doing what :set or :initialize calls for. IOW, they do not treat the option wrt its possibly complex definition, and handle it as if it were a simple defvar. And that gets them into trouble. The fault here is sometimes inadequate doc, that in effect leads the user down the garden path to a mistake, by not making clear what the restrictions are on the option value etc. But the fault is also too often, IMO, with users who want to feel "Lispian" by using setq rather than using something as "non-programmer" as the Customize UI. "Look Ma, no hands!" > Setting some values in specific mode (or mode groups) is > not possible. It is only possible to the extent that the application provides for it. You are right that there is nothing about this that is part of the UI. But a library can certainly create an option that is only useful in certain contexts or is only usable in certain ways. > 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#IciclesCustomizingKeysScree= nshot] Not sure what you mean by "let alone for something like the mode-line". But I guess you mean that it is not simple to customize the mode line. Agreed, beyond some basics. If your point is that customizing Emacs is in many ways not covered by Customize then I doubt that you will find anyone who disagrees. Certainly the structure of menus, keymaps generally, font-lock-keywords, `mode-line-format', and even face specs is complex. That is the case in _Lisp_, and Customize offers little-to-nothing to help in this regard. But it should. And so should the Lisp handling of these things be made easier. That might be your argument; dunno. It is mine. > 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. FWIW, that is the kind of thing that Do Re Mi tries to offer. But those kinds of things could usefully be used as _plug-ins_ for the Customize UI, extending it in more useful, direct-manipulation ways. If, that is, Customize provided for such easy plugging-in... Currently, choosing a color, say, with the Customize UI is pretty primitive. Here too there are better color-choosing UIs, but they are all relegated to remaining essentially outside Customize. That's OK, since it is possible for such a library to let you save a choice you make as a custom value (i.e., so it is recognized by Customize). But few do that, perhaps out of ignorance of the custom*.el code. What is true wrt defining themes is also true wrt using `font-lock-keywords', at least in any context where those keyword entries are multiple or complex. What's needed is one or more UIs (e.g., commands) for tweaking and immediately visualizing the effects. See this recent StackOverflow question and answers for a start in this direction: http://stackoverflow.com/questions/21125658/how-to-test-font-lock-keywords-= values-for-emacs-lisp-code/ > 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. Yes. But there is also value in automatic handling of such things, especially when they are complex structures. 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.) > 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") I think you are underestimating :type, in particular. But there, the responsibility is on the programmer who uses defcustom. If s?he uses it only like defvar, then yes, Customize - at best - just makes things a bit easier that were already easy. And maybe not even a bit easier. If a programmer uses defcustom as if it were defvar then, sure, users of that library might as well use setq. But if your argument is that the most complex structures in Emacs Lisp: menus and other keymaps, `font-lock-keywords', `mode-line-format', and the like are not usefully accessible to users via the Customize UI, well, that's obvious - a no-brainer. And I agree that it is not the case that wanting or needing to tweak such things maps only to "advanced users". And you are right to point this out as one of the biggest Emacs impedance mismatches: to do something that nearly everyone might want to do (if it were easy), you are confronted immediately with a monstrous recursively defined list structure (sometimes with shared structure) and hard-to-fathom doc. > - `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. > - 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.) 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." I don't see those things as difficult or as things that are hanging users up or binding them in knots of confusion. But maybe I'm missing something. > 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. >=20 > - 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. Sorry, I don't see that as solving any real problem, unless you feel that some package authors make what should be internal variables into user optinos. I haven't noticed that much, but I'm sure it can happen. 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. There are lots of options, true. But I don't see that most of them, or even many of them, should not be options. I don't see the number of options as a problem. One should not multiply things unnecessarily (Occam), but that does not mean that blindly limiting things is smarter. A variable whose value really _must_ be an integer, and which you want users to know that they are invited to change - as a user preference, is better off as a user option than as an internal variable (defvar). I've seen enough naive users setq a variable whose value must be a symbol to a string value instead, and vice versa. What you say there sounds only like an argument against the notion of user option. I disgree with that, in any case. Any user can tweak any Lisp variable - and that's a good thing. But it can help users to let them know about some variables that have been designed specifically to allow for user fine tuning (customization). Guiding users to user options helps them. Making every variable essentially the same - just another global variable - does a disservice to users. > 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. Saying that in some cases (do you really mean "most"?) you can imagine a better, more hierarchical disposition of user-tweakable knobs is in no way an indictment of Customize or of user options. It says nothing about either. You are essentially just going on about some people misusing these things. That is no different from my saying that some programmers do not bother defining good :type specs when they create defcustoms. But my argument is in defense of the constructs they misuse: the problem is not the constructs but the poor use of them. Your argument seems to be that because some programmer creates more options than needed, or does not organize a program's customization as efficiently as you might expect, the fault is with the existence of user options, Customize, and `defcustom'. Too facile. Don't get me wrong. I agree with some of what you say. But I do not see either the notion of user option or the control over variable values offered by `defcustom' as the problem. Nor do I see the existence of a Customize UI as the problem. (It needs to be improved, not abandoned.) Nor do I see programmatic control over saving and restoring user preferences as the problem. (It needs to be kept out of user init files, not abandoned.) To come back for a moment to the misuse of defcustom, which I'm guessing is too often due to laziness and ignorance: I think of that pretty much the way I think of the relative lack of menu support provided by 3rd-party packages: These are not the first things one writes, when coming up with a new package. They are typically among the last things. You might even add documentation to that list, although nowadays more programmers take doc more seriously, if only because they sometimes have to. These things are not the core of a package. And they too often get short shrift. As a result of their relative lack of attention to these things, some programmers do not bother to learn much about building good Emacs menus or defining good defcustoms. The same would even be true of keymaps and font-lock-keywords, except that features closer to the core often involve them. They tend to be, let's say, second-class, whereas well designed menus and user options tend to be third-class.