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

[Terje Bless <link@pobox.com>]

Eli Zaretskii <eliz@is.elta.co.il> wrote:

>>Date: Sun, 21 Apr 2002 17:11:36 +0200 From: Terje Bless
>><link@pobox.com>
>>
>>>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. 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.

But that's beside the point in this case. The dialog that pops up which I
gave as an example in a different message was as a front end for the search
and replace functions. Switching between buffers can be done either with a
dialog providing a list (but which variant C-x C-b handles well enough), or
by switching sequentially, or by any number of other variants. Nobody
suggested using one of these terrible newfangled dialog thingies for this!


>>I don't need all the power of XEmacs, only a small subset of it, and
>>becoming an expert to use the small subset is a bad tradeoff; too steep
>>a price.
>
>If you refuse to learn, how do you know that you only need a small
>subset of the features?  Perhaps if you learned more you'd want to use
>more of them?

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.

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. The alternative is to
make everyone rich enough to be able to afford it, and frankly I don't see
that as being very realistic!


>>Very very few of the things I want to do with XEmacs should require me
>>to actually read the manual. They're simple things, why can't they be
>>simple to do?
>
>Examples, please!  It is not useful to write slogans to which everyone
>agrees without specific examples.  What are those ``simple things'' that
>cannot be done in a simple way?

Ok. I'll try to come up with some specific suggestions and post them to
xemacs-beta. 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. 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.

I've deliberately avoided getting into specifics because quite frankly I'm
not _qualified_ to speak to them. The only people that are really qualified
to do that are the developers and very advanced users. I'm just trying to
provide general input for them to take into account when designing and
implementing XEmacs.


And please accept my apologies for not doing that any better...