From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Serge Wroclawski Newsgroups: gmane.emacs.devel Subject: Re: The minibuffer vs. Dialog Boxes (Re: Making XEmacs be more up-to-date) Date: Sat, 20 Apr 2002 10:12:50 -0400 (EDT) Sender: emacs-devel-admin@gnu.org Message-ID: References: NNTP-Posting-Host: localhost.gmane.org Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Trace: main.gmane.org 1019312144 11938 127.0.0.1 (20 Apr 2002 14:15:44 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Sat, 20 Apr 2002 14:15:44 +0000 (UTC) Cc: , Return-path: Original-Received: from quimby.gnus.org ([80.91.224.244]) by main.gmane.org with esmtp (Exim 3.33 #1 (Debian)) id 16yveS-00036R-00 for ; Sat, 20 Apr 2002 16:15:44 +0200 Original-Received: from fencepost.gnu.org ([199.232.76.164]) by quimby.gnus.org with esmtp (Exim 3.12 #1 (Debian)) id 16yvyK-0007qW-00 for ; Sat, 20 Apr 2002 16:36:16 +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 16yve0-0002IW-00; Sat, 20 Apr 2002 10:15:16 -0400 Original-Received: from gwyn.tux.org ([207.96.122.8]) by fencepost.gnu.org with esmtp (Exim 3.34 #1 (Debian)) id 16yvbk-00026y-00 for ; Sat, 20 Apr 2002 10:12:56 -0400 Original-Received: from localhost (serge@localhost) by gwyn.tux.org (8.9.3/8.9.1) with ESMTP id KAA06166; Sat, 20 Apr 2002 10:12:50 -0400 Original-To: Terje Bless In-Reply-To: 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:2842 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:2842 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