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: Wed, 24 Apr 2002 02:08:10 +0200 Sender: emacs-devel-admin@gnu.org Message-ID: NNTP-Posting-Host: localhost.gmane.org Mime-Version: 1.0 Content-Type: text/plain; Charset=US-ASCII Content-Transfer-Encoding: 7bit X-Trace: main.gmane.org 1019607209 15792 127.0.0.1 (24 Apr 2002 00:13:29 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Wed, 24 Apr 2002 00:13:29 +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 170APY-00046b-00 for ; Wed, 24 Apr 2002 02:13:28 +0200 Original-Received: from fencepost.gnu.org ([199.232.76.164]) by quimby.gnus.org with esmtp (Exim 3.12 #1 (Debian)) id 170AQx-00024R-00 for ; Wed, 24 Apr 2002 02:14:55 +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 170AOS-0005Lo-00; Tue, 23 Apr 2002 20:12:20 -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 170AMh-0005Eg-00 for ; Tue, 23 Apr 2002 20:10:31 -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)); Wed, 24 Apr 2002 02:12:53 +0200 Original-To: Eli Zaretskii X-Priority: 3 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:3147 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:3147 Eli Zaretskii wrote: >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. Perhaps I just overestimate my own ability to adapt compared to the average user (arrogance was ever my vice, I'm afraid). I've adapted fairly well to this way of doing things. Let me try to be more specific. 1. The split view is somewhat overloaded; it's used for both the function that dialogs hold in other environments and for regular split-view. 2. The expected meaning of buttons is "wrong" here; button2 is Select and not Paste as it is everywhere else. Button1 does nothing, but everywhere else it means Select. Button3 gives you unrelated options. This is possibly the most confusing combination of behaviour for mouse buttons that can be chosen in the context. And it's absolutely unique to XEmacs. 3. A dialog can be dismissed if you enter it by mistake. Just click Cancel or hit ESC. Here, ESC does nothing, there is no Cancel button, and the "magic incantation" C-g may need to be pressed one or two times depending on what to me appears as arbitrary criteria (they're not of course, but I haven't figured out what they are yet); assuming you even know about C-g. But even in light of this, I'm not necessarily suggesting the use of a dialog for this. The dialog suggestion I made was specifically as an alternate interface to the various search and replace commands. The completions buffer has some problems from my point of view, but I'm not sure what can be done to remedy them, or indeed if they warrant "fixing" at all. >>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. Despite the dialogs, I tend to run my other editor entirely from the keyboard. In the Xemacs conmpletions buffer there is no hint of how to do this (see below). I'm sure you can switch from the minibuffer to the completions buffer from the keyboard, but I don't know how (see below). Trying the methods that are familiar from other environments -- and so have taken on the status of trained reflexes by now -- do not work. And the look of the buffer doesn't hint at how it could be manipulated. Once there I can move around fairly well and guessing that Return activates seems to be right. But only when I begin to study this buffer in composing this reply do I notice that there is some text up there. Aha, I can use M-v to move there. Why M-v? What possible heuristic could it have? Could it be because TAB is already taken for minibuffer completion that it isn't used? TAB is what's used everywhere else for switching between panes and text fields. And the completions buffer doesn't look like a control; it looks like text. You don't expect to be able to manipulate it as a control. Data should be kept distinct from controls because you manipulate them in different ways. And the buffers listing crams a lot into a single screenfull, but it doesn't make it easy to select from the list. You need to consider too many columns in what appears to be a bastardized semi-alphabetical order. Maybe this is a fair tradeoff of power over simplicity. I know it's more confusing then convenient for me, your MMV. >>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. Perhaps. What "i" command? "C-h i"? That gives me 340 lines of mostly incomprehensible text. The first 60 of which we should probably shoot Red Hat for leaving as "[No description avilable]". The remaining lines giving me what appears to be the info pages for the GNU utils. The plain "i" does nothing, though I see it's supposed to be bound to... Hmmm... That's funny.. I could have sworn... Oh great! These keybindings change depending on what buffer I'm in?