From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: "Drew Adams" Newsgroups: gmane.emacs.devel Subject: RE: Getting more info on a variable in Customize buffers Date: Thu, 6 Jan 2005 11:05:38 -0800 Message-ID: References: NNTP-Posting-Host: deer.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Trace: sea.gmane.org 1105038558 23543 80.91.229.6 (6 Jan 2005 19:09:18 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Thu, 6 Jan 2005 19:09:18 +0000 (UTC) Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Jan 06 20:09:05 2005 Return-path: Original-Received: from lists.gnu.org ([199.232.76.165]) by deer.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 1Cmd0K-0002yS-00 for ; Thu, 06 Jan 2005 20:09:04 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.33) id 1CmdBc-0004XY-W2 for ged-emacs-devel@m.gmane.org; Thu, 06 Jan 2005 14:20:45 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.33) id 1CmdBR-0004V2-8n for emacs-devel@gnu.org; Thu, 06 Jan 2005 14:20:33 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.33) id 1CmdBP-0004SX-2y for emacs-devel@gnu.org; Thu, 06 Jan 2005 14:20:32 -0500 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.33) id 1CmdBN-0004SO-Kg for emacs-devel@gnu.org; Thu, 06 Jan 2005 14:20:30 -0500 Original-Received: from [141.146.126.229] (helo=agminet02.oracle.com) by monty-python.gnu.org with esmtp (TLSv1:DES-CBC3-SHA:168) (Exim 4.34) id 1CmcxC-00015T-2g for emacs-devel@gnu.org; Thu, 06 Jan 2005 14:05:50 -0500 Original-Received: from agminet02.oracle.com (localhost [127.0.0.1]) by agminet02.oracle.com (Switch-3.1.4/Switch-3.1.0) with ESMTP id j06J5hcg011955; Thu, 6 Jan 2005 11:05:43 -0800 Original-Received: from rgmsgw301.us.oracle.com (rgmsgw301.us.oracle.com [138.1.191.50]) by agminet02.oracle.com (Switch-3.1.4/Switch-3.1.0) with ESMTP id j06J5ePe011896; Thu, 6 Jan 2005 11:05:42 -0800 Original-Received: from rgmsgw301.us.oracle.com (localhost [127.0.0.1]) by rgmsgw301.us.oracle.com (Switch-3.1.4/Switch-3.1.0) with ESMTP id j06J5eKv013713; Thu, 6 Jan 2005 12:05:40 -0700 Original-Received: from dradamslap (dradams-lap.us.oracle.com [130.35.177.126]) by rgmsgw301.us.oracle.com (Switch-3.1.4/Switch-3.1.0) with SMTP id j06J5dqq013703 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Thu, 6 Jan 2005 12:05:39 -0700 Original-To: "Per Abrahamsen" , X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 Importance: Normal X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: main.gmane.org gmane.emacs.devel:31964 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:31964 > Therefore I believe every piece of > information we get about how different persons react to this > interface is important. Unfortunately, expert users are much more likely to provide feedback then casual users. Unfortunately in some ways, but fortunately in others. I agree with your statement (http://www.dina.kvl.dk/~abraham/rants/documentation-goals.html) that "if your goal is to get qualified feedback, preferably in the form of patches or at least useful bug reports, ordinary users aren't going to be what you are after." Therefore, free software user interfaces tend to be "expert friendly", rather then "beginner friendly". An in particular, cram way to much information and functionality into the UI, scaring off beginners and casual users. Power users in the area of UIs give valuable feedback criticizing poor UIs. The average free-software expert user might not be an expert on UIs, but some no doubt are. People who are interested in UIs, whether expert users of the particular UI or not, tend to take a UI-user point of view, just as people interested in doc take a reader point of view. That's helpful. I agree with your point, however, that feedback from users who are not familiar with the application and its UI is 1) important and 2) hard to obtain. In the current case, I am not a novice wrt Emacs, but I am a novice wrt Customize. (We are all novices in some context.) Feedback from Emacs users who are novices to Customize is useful (and apparently hasn't been that hard to obtain :-)). Even if their ultimate use of Customize will not be that of the primary target audience (non-Lispers), their feedback can serve. (See below on the Customize audience.) Which is fine in general, expert friendly software is very important. But Emacs has always been expert friendly. Expert users already have an excellent interface for customizing Emacs, namely Lisp. Customize was supposed to add an *additional* interface in order to make customization easier for casual users. Drew Adams feedback seems to build on the mistaken belief that Customize is the preferred way to customize Emacs. Which is far from the truth. Chalk it up to a mistaken impression on my part. And there are no priests to out :-). Beyond that mistaken impression, I also made the point that a Lisp user of Emacs needs now to have some understanding of Customize (both the UI and the customize functions) - if for no other reason than that reading the Lisp source code now requires it. And writing library code requires it (per priests). If you write code for users of a UI, you need some familiarity with that UI (as a user and as a developer). However, my main point was that dividing Emacs users into two mutually exclusive sets - those who use Lisp and those who use Customize - is a mistake. Customize should be aimed primarily at non-Lisp users, in the sense that one should not _need_ to use or understand Lisp to be able to use Customize. But that does not mean (to me) that Customize should not _also_ be useful for Lisp users of Emacs. I mentioned the benefit of a good options browser to Lisp users as well as beginners. I also pointed out that there are already many parts of the UI that concern Lisp sexps and are obviously _not_ for beginners. There is nothing wrong with that, as long as the UI does not place such stuff in the way of non-Lisp users - it should not distract them; ideally, they would not even see it. I agree with Bob Chassell that "Advanced Customization" is a good (and typical) way to separate the sheep from the goats and still let each stray to the other, apparently greener side if/when they wish. In sum: Customize is for everybody, even if its primary raison d'etre is to help non-Lisp Emacs users customize Emacs. My other main point is that for Emacs aficionados, and _even more so for Emacs novices_ (just a guess), the Customize UI has problems. Problems in orientation, navigation, presentation, clutter, and semantic clarity. And the same UI improvements will help both groups of user. I do not believe there are any "preferred way" to customize Emacs. There are a number of different mechanisms (Lisp, X resources, the customize group interface, the customize browse interface, the customize menu interface, The Options menu, edit-options, set-variable, and customize-set-variable). None of these are obsolete. Well, maybe "edit-options" is. They are useful in different situations, to different users. And they mostly play along together. I agree with all of that. The last sentence is key here, however - I would disagree with it if "mostly" weren't guarding it so well. This thread has been about some ways in which Customize does _not_ play too well with the rest (as well as about some general pbs with Customize). It has included remarks from people for whom it is not clear how to do customize-like or customize-compatible changes from Lisp (so that Lisp and Customize will play well together). It has also included remarks from people like me who feel that Customize should at least provide everything that `C-h v' provides - for both Lisp users and novices (so that Lisp and Customize will play well together).