From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Terje Bless Newsgroups: gmane.emacs.devel Subject: Re: The minibuffer vs. Dialog Boxes (Re: Making XEmacs be more up-to-date) Date: Sun, 21 Apr 2002 17:11:36 +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=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Trace: main.gmane.org 1019407367 1839 127.0.0.1 (21 Apr 2002 16:42:47 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Sun, 21 Apr 2002 16:42:47 +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 16zKQJ-0000TY-00 for ; Sun, 21 Apr 2002 18:42:47 +0200 Original-Received: from fencepost.gnu.org ([199.232.76.164]) by quimby.gnus.org with esmtp (Exim 3.12 #1 (Debian)) id 16zKQb-0002f5-00 for ; Sun, 21 Apr 2002 18:43:05 +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 16zKQ2-0000wE-00; Sun, 21 Apr 2002 12:42:30 -0400 Original-Received: from mail.wavelan.no ([217.144.228.111] helo=isa) by fencepost.gnu.org with esmtp (Exim 3.34 #1 (Debian)) id 16zKOS-0000mr-00 for ; Sun, 21 Apr 2002 12:40:52 -0400 Original-Received: from [217.144.228.69] by isa (ArGoSoft Mail Server Pro for WinNT/2000/XP, Version 1.8 (1.8.1.1)); Sun, 21 Apr 2002 18:43:23 +0200 Original-To: Hrvoje Niksic X-Priority: 3 In-Reply-To: X-Mailer: Mailsmith Prerelease (Blindsider) 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:2945 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:2945 Hrvoje Niksic wrote: >Terje Bless writes: > >>Actually, it's slightly worse. I use >> >>'(buffers-menu-submenus-for-groups-p t) >[...] >>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. I'm struggling with the limits of my Emacs vocabulary here, but I have the Buffers menu set up to group buffers by type (that "mode" rather, probably, no?) and to give each group of buffers their own sub menu. And I've switched on the sub-menu for each buffer menu that gives you commands like "Switch to Buffer" and "Switch to Buffer, Other Frame" etc. The only command listed with a keyboard shortcut in my XEmacs is the "List All Buffers" command. >>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, Well, certainly (to both). I just prefer to cycle sequentially through buffers until I hit the right one. Anyways, my point was that I hadn't yet figured out how to do it rather than complain of the lack. Or put another way, either I don't learn well or XEmacs doesn't teach well. Take your pick! :-) >probably the best UI invention pushed by Unix-like systems. Yes, without question! :-) >Pressing `C-x b ' 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. I don't know what to do!" You're giving me too many options. You're making me think too much, forcing me to make choices I don't care about. >If that's not full-featured, I don't know what is. Yes, exactly! It's not only full featured, it's _too_ full featured. >>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, [...] It was a couple of years back during a discussion of the pros and cons of adding the ability for XEmacs to natively use Perl as an extension language in addition to Lisp. The last time I was experiencing opinions... :-) We were talking of how you can view XEmacs in two distinct ways: as a mere text editor; or as a Lisp interpreter with an exceptionally rich library, some of which is uniquely suited to implement a text editor... >>From the text editor view, the ability to write extensions in a nother language can be nothing but good, but from the Lisp interpeter view, adding Perl into the mix can only dilute the value of it's core strengths (IMO, of course). But lets not get into /that/ discussion here. :-) >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. Probably for the very same reasons you use XEmacs. It's powerfull, it has killer features, it's extensible, and no matter what you want to do, XEmacs can probably do it. Mostly though, it can be summed up in one word: "cperl-mode". After trying about a million different editors, the only one that does Perl half way decently is XEmacs. Nobody else even comes close (IMO, YMMV, etc.). Don't get me wrong, all my bellyaching isn't to suggest XEmacs is a bad terrible editor. It's just that I think it could be even better. >>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.=20 >Have you actually read it? Of course, by "manual" I don't mean the >Lispref, but the actual XEmacs Reference Manual. Yes, I read it. A long time ago, but... The Lisp reference was just an example (possibly not a very good one). The XEmacs User's Manual is a big huge weigthy tome of knowledge. The New Users Guide is much better. Both do define the term "Buffer" and it's relationship to "Files" and "Windows". And anything you want to do you can probably figure out from these manuals. But then, since it has source avilable and a license that allows it, I could have figured it out from reading the source, given enough time, too. My point isn't XEmacs=B4 inability to perform some task (really, it's _Xemacs_ we're talking about here! Is there anything it /can't/ do? ;D) or a lack of documentation. It's the accessability of it's features for less-then-expert users. The reason I don't know more about it is because I'm refusing to learn; because the cost is too high. 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. 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? My "other editor" allows me to work in the subset of functionality I'm comfortable with while still keeping the more advanced features available. It will gradually disclose more of it's secrets as you become more familiar with it. That doesn't mean it's interface changes; it just means it doesn't throw the advanced features up as barriers that you need to pass before you can use the simple functions. Keyboard equivalents are available, but not necessary. They are provided in the menus for every command that has one, and in dialog buttons when the buttons have one. In the latter case, the keyboard equivalents only become available when you press the Mac OS standard "Command" key (more or less equivalent to Ctrl on UN*X and Alt on `doze, I think) and after a short delay. They don't get in your way by default, but when you start to get comfortable and begin to explore they show up to provide you with a path to ever more advanced features. The search dialog pops up when you use the search command and lets you set various search options. You can then press the Find button or the Find Next button. It has options for searching multiple files on disk, with filter criteria to include or exclude various files. It lets you turn on or off regex searching etc and it provides both the search function and the replace function. The menus also contain commands to short-circuit the dialog, so when you get tired of having that dialog in your face for each search, you can get rid of it run the entire thing from the keyboard. But you're not required to do so! You don't have to remember keyboard shortcuts until you're so comfortable with them that it becomes easier for you, individually, to use the keyboard instead. In Xemacs I get thrown to the mini-buffer. A concept that's rather unique to Emacs so no prior experience has prepared me for it. I have no frame of reference to tell me how it works. It prompts with "I-search:". It tells me nothing about what options are available to me at this point. It doesn't tell me what it's doing, it offers no command keys and certainly no pretty buttons to press. Pressing C-g (which someone once said worked kinda like Ctrl-C or ESC in the rest of the world) doesn't bounce me out of it. It returns me (apparently) to the last prefix that matched anything. "How the hell do I get rid of this confusing thing that prevents me from working with my file? It just keeps beeping at me!". Using the "Replace" command works similarly. I manage until I've entered the string to search for and the replacement string, but then what? Ok, it sez to "f1 for help". Now there's a split window obscuring half of my file. How do I get rid of that? And it doesn't offer options to "Yes, replace" or "No, don't replace". It offers a huge array of keyboard shortcuts talking about lotsa stuff I don't understand. What's "recursive edit"? What exactly does "clear frame, redisplay, and offer same replacement again" do? (Really, I couldn't figure this one out by experimenting!). Oh and why doesn't it find any matches when I know the string is in there? Oh that's right, it searches from point to EOF so I apparently have to scroll to BOT before running the search... Compare e.g. the search dialog in this screenshot . For various reasons it doesn't do incremental search, but the general point still stands. Putting a similar GUI on the search and replace functions makes that feature accessible to non-expert users; and can be done without impacting the experts that can work much faster using the mini-buffer. But I'm not expert enough in human interaction design to really be comfortable making this specific suggestions. I try to be vague on the specifics intentionally for this reason. It's not that I have all the answers for how to make XEmacs the perfect editor; I'm just trying to argue that focusing on these issues -- instead of saying "Oh no, that would jeopardize the power-user features and dumb down XEmacs" -- will lead to a better editor for everyone involved. >>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') I dunno. What's it do? Where would I have found out about it's existence? How do I work it? "M-x edmacro" just sez "no match" and "M-x edit-kbd-macro" apparently expects me to know how it works before I try to use it. It asks me for a keyboard macro to edit. I don't have any keyboard macros do I? I never tried "Start Macro Recording". What's "C-x e, M-x, C-h 1, or keys" mean? >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. I don't think it's hopeless. I _do_ like how XEmacs does things. It's just that it's such a royal PITA to actually __figure_out__ how it does things. All programmers face the problem that they know down to the last paren how their program actually implements a given feature, but that doesn't mean it's impossible for them to try to make th efeature more easy to use for those that don't know it that intimately. For non-free software developers this is pretty much a rock hard necessity because they can't tell users to read the source; they've hidden it away and locked it up. If they can pull it off, I'm damned sure y'all can too! --=20 > ...publicity rights, moral rights, and rights against unfair competition.= . Well, you've got me there. I have no idea what any of those have to do wi= th SGML. Next you'll be claiming that running NSGMLS constitutes an unauthoriz= ed public performance of SGML. -- Richard Tob= in