The Modernization of Emacs: terminology buffer and keybinding

[Twisted]

On Jun 23, 2:04 am, Robert Uhl <eadmun... at NOSPAMgmail.com> wrote:
> Of course, emacs doesn't take years of mastery.  It takes 30, 40
> minutes.

I gave it twice that, and it failed to grow on me in that amount of
time.

> > Besides, ANY interface that involves fumbling around in the dark
> > trying to find a light switch is clunky.
>
> That sounds like vi, not emacs.

That sounds like any application where you need to read the help, but
"f1" does not bring up a separate help window, switchable with the
main one using alt-tab or the mouse, and navigable using arrows,
pageup, pagedn, and the mouse. The result of that is invariably that
when the document has the focus, the help is open to "help on
switching windows" rather than whatever you need it to be on once the
document has the focus. You can read the help on doing what you want
to do with the document, but to apply it you need to transfer focus
back to the document. If doing that isn't second-nature, you have to
navigate the help away from where you need it to get the focus back to
the document. Now the focus is on the document, but the help you need
isn't displayed next to it anymore. Frustrating? You can't begin to
imagine, I suspect. Apparently, some people are born somehow able to
avoid this problem without having to memorize one or the other piece
of help. You're clearly one of those. I am equally clearly NOT one of
those. Of course, if emacs let you keep THREE windows open and visible
at the same time, instead of being limited to one or a horizontally
split two ... and a cramped 80x10 or so each, at that ...

> > 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

I'll admit that it didn't USED TO 'eschew normal methods of
navigation', but at a certain point in time there began to be 'normal
methods of navigation' and emacs naturally began eschewing them
promptly and has done so ever since.

> 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

If I haven't, it must be the case that finding this tutorial (or even
discovering that it exists) was nontrivial, or it wasn't built into
emacs, one or the other. My memory is somewhat fuzzy after all these
years so you'll forgive me if I don't make a definite statement about
which. On the flip side, if I have, the tutorial can't have been all
it's cracked up to be. Especially given I can program Java
proficiently, including some fairly sophisticated network-using tools,
and clearly am not an idiot or untalented in technically demanding
areas involving substantial amounts of arcana. Of course, I might have
put more effort into learning effective Java; effort like that in
learning some language is necessary to being a programmer. Thanks to
modern editors and IDEs, putting a comparable amount into learning the
mere mechanics of operating a text editor is not necessary, and I
chose to spend the time and effort elsewhere, where it was necessary,
such as on learning a programming language.

The technical term for managing limited resources, such as time and
effort, first where needed and never where avoidable, is "efficiency",
in case you were unaware.

> > 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

Impossible

> you've never actually used emacs

Untrue

> or you're just making things up.

Also untrue, and you've just accused me of incompetence once and of
lying twice, which in a formerly civil discussion constitutes behavior
that I consider to be in poor taste.

> 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.

Apparently because you find the switch second nature, despite its not
being the obvious (which is ctrl-tab, to switch between documents in
an MDI app). Cheat sheet? Memorized with painstaking months of hard
effort? Thanks for proving my point, either way.

> In fact, I am not aware of any package which auto-changes the *info* or
> *Help* buffers to reflect the last keyboard command.

I didn't say it auto-changes. It manual-changes. The exact sequence of
events that causes this with a novice user being:
* Need to do X, and the usual command doesn't work (e.g. go to save
document and get search prompt)
* Now nothing much works (typing stuff bleeps), hit esc a bunch of
times
* Now it complains of hitting esc too many times, but typing into the
document at least works again
* OK, time to resort to *gulp* the help.
* Oh, great, now what did it do? I hit F1 and ...
* Eh. Try random stuff. Help starts with h. Alt-h? Ctrl-h? ...
* Oh, right. I seem to remember the help popping up unwanted when I
tried to backspace over a typo earlier, so I'll just do that.
* Hrm, now how to search the bloody thing?
* <Hours pass, some spent trying ctrl+f and ctrl+s, mostly
fruitlessly, followed by a load of scrolling>
* Ah. "How to do Foobar to your open document". Perfect!
* Oh crap. How do I do anything to my open document, when the focus is
on the help instead of the document?
* <Scrolling for ten minutes>
* Ah, I hit this. It worked!
* Oh, fudge. Where did "How to do Foobar to your open document" go?
The help's open to "How to switch windows". For shame.
* Switch back, scroll ... there it is.
* Crap, now I don't remember how to put the focus back on the document
window.
* More scrolling.
* Oh, fudge. Where did "How to do Foobar to your open document" go?
The help's open to "How to switch windows". For shame.
* <however many repetitions of the preceding 4 lines>
* Error: Stack overflow. Dumping core.

I trust you get the picture.

[snip]

Whoa, what did you just say? Page 899 of the ... good Christ. Er ...
Run! Flee! It's a monster! Head for the hills! Sound the civil defense
sirens, tornado TORNADO! *runs*

> > 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

What are you blithering about? Oh, great, now I'm using the term
"blithering". :P But ...

WHAT menu bar? We're discussing emacs. As in, a text-mode editor. As
in a cramped little 80x24 grid of letters, numbers, spaces, and
punctuation with no menus, no concept of a pointing device, and a bad
attitude.

Actually, the big thing the GUI and mouse did was rescue us from
escalating UI problems with tasks complex enough to require modes. You
needed either separate components with separate associated
functionality and a "focus" to move among them, or you needed commands
and keyboard-toggled modes. The former got you an emacs and the "can't
switch back from the help" syndrome, and the latter got you ...
something vile.

Until the GUI-with-pointing device, which made user control of a
"focus" a snap requiring virtually zero learning curve, and better
yet, what little learning there was being transferred readily across
applications. Unified windowing systems, with Macs and Windows,
cemented the victory of the pointing device over the problem of focus
management. Point at the thing you want to use next and click; that
simple. A child can do it. Using a GUI is like doing a job yourself,
such as washing the car. Using something from the dinosaur age,
especially afterwards, feels like sitting back and directing some
hired help. Help that happens to be blind as a bat as well as having
the usual poor grasp of English. "Left, Senor. Right, Senor. No not
THAT far right! Now you've gotten it all into the open drivers-side
window, and those documents I left on the front seat are ruined!"
Ouch. Yet trying to control old text-mode tools is pretty much exactly
the same, only the flawless English it speaks belies an even dodgier
grasp of same, or even the need to speak to it in some obscure dialect
of Greek full of "meta" instead...and it doesn't apologize when
there's a screwup a more hands-on interface would easily have
prevented.

If you want a job right, do it yourself. With a mouse, you can; no
need to speak an obscure variant of Swahili into a keyboard just to
get the focus to the document from the help or wherever. And to top it
off, every Windows app understands tab and alt-tab and most understand
ctrl-tab. Actually, the OS GUI components themselves understand alt-
tab, and the applications just get told the focus went elsewhere or
came back, making it one less area for application designers to screw
things up. (All too often, they screw up ctrl-tab in tabbed/MDI apps,
or screw up tab by using a dodgy tab order or controls with no visual
indication of focus, mind. And then you can just resort to the mouse,
rather than throw up your hands or find something non-electronic to
sob into so as to avoid ruining another $40 keyboard.)

> 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.

It's an "operating system" to precisely the extent Windows 3.1 was.
It's like Windows 3.1 in a number of other ways too, including size
and aesthetics, though not stability. Even more like its predecessor
DOSShell.

Take that however you wish.

At least Windows 3.1 had most apps have the same keys for the vast
majority of commands, and those were the right keys. Emacs has all the
applications have the vast majority of their commands use the same
WRONG keys. Including whatever you'd use to rebind them. And the help
you'd use to find out what the damn keys are in the first place. ;)

And let's not forget that to someone with a 17" LCD monitor and a
blisteringly fast graphics card, 80x24 text in a terminal emulator is
somewhat underwhelming, and doesn't provide anything like the
information density needed to make truly complex software interfaces
usable. The human optic nerves have about 100Mbps of bandwidth *each*;
that's a couple of ethernet cables directly into the cortex. Even a
large, high resolution, big-color-gamut display with a decent refresh
rate doesn't use more than a fraction of that capacity to deliver
information to the user, even when the display is used to maximum
advantage by the software to provide state information and navigation
cues (and document views!).

Those dim old greenly-glowing 80x24 terminals flickering at 20-odd Hz,
by contrast ... barely adequate to design their own replacements on,
though necessary for same. It's a good thing some people are
apparently very good at maintaining most of the state information in
their head that that tiny little box of text isn't displaying to them,
and "reading between the lines" to make use of even fairly complex
applications through such a tiny interface. Or those replacements
might never have been built.

> 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.

I'm not sure that's such an advantage. Sometimes, unifying tasks too
much creates security holes, especially when some of those tasks are
network-facing and some are not. Some proposed or actual Windows
features result in an unclear boundary between "my computer" and "the
net out there", and that's bound to result in leaked passwords and
credit-card numbers and all manner of other accidental breaches, as
well as enable a variety of new social engineering attacks to
purposely compromise more of the same. Phishing and similar attacks
already pose a problem, but if the "phishing" looks like it's local
applications or content instead of online, it's even more likely to be
mistakenly trusted.

One sometimes wonders if Microsoft has more sinister motives than "get
rich with as shoddy and cheap a product as possible" in light of
things like this. I do hope the unified stuff you describe in emacs
isn't the open source equivalent. There's frank danger in making it
too easy to mix up local stuff and online stuff while at work at a
computer.

> 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?

Define "we". It can't be "people", because a substantial fraction of
people use computers heavily for image or even 3D manipulation, or
sound, rather than text, or a mixture with text not predominant, and a
much larger fraction use computers for absolutely nothing at all.

"Programmers" maybe. Even so, some people program from time to time
but do a lot of, say, image manipulation.

I expect even most programmers like to be able to see what the heck
they're doing, rather than resorting to fumbling around with a
flashlight or grunting terse instructions to a blind butler with an IQ
in the mid-zeros.

> 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?

Search is usually ctrl+f, type something, hit enter in my experience.
And I can use any text editor I want to edit HTML.

> 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).

That looks like three commands, although I can't be sure -- my Swahili
is a little rusty from years of disuse. ;)

I'd normally use at least eight -- open, save, quit, find/find next,
replace, cut, copy, and paste. That's not counting arrows, page up,
page down, del, backspace, and the like, and unixy tools don't let you
take even THOSE for granted. And if I needed more, add help. Add the
four arrows, page up, page down, delete-forwards, backspace, and help
to the original eight and we now have 17 commands. I seriously doubt
that your short chunk of Swahili up above encompasses all of them.

> 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.

What are you talking about? Clearly not emacs, which is a console app
for unix systems (with the inevitable MS-DOS ports and others). Some
sort of bastardized Windows port I suppose? I've seen the occasional
attempt at a Windows port of a unix tool, and the results are fairly
uniformly awful. Everything looks mostly right, and nothing works
quite right. They're often actually more unstable than native Windows
apps, probably because the porters don't know half as many of the
landmines littering the windoze APIs as real Windows application
programmers do (and *they* only know maybe half of the total, to judge
by the stability of even higher-quality Windows apps) and because they
are bolting on a thin layer of Windows widgets onto a core that works
in ways fundamentally alien to those same APIs. No real Windows app
dares to try spawning around 700 threads to service a request to copy
two lines of text to the clipboard, for example. :)