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

[Terje Bless]

Hrvoje Niksic <address@hidden> wrote:

>Eli Zaretskii <address@hidden> 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´. 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! :-)