From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: The minibuffer vs. Dialog Boxes (Re: Making XEmacs be more up-to-date) Date: Mon, 22 Apr 2002 09:02:10 +0300 (IDT) Sender: emacs-devel-admin@gnu.org Message-ID: References: NNTP-Posting-Host: localhost.gmane.org Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Trace: main.gmane.org 1019451982 15217 127.0.0.1 (22 Apr 2002 05:06:22 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Mon, 22 Apr 2002 05:06:22 +0000 (UTC) Cc: 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 16zW1u-0003xK-00 for ; Mon, 22 Apr 2002 07:06:22 +0200 Original-Received: from fencepost.gnu.org ([199.232.76.164]) by quimby.gnus.org with esmtp (Exim 3.12 #1 (Debian)) id 16zW2S-0002UA-00 for ; Mon, 22 Apr 2002 07:06:56 +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 16zW1j-0007cY-00; Mon, 22 Apr 2002 01:06:11 -0400 Original-Received: from is.elta.co.il ([199.203.121.2]) by fencepost.gnu.org with esmtp (Exim 3.34 #1 (Debian)) id 16zVzF-0007Ec-00 for ; Mon, 22 Apr 2002 01:03:38 -0400 Original-Received: from is (is [199.203.121.2]) by is.elta.co.il (8.9.3/8.8.8) with SMTP id JAA11641; Mon, 22 Apr 2002 09:02:10 +0300 (IDT) X-Sender: eliz@is Original-To: Terje Bless In-Reply-To: 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:2975 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:2975 On Sun, 21 Apr 2002, Terje Bless wrote: > >>>Pressing `C-x b ' gives you a "completions" buffer > >> > >>And *poof* you've just thrown me into a new world; "Mommy this is > >>_confusing_! My window just split in two and half my text is hidden. > > > >How is this different from a dialog that pops up and obscures part of > >the display? > > All things being equal, it wouldn't be. Not by much anyway. > > But in this there is the matter of what people are used to and expect. In a > graphical editor, popping up a dialog is the normal way to handle this. I think you overestimate the power of old habits and underestimate the ability of people to learn new ones. The completions buffer popping up might surprise someone the first time they see it (although Bash and tcsh users are probably used to that already), but in my experience (observing people who converted from Visual Studio etc.) it doesn't take more than a couple of times to get used to it. > A > dialog also has some advantage that the split screen approach does not > have; chiefly that of following a stratageme of direct manipulation. You > don't have to weasel out what keys you can press to achieve something. All > the options that you need are avilable as clearly labelled text fields or > buttons. I hope you are aware that the completions popped up by Emacs are clickable. Move your mouse pointer across the completions and observe the magic. > I allready do want to use more of them, and to use those I allready use > more efficiently. But I have made a concious choice that the price of > admission is too high. I make do with what I have because I'm not willing > to pay the price of admission to get the rest of the features. I think you overestimate the price. The price of using the Emacs manual as a reference, via the `i' command, is normally quite low. (The abnormal cases usually constitute docs bugs.) I suggest to try that, perhaps you will find it easier than you thought. > Trust me, when the the pain outweighs the price, I will learn. I'm just > suggesting that one way to achieve your stated goal of bringing XEmacs to a > wider audience is by lowering the price of admission. That's everobody's goal, I believe. Specific examples and requests will help bring us closer to it. > Ok. I'll try to come up with some specific suggestions and post them to > xemacs-beta. Thank you! > I haven't allredy done so because I'm not sufficiently > familiar with XEmacs to be able to differentiate well between what is > feasible and what isn't, what is worthwhile and what isn't. Don't worry about that; just tell what you find unclear, unobvious, cumbersome, etc. > What I might be > able to provide is examples of what /I/ find difficult -- and sometimes > suggestions for ways it could be made easier -- and then leave the real > work (the thinking about ways to solve it and the implementation) up to the > developers. Perfect! Please do. > And please accept my apologies for not doing that any better... I don't see anything you should be apologizing for.