From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Hrvoje Niksic Newsgroups: gmane.emacs.devel Subject: Re: The minibuffer vs. Dialog Boxes (Re: Making XEmacs be more up-to-date) Date: Sun, 21 Apr 2002 03:45:25 +0200 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 1019353703 22938 127.0.0.1 (21 Apr 2002 01:48:23 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Sun, 21 Apr 2002 01:48:23 +0000 (UTC) Cc: Eli Zaretskii , jas@extundo.com, bradym@balestra.org, xemacs-design@xemacs.org, emacs-devel@gnu.org Return-path: Original-Received: from quimby.gnus.org ([80.91.224.244]) by main.gmane.org with esmtp (Exim 3.33 #1 (Debian)) id 16z6Sl-0005xr-00 for ; Sun, 21 Apr 2002 03:48:23 +0200 Original-Received: from fencepost.gnu.org ([199.232.76.164]) by quimby.gnus.org with esmtp (Exim 3.12 #1 (Debian)) id 16z6Sk-0006Rm-00 for ; Sun, 21 Apr 2002 03:48:23 +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 16z6SY-0000Is-00; Sat, 20 Apr 2002 21:48:10 -0400 Original-Received: from dragon.arsdigita.de ([212.84.246.66] helo=florida.arsdigita.de) by fencepost.gnu.org with esmtp (Exim 3.34 #1 (Debian)) id 16z6QT-0000HA-00 for ; Sat, 20 Apr 2002 21:46:01 -0400 Original-Received: from hniksic by florida.arsdigita.de with local (Exim 3.35 #1 (Debian)) id 16z6Pt-0000Pw-00; Sun, 21 Apr 2002 03:45:25 +0200 Original-To: Terje Bless X-Attribution: Hrvoje X-Face: &{dT~)Pu6V<0y?>3p$;@vh\`C7xB~A0T-J%Og)J,@-1%q6Q+, gs<-9M#&`I8cJp2b1{vPE|~+JE+gx;a7%BG{}nY^ehK1"q#rG O,Rn1A_Cy%t]V=Brv7h (Terje Bless's message of "Sun, 21 Apr 2002 02:56:05 +0200") Original-Lines: 88 User-Agent: Gnus/5.090006 (Oort Gnus v0.06) XEmacs/21.4 (Common Lisp, i686-pc-linux) 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:2895 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:2895 Terje Bless writes: > Actually, it's slightly worse. I use > > '(buffers-menu-submenus-for-groups-p t) > > (I have no idea what this feature is /really/ called) So do I. Except I don't use the menus, I just like how they look. :-) > and the "Switch to Buffer" command in the buffer sub-menu lists no keyboard > shortcut. I'm not sure what you mean by "the buffer sub-menu", but in the menubar, the "Buffers" menu contains a "Go to buffer..." item which is marked with `C-x b' -- and that's how you switch buffers using keyboard. > 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. De gustibus... In my case, "much typing" is tempered by the fact that you have completion, probably the best UI invention pushed by Unix-like systems. Especially Emacs's completion feature, which tightly connects keyboard and mouse. Pressing `C-x b ' gives you a "completions" buffer and three choices: * Insert text, using TAB for further completion. Enter chooses a reasonable default -- last used buffer. (I use this method.) * Press PgUp to get to the "completions" buffer, and navigate it using the cursor keys. Notice how the cursor keys move by items rather than by characters. Also notice how pressing RET does The Right Thing. * Find the wanted selection and click with button2 to choose it. If that's not full-featured, I don't know what is. I've never felt the need for any of the "advanced" buffer switchers, and I was appalled whenever I tried one of them. > 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; I'm afraid I don't remember our previous discussions, but I can certainly see your point here. What I don't understand is why you keep using XEmacs. Although Emacs is a decent editor, I'm sure there are ones as good, but without the "burden" of Lisp and programmability. > So to improve the "manual" for /me/ you'd have to remove every > reference to lisp from it. I don't think the XEmacs manual makes all that many references to Lisp. Have you actually read it? Of course, by "manual" I don't mean the Lispref, but the actual XEmacs Reference Manual. To take another example, look at my description of `C-x C-b ' above. How much Lisp did I use? > 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. I see your point, I really do, but I don't have a good idea how to fill this gap. I think the tools like `M-x edmacro' (have you tried it? -- `M-x edit-kbd-macro') are a good first step because they make it easy to translate keystrokes and the "editing" stuff you see into the Lisp stuff underneath. Then it's not hard to mess with the Lisp stuff without having to have a deep understanding about it. `M-x customize' is another example of the same, but fails to deliver for similar reasons -- still too complex and "hard". We have a long way to go, and I'm not sure Emacs will ever fit the bill here. Part of the problem is that, once you overcome the barrier, you are no longer part of the target group, and you even begin to *like* the way Emacs does things. It seems like a tar pit, but I can't sympathize with that view and be entirely honest -- I've been assimilated.