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

[Terje Bless]

Hrvoje Niksic <address@hidden> wrote:

>Terje Bless <address@hidden> 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 <tab>' 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. 
>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´ 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
<URL:http://www.barebones.com/images/aqua_find_dialog.gif>.

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!




-- 
> ...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 with
SGML. Next you'll be claiming that running NSGMLS constitutes an unauthorized
public performance of SGML.                                  -- Richard Tobin