Re: The minibuffer vs. Dialog Boxes (Re: Making XEmacs be more up-to-date)

[Terje Bless]

Eli Zaretskii <address@hidden> wrote:

>On Sun, 21 Apr 2002, Terje Bless wrote:
>
>>>>>Pressing `C-x b <tab>' 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?