The Modernization of Emacs: terminology buffer and keybinding

[Robert Uhl]

Twisted <twisted0n3 at gmail.com> writes:
>
> How clunky versus usable an interface to a tool is is for those who
> invest some, but not extraordinary amounts of, time into its use to
> decide. If it requires years of mastery, it is clunky -- period. This
> may be unavoidable if it's something involved in nuclear power plants,
> delicate neurosurgery, or whatever. If it's a text editor, on the
> other hand, it's clearly going to have superior competition in the
> area of usability.

Of course, emacs doesn't take years of mastery.  It takes 30, 40
minutes.  And a functioning intellect, of course.

Incidentally, a violin requires years of mastery, and is hardly cranky.
Granted, there are few people with the talent to play a violin well.
Maybe an automobile is a better example...

> Besides, ANY interface that involves fumbling around in the dark
> trying to find a light switch is clunky.

That sounds like vi, not emacs.

> Applications that not only eschew normal methods of navigation of the
> interface, but force you to fumble your way between the help and the
> task you're trying to do, are definitely clunky.

a) emacs doesn't 'eschew normal methods of navigation'; it's been doing
   its own thing since before there _were_ Mac OS or Windows

b) I believe you've never used the emacs tutorial, which is quite
   definitely designed for you _not_ to have to fumble around between
   windows

> The interface never improved over that time -- the biggest problem
> consistently being that whenever focus was successfully transferred to
> the document window, the help window was invariably open to the
> instructions for switching windows, so you could never be doing
> something with the document and have the help for that something
> available at a glance.

That doesn't even make sense.  Either your memory is faulty, you've
never actually used emacs (something I'm beginning to suspect more and
more) or you're just making things up.  If I'm browsing the manual
online, I can switch from said manual to my document buffer without
making the manual scroll to the documentation for switch-to-buffer.  In
fact, I am not aware of any package which auto-changes the *info* or
*Help* buffers to reflect the last keyboard command.

> Even though it would be at the price of no full- text search
> capability -- not that I could ever get that to work in emacs
> anyway. There was no apparent way to do a simple substring search and
> click "next match" or "previous match" to navigate among the
> hits...more arcane keypresses would be required, and as soon as it
> showed you the first match inside the help, the keypress documentation
> of course vanished.

Dude, you hit C-s; you're prompted for a search string; you hit C-s to
search for the next match.  From line 899 of the tutorial:

>> Now type C-s to start a search.  SLOWLY, one letter at a time,
   type the word 'cursor', pausing after you type each
   character to notice what happens to the cursor.
   Now you have searched for "cursor", once.
>> Type C-s again, to search for the next occurrence of "cursor".

If you had actually, you know, actually _read_ it this would not be a
surprise.  I hate to be rude, but I just don't see how you could ever
have actually done what you claim to have done.

> Infrequently used commands you can stand to hunt for in menus. When
> you find you use one frequently, you can try to learn the keyboard
> shortcut -- and you can find it without even consulting the help,
> simply by finding the command's menu item.

This is no different from emacs.  There's a menu bar; it displays
commands and shortcuts next to them; one can learn to use them instead,
at one's own pace.

> Every time you want to use the command but can't remember the shortcut
> you just find it in the menu and activate it from there, and see the
> shortcut while you're at it, helping to eventually memorize it. And
> the commonest sorts of File and Edit menu items have near-universal
> shortcuts, the big variation tending to be whether Redo is
> shift-ctrl-Z, ctrl-Y, nonexistent, or menu-only.

You've actually hit on another advantage of emacs: consider emacs itself
as an operating system hosting multiple applications, in which the vast
majority of commands are the same.  I can use the same text-editing
commands for reading & writing emails, reading & writing Usenet posts,
reading & writing code, browsing the web, organising my schedule and so
forth.

The vast majority of what we do on a computer is reading & writing
text--wouldn't it be cool to have a full-fledged text editing
environment always available for that sort of thing?  Wouldn't it be
cool not to have one program implement search in one way, and another a
second way, and yet another a third?  Wouldn't it be cool to have access
to a proper text editor when editing text on a web page?

> But you can start using it right away with low productivity, and
> increase your productivity with proficiency and learning (optional)
> shortcuts, chiefly those to the commands you happen to use a lot.

That's how I learnt emacs.  I was 13, and had only ever used Mac
software up until that point.  I had a fairly limited command set
(basically, C-x C-f, C-x  C-s & C-x C-c).

> One person elsewhere in this thread even went so far as to suggest
> that to avoid having a similar hurdle with every application you just
> use emacs for everything. If you like being claustrophobically trapped
> in 80x24x8BPP instead of 1280x1024x32BPP, that may be your cup of tea.

Do you realise that emacs has a GUI these days?  I'm writing this in a
70-line window, with gtk+ widgets.  Which means full-resolution,
full-colour.

-- 
Robert Uhl <http://public.xdi.org/=ruhl>
A wealthy man is one who earns $100 a year more than his wife's sister's
husband.                                                  --H.L. Mencken