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

[Serge Wroclawski <serge@tux.org>]

On Sat, 20 Apr 2002, Terje Bless wrote:

> I've been using XEmacs for programming since the early nineties. I _still_
> have no clue how to switch between buffers from the keyboard! I keep going
> to the Buffers menu and selecting the one I want. In my "other editor" --
> BBEdit on Mac OS X; solidly planted in GUI land -- I /can/ switch between
> buffers from the keyboard.

> Odd that, considering how "keyboard-oriented" XEmacs is, and how "GUI
> oriented" BBEdit is...
>
>
> And speaking of which, the thing that confused me most over the years was
> the terminology. A "buffer" is a "document" and a "frame" is a "window"?
> Why do I have to choose "New Frame" when what I /really/ want is a new
> window? And I don't work with "buffers"; I work with "files" or
> "documents". "Buffers" are something hardware /has/ or that I implement in
> code, it's not something I work with day-to-day.

This issue, while flamable is not entirely bad.

I think a main issue which both the Emacsen have tried to deal with is how
to map the older Emacs terminology onto the common terminology of today.

Buffer is a bad term only becuase it relates to little for the user. Is a
buffer a document? A peice of text? A "window of text".

But it pales in comparison to issues like yank, kill, faces and so on.

Emacs, had it been designed more recently, would have both been aided and
limited by the ideas that permiate today (some which of course some from
editors like Emacs).

The issue is that people see these issues as very important. They want to
think that a yank is not a paste, , a kill is not a cut and a window is
not a frame (and so on). It's mostly true, but thinking that such issues
don't make for a easy use for the new user.

The advantage of GUI Emacsen is that they've covered these issues up by
hiding them. In some cases, they completely hide the issues by replacing
the terms.

If I could make one magic wish for Emacs, it would be that it would
integrate with the Bonobos or similar type functionality of GNOME, that
is, wouldn't it be nice if I could have an Emacs buffer as part of other
applications or that Emacs buffers could "pretend" to be other things more
simply than they can now.

A few examples:

A user wants a terminal emulator. It's possible they'll use the shell
mode. But maybe they like the way the application handles a few things
more than Emacs does and for some good reasons, the Emacs should not do
that (for instance menu placement, language, tabbing).

But there's no reason I can see that the program couldn't call up a way to
access an Emacs buffer and have the Emacs buffer do the hard work.

That is what I see is the biggest thing Emacs needs. Instead of focusing
it efforts on an appealing UI, it needs to make a way for other
applications to work with it, accessing the powerful conceptual aspects of
Emacs while not being as limited by UI decisions which often have no
choice in how they're made.

- Serge Wroclawski