From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Terje Bless Newsgroups: gmane.emacs.devel Subject: Re: The minibuffer vs. Dialog Boxes (Re: Making XEmacs be more up-to-date) Date: Sun, 21 Apr 2002 02:56:05 +0200 Sender: emacs-devel-admin@gnu.org Message-ID: References: NNTP-Posting-Host: localhost.gmane.org Mime-Version: 1.0 Content-Type: text/plain; Charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Trace: main.gmane.org 1019351918 21593 127.0.0.1 (21 Apr 2002 01:18:38 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Sun, 21 Apr 2002 01:18:38 +0000 (UTC) Cc: Eli Zaretskii , jas@extundo.com, bradym@balestra.org, xemacs-design@xemacs.org, emacs-devel@gnu.org Return-path: Original-Received: from quimby.gnus.org ([80.91.224.244]) by main.gmane.org with esmtp (Exim 3.33 #1 (Debian)) id 16z5zy-0005cA-00 for ; Sun, 21 Apr 2002 03:18:38 +0200 Original-Received: from fencepost.gnu.org ([199.232.76.164]) by quimby.gnus.org with esmtp (Exim 3.12 #1 (Debian)) id 16z5zx-0005ms-00 for ; Sun, 21 Apr 2002 03:18:37 +0200 Original-Received: from localhost ([127.0.0.1] helo=fencepost.gnu.org) by fencepost.gnu.org with esmtp (Exim 3.34 #1 (Debian)) id 16z5zn-0005Zy-00; Sat, 20 Apr 2002 21:18:27 -0400 Original-Received: from mail.wavelan.no ([217.144.228.111] helo=isa) by fencepost.gnu.org with esmtp (Exim 3.34 #1 (Debian)) id 16z5xU-0005WS-00 for ; Sat, 20 Apr 2002 21:16:05 -0400 Original-Received: from [217.144.228.69] by isa (ArGoSoft Mail Server Pro for WinNT/2000/XP, Version 1.8 (1.8.1.1)); Sun, 21 Apr 2002 03:18:07 +0200 Original-To: Hrvoje Niksic X-Priority: 3 In-Reply-To: X-Mailer: Mailsmith Prerelease (Blindsider) Errors-To: emacs-devel-admin@gnu.org X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.0.9 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Emacs development discussions. List-Unsubscribe: , List-Archive: Xref: main.gmane.org gmane.emacs.devel:2893 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:2893 Hrvoje Niksic wrote: >Eli Zaretskii writes: > >>The menu itself shows the keybinding, if any, that invokes the same >>command. Isn't that good enough? > >It's not good enough for what Terje was complaining about. Under >XEmacs, if you open the "Buffers" menu, you can choose the buffer you >want to go to. But there is no keybinding equivalent to "go to buffer >named foo.c", hence none is written. Actually, it's slightly worse. I use '(buffers-menu-submenus-for-groups-p t) (I have no idea what this feature is /really/ called) and the "Switch to Buffer" command in the buffer sub-menu lists no keyboard shortcut. None of the menus offer a way to cycle sequentially through buffers and certainly offer no keyboard equivalent. The lack of a command to go to a named buffer is irrelevant; doing that involves so much typing I'd rather select it from the menu. >In this case, one must learn the procedure by reading the manual. I >have no problem with this, but Terje confesses to have been unwilling >to do so for years. Maybe it can be improved? Well, from my point of view, it certainly can. As we discussed some years ago Hrvoje, from my point of view (X)Emacs is a mere editor; a tool for editing the kinds of files that I want to edit. The fact that it has a lisp interpreter and a rich library isn't an advantage; it's a _liability_. I don't know lisp. I don't even /like/ lisp. I do like a specific subset of Emacs-the-text-editor's features though. So to improve the "manual" for /me/ you'd have to remove every reference to lisp from it. Feel free to explain the concepts Emacs uses and mention that .emacs contains "configuration", but the second you throw in a "sexp" or a "feature-p" or too many parens you've lost me. I'll freely and gladly admit to ignorance, to inability to learn, and to these being my failures and not Emacs=B4. But wouldn't it be nice if Emacs could make up for my failings so that I could be productive with it too? I get by with C-x C-f, C-x C-s, C-s, and C-x C-c. I manage the occasional foray into Customize and instructions that say "put this in your .emacs". And the stuff in the Options menu makes my life ever so much easier. But a lot of the time I'm hindered by the fact that Emacs insists on me adapting to it, instead of it adapting to me. It "DWIMs" fairly well in some situations, but a lot less well in others. And writing lisp code is considered an acceptable way to interact with Emacs for normal users! But the real point of all this isn't any specific feature or implementation detail. The main point I'd like to make is that, again in my opinion, the single most important factor in making Emacs more accessible to more people is to start giving more weight to these issues (and, yes, as a consequence less weigth to other issues; it's a tradeoff when resources are limited). The technical merit of any given feature is important. The cleanliness of it's API, or of how it uses the API, is important. How powerfull the feature is, how fast it is, how much overhead it has, these are all important issues. But how well it fits in with the expectations of Joe R. User is _also_ important! The perfect feature needs no documentation because it's intuitively obvious how it works. It's existence so obvious that it doesn't need to be pointed out, and it's placement so natural that the user doesn't have to be pointed in the right direction. That's not achievable of course, but striving to approach that (to the point where diminishing returns dictates you stop) will be _better_ even if perfection is not possible. Or maybe I just wish to redefine what is the "average" user of Emacs. Right now, as far as I can tell, the "average" user knows more then average (if you'll pardon the pun) about lisp and the implementation details of Emacs. There is a fairly large barrier to entry. When you pass it it will scale upwards very well, but it doesn't scale _down_ at all well. There is this huge gap between doing everything from the menus and writing your own custom lisp bits to make Emacs behave the way you want it to. This gap is what I first would like to see filled. But there is also a possibility that Emacs just isn't the tool for me. Perhaps it's too advanced a tool for my simple use and I should stay with less powerfull, but also more easy to understand tools. That's a valid point of view. I'd like to see Emacs cater to me also, and I firmly believe it can do that without compromising away the power it has that more advanced users need. Oh, one final thing... I usually keep my mouth shut on these lists. I lurk here because I like to keep tabs on what's happening in the future for my toolchain and because they're sometimes informative and sometimes funny (the recent threads on garbage collectors on Xemacs-beta fall into both categories ;D). I'm poking my nose in here because I genuinely believe that my point of view might be usefull to those actually designing and implementing the Emacsen. Anyone that disagrees may feel free to tell me to buggar off and mind my own business (though perhaps off-list). I promise I won't be offended! :-)