Re: Great SWT Program

On Sep 26, 9:15 am, blm...@xxxxxxxxxxxxx <blm...@xxxxxxxxxxxxx> wrote:
Sure. My point was that the behavior I find annoying -- silently
making changes that aren't backwards compatible -- seems to be more
common with the new-style than the old-style tools.

I'd object to such behavior too, but it's an issue that's obviously
orthogonal to whether or not a program has a decent user interface.

I think I was imagining that with a single-user system, every
version of an application might have its own config.ini file (same
name for all), but each could be stored in a folder specific to
the application version, together with the executable, or some
such, and that this might be slightly more difficult to manage
with per-user files because of the identical filenames -- not
impossible, no, just a bit more trouble and hence perhaps not
done as often.

It's easy -- the application just creates an "/appname/version/"
directory under the user's home directory to put its settings stuff
in. Any fool can code this functionality if they can code all the rest
of an application that is complex enough to need it. I can practically
see the code for this in my head. :P

Really? This is the first I've heard of any unix app even knowing that
there is such a thing as a function key.

When was the last time you used a Unix/Unix-like system?

On a PC a few years ago with some distro or another installed on it.
Nothing designed for the console (rather than for X/KDE/Gnome/
whatever; the box had KDE) seemed to know that anything but the
printable characters, space, enter, shift, ctrl, alt, and backspace
existed. A few also knew the arrow keys existed. None seemed to
recognize pageup, pagedown, home, end, Fn, or delete.

What evidence would you find believable? I could hardly be
mistaken about this -- I mean, I did some experiments before
writing the above paragraph -- so are you saying I'm lying?

Frankly I don't know what is going on here, but as I understood it, vi
didn't support so much as the arrow keys -- it expected you to
navigate using h, j, k, and l. Yes, four keys that not only aren't the
arrows, but are not even arranged in a cross, but rather in a straight
line! Of course, there's also the problem that this overloads the
meanings of four of the letters you might want to type into a
document...which leads to the crufty mode thing, of course...

Why would I do that, when it would be so easy for you to refute the
claim with a simple experiment?

Well, actually, it's not, since I don't have ready access to a *nix
box for the time being.

In other words, don't worry about keeping the existing user base
happy; force them to adapt to what the majority does.

If we're talking a few nostalgia buffs vs. everyone else in the world,
then hell yes! Except it's moot anyway -- there are perfectly good,
"normal" text editors for KDE/Gnome nowadays so with any luck nobody
will ever be forced to use vile (or emacs) again. This is rather like
how we no longer have dungeons and corporal punishment and arbitrary
arrests and convictions without trials in the West (modulo Bush and
cronies' misbehavior with supposed "terror suspects" of course), but
there remains a thriving BDSM community.

In case it's not clear, I'm not trying to argue that everyone
should use the same tools I do; I'm saying that there is a place
for tools that appeal only to a minority.

Even if it's a baffling kink. BDSM at least has a certain
sociobiological logic to it. Emacs and vi ... that's like getting off
on being bound with your eyes taped open and forced to watch the most
terrible B-movies in history mixed with old reruns of /I Love Lucy/,
all of them remastered using a kaleidoscopic filter and colorized by
the "catastrophic containment failure in a paint factory" method,
while your feet are tickled and your ears are subjected to electric
shocks. Give me a plain old whips-and-chains experience over that
*anyday*. :P

I'm not aware of a WYSIWYG word processor with LaTeX-style logical
structure. Seems there's demand for such a thing though. Automatic
behaviors should all be turnable-offable someplace.

Or better yet, they should default to "off" and be turn-on-able.
My opinion, though.

No problem there.

I think my point is that somehow a "point and click" interface
obscures that (1) is needed. In my opinion, anyway.

Not intrinsically. And sometimes the technical expertise needed is an
artifact of a layer lower down. Should the user care about the details
of how data is transmitted to the printer, for example? No, and proper
print driver configuration doesn't require it; it tries to autodetect
the right protocol for the particular printer that is in use.

Your "window dressing" apparently includes my "useful functionality
required to qualify the application as a 'real text editor'".

AFAICT from what you wrote elsewhere, your "window dressing" includes
"useful functionality required to qualify the application as an IDE".
Or maybe you simply use "real text editor" as a synonym for IDE; I
dunno.

Well, the old-style Unix model is that everything is stored in
text files, and you use a single editor to work with all of them,
rather than having to learn a new editor to work with each new
type of file.

Cute. Of course, thinking more moves ahead leads inevitably to:
* For each type of file there's specialized features that would
be useful.
* Hence the editor gets bloated with various modes and features
* Hence you get a single feeping creature that is full of
everything but the kitchen sink.
* And you STILL have to learn a new editor to work with each
new type of file. You just invoke it differently, and they
are all part of the same gargantuan executable instead of
having separate ones. Worse, their documentation is all
part of the same gargantuan help file, which makes getting
help for one of them orders of magnitude worse than if they
were kept decently separate.

AFAICT the motivation for all of this was, ironically, lack of
standardization: if separate IDEs, configurators, etc. all used the
same key bindings for basic editing commands, nobody would object
since the only things needing learning for each one separately would
be the domain-specific features that would all have to be learned
anyway. The lack of CUA on the other hand meant each one would
inevitably have its own idiosyncratic bindings for basic navigation
and cut/copy/paste and what-have-you as well, though (hjkl?!) and as a
result people would want to use just one and stick with it -- and then
cram all the IDE and other functionality into the one. And a feeping
creature is born!

In a sense, Windows users do have a "kitchen sink" editor of a sort --
in a sense, every editor whose basic text manipulating functionality
and navigation works the same is a specialized mode of a system
editor. But the modes are not exposed to the user nor any
complications arising therefrom, and each has separate documentation.
Indeed, the comctl32.dll textarea control is this "system editor" and
provides hooks for the embedding application to add extra
functionality, though some roll their own for extra flexibility, while
sticking to CUA so that the user doesn't notice or care. All the cruft
stops hanging out and becomes an implementation detail users can
safely ignore. Now THAT is a standard system-wide editor!

Applications that need to do text editing from
within the application call the user's editor of choice. I think
it's still a model that makes sense, though maybe it's not for
everyone, and perhaps some applications need more interaction
with the editor than is possible with this model.

See above.

Say what? the text editor isn't trying to be a command processor
here; it's giving me access to the rest of the system without
the need for cutting and pasting between windows.

That's it exactly -- in this case, what you really want is a command
processor with better interactivity/editing functionality, not an
editor with auto-paste-from-shell functionality. What you're
ultimately doing there is shell stuff, with fancier editing than the
shitty shell-prompt line-editor allows. Which suggests a command
processor with better editing functionality rather than an editor with
command launching and output redirecting functionality. Kludges like
this indicate the need to redesign the system in question from the
ground up.

Here's an example: I'm writing a document and want to include
the result of doing some simple calculation. I can express
the calculation in the form expected by a text-mode calculator,
pipe it into the calculator program, and get the result back in
my document. Of course there are other ways to accomplish this
involving cutting and pasting, but they strike me as somewhat
more trouble, if easier to learn.

What's really needed here is a better calculator -- or maybe a better
text editor, or something. What exactly are you editing or doing here?
Perhaps the application for that shouldn't be a bare-bones text editor
at all but a specialized one with OLE-like features to embed
calculated values and other stuff. A cross between Word and Excel, in
a sense. Or even a general "embedding and linking based document"
editor in which you can embed text paragraphs, inline math results,
images and other media, and so forth and invoke specialized sub-
editors for each, with more of them pluggable as desired. Microsoft
tried something like this a time or two in their office suite and
failed miserably, but it can probably be done right. Just not by
Microsoft. :)

AFAICT, you're really looking for an IDE, not a plain old text editor,
here.

Well, no, because a lot of these are useful features no matter
what kind of text I'm editing (source code, mail message, newsgroup
post, etc.) -- maybe not syntax highlighting, but the other
ones.

I don't see how. When editing source code, an IDE that embeds or
drives an editor makes sense, rather than an editor that embeds an
IDE. When editing mail or news, a mail/news client that embeds or
drives an editor makes sense, rather than an editor that embeds a mail/
news client. And so forth. Each of the embedding applications can
bring domain-specific specializations: syntax highlighting and
language awareness here, address book functionality and spellchecking
there, and so forth, as well as connecting with the task's wider
context: the compiler and rest of the tool-chain here, NNTP/SMTP/POP
functionality, account management, and message browsing there, and so
forth.

This, by the way, is what you have, in effect, on Windows.

Think about which keys are needed? It's completely intuitive with,
say, Notepad; shift+navigation keys moves one endpoint of the
selection (the other being wherever you were when you first started
holding down shift).

Shift + navigation keys is intuitive?! In whose universe? Now,
that the key marked with a left arrow should move the cursor left
is semi-intuitive (though I think it does presuppose a notion
of cursor that total newbies might not have), but how would you
know that Shift does what you describe without reading about it
somewhere, or having someone show you? Once you've discovered it,
sure, it works in a lot of circumstances. But discovering it?

First of all, and this will seem strange to you since it's not
apparently the unix way, but: it's documented, and it's documented in
basic introductory tutorial documents rather than buried somewhere
around page 666 of a 917-page tome to boot.

Secondly, like the basic cursor-stuff it's so universal (except for
museum-piece apps from the dark ages that is) that you pick it up
early on and need never worry about it again. Hell, moving one end of
a selection is a form of navigation, but modified, so using a modifier
key together with the navigation keys to effect it just plain makes
sense, and furthermore extends naturally to whatever additional
navigation features you might devise. Selection-end-moving and
navigation are orthogonalized.

The latter are noninteractive tools.

So?

So the discussion was about user-interfaces. Noninteractive tools
lacking one is normal, which puts them beyond the scope of this
discussion except as functionality that could be embedded in something
that had an interface.

If you want an interactive tool, gnuplot. I'm pretty sure just
about everything I know about it was learned without a live tutor.
Now, if I didn't already have some familiarity with similar tools,
I might have had more trouble. But I do, just as Windows users
have familiarity with the conventions of *their* platform.

At least our platform *has* conventions. (For the user-interface. I
know unix has arcane conventions for command line argument syntaxes,
directory structure, and other things, none of which are 100%
intuitive or especially well-documented, but it clearly has none at
all for interactive UI!)

The old-style help systems (man and info pages) are admittedly
a weak point, better as reference documentation than tutorials.

Better as one-time pads than either, I'd expect. Well-nigh unusable
for their putative purpose due to the clumsy interface that makes
navigating them in a decent manner impossible, but chock-full of
entropy and ten to the quadrillion bits of it too!

Well, except that copies abound, so the entropy in them isn't very
secret. :P

Perhaps if it was possible to actually navigate them properly it would
not be so, but any attempt to do anything on Unix seems to involve man
this, page down (er, space) times sixty trillion, read some stuff,
exit, man that, page down some more, etc. etc.; one big hypertext
system with clickable links would be far more useful than anything
requiring actually exiting and rerunning the so-called help browser
six times just because you need to consult six different chapters of
the system's documentation! Of course the inability to have all of the
stuff you're referring to on the screen at the same time also puts a
crimp in things; even Windows help is broken there as you usually
can't spawn multiple browser instances. HTML files plus Firefox is
clean and simple to author and works great -- users can right-click
and "open in new tab" and keep tabs open to many different things at
once to facilitate quick reference during a task, and Firefox has a
search you can actually discover and use and that then actually
behaves in a reasonable fashion. (Windows Explorer's is slightly
broken, however. Since that's a file search, it should support
wildcards and the like. Indeed, searches for foo*bar and foo?bar work
more or less as expected, and just foo bar will find e.g. foo diddly
bar which foo*bar would also find and also bar diddly foo which
foo*bar wouldn't, but if you want to find only foo bar, with the bar
right after the foo, "foo bar" doesn't work -- it returns nothing!)

Should rename that to "pwned", since that's what you are if you are in
a constrained-width environment in this day and age. :P

Your monitor is infinitely wide? Cool. Where can I get one of those,
and a big enough room to keep it in?

It's all thanks to this nifty thing Xerox PARC invented back in the
late seventies called a "horizontal scrollbar". There's also the whole
"1280x1024 and a decently small font pitch allows ~200 characters per
line *without* scrolling" thing. That's 5/2 the character width of an
old terminal, in case you were wondering.

Now a decently modernized command prompt box would be quasi-graphical
and supply a prompt that actually collapsed with ellipses, e.g. C:\foo
\b...ker\mumble\f...cks\data17> with tooltip expansion of the
"berserker" and "fiddlesticks" in there. Coding this is left as an
exercise for the reader. :)

Another benefit of the GUI way -- information can be stuck in various
places about the screen to be referred to, without being in the main
task area, and there's room for a lot more of it besides. :)

One could put this in the top line of a text-mode application's display
as well.

Of course, that's costing you 1/24 of your screen real-estate instead
of around 1/100 of it in a GUI. :)

Okay with me. I don't insist that everyone use my preferred set
of tools, just that they leave me to use them in peace and not try
to explain to me how wrong-headed I'm being. The downside is that
I don't learn as well what most people's experience of computers
is like, which is limiting in its way -- though nice in other ways.

Eh -- well, using them in peace wouldn't draw attention on a newsgroup
automatically, unless people decide to poke around in the headers
looking for "User-Agent: trn" or the like just to pick a fight. AFAIK
that rarely happens and it's only people that choose to publicly
evangelize software with unusable UI that get it. ;)

And those that publicly blast GUI software, of course, which is the
same thing you're asking me not to do, but in reverse...

That's not my observation. See above. Hell, when "something goes
wrong" on Windows 90% of the time it's fixed with a reboot, or a
reinstall of the offending app, or both. When "something goes wrong"
on Unix 100% of the time it's fixed with voodoo, for which your local
witch-doctor will probably charge money. If you can even find one. :P

Not my experience.

You've obviously been lucky then. Or had some recourse beyond the
unusable documentation the systems tend to ship with. The four failure
scenarios I'm familiar with on unix are:
1. Something doesn't work, and the error message + documentation are
cryptic. It quickly becomes clear that fixing it requires learning
almost as much about the thing's internals as it took to code the
damn thing to begin with. Time to email the developers.
2. Something doesn't even compile, and you're no programmer, and even
if you are, you don't have time to learn all the specifics of this
particular program as if to hack and modify it; you have a job to
get done! It quickly becomes clear that fixing it requires you
email the developers.
3. Something doesn't work and as a result X won't run, which means no
GUI. You're stuck with a single "window" that can therefore only do
one thing at a time and old, crufty documentation whose browser UI
ranges from unusable through abysmal to non-existent. It quickly
becomes clear that you'll be spending the next six hours slogging
through poorly-organized documentation in poorly-organized UIs
trying to find the information needed to make X run again. You
give up and phone the local geek, since trying to configure and use
the console-mode mailer is like trying to shave in the dark with a
new, maximally-sharp blade and fading flashlight batteries during a
magnitude 6.5 tremor.
4. Something doesn't work and as a result the machine won't boot,
which means no access to the documentation that might help you fix
it at all. Of course there's also no such thing as safe mode. It
quickly becomes clear that you're hosed. Time to wipe and
reinstall.
Hope you had recent backups.

Of course, item 4 happens on Windoze too, but safe mode + system
restore or whatever will usually save your bacon. And my observations
have been that 4 almost never happens with NT/2K/XP, and actually
happens more often with Linux -- and a simple power failure can be
enough to cause it there. Either no boot, or a boot directly into grub
or fsck or something like that instead of anything that either
resembles a normal shell or has a user interface. Of course this means
the drive/filesystem is hosed, which means no documentation, which
means same conclusion as option 4. Maybe a guru can fix it from there,
without referencing the now-inaccessible-and-possibly-now-nonexistent
fsck documentation without which no normal human being can hope to
accomplish anything at a cryptic and mute fsck-repair-mode command
prompt.

With luck, they've now gotten it to the point that it no longer is
designed around the assumption that you're running your unix on a
mainframe in a major datacentre with a UPS, but that still leaves
categories 1 through 3...

Mainly those happen on Windows through boneheadedness or bugs in the
software. On Unix they also seem to happen from simply trying to set
up and use something in a non-fancy way, because setting something up
on Windows is pick-install-directory, select-options, click-install,
reboot whereas on Unix it is somewhere in between a) setting up an
entertainment center whose instruction pamphlet is the size of the
Encyclopedia Britannica and written in Swahili plus pictograms that
appear to be lifted from the Ming Dynasty edition of the Kama Sutra
and certainly bear more relation to this than to the components you
have arrayed before you and b) setting up a shiny new CANDU reactor
with the optional fuel reprocessing module and waste storage vault --
some assembly required, moon suit sold separately. (The instruction
manual for one of *those* fills a small library, or so I'm told.)

"cd" is an unusual combination, though, isn't it? (As it happens,
on the man page on my system, the third occurrence of "cd" was
the one that was most helpful.)

Lucky you. The third out of 54,252 occurrences being the right one is
a minor miracle, comparable to winning the $1000-$5000 level prizes in
your local lottery. :P

Search queries only a couple of letters long are well-nigh unusable.
So is any interface that depends on your using such to navigate.

Binary search is better? because that's what we're comparing here.

Hypertext is better, or something actually semantically aware so you
can tell it you're interested in the command "cd" and it will ignore
occurrences of the letter combination "cd" that refer to something
else.

Ctrl-F is somewhat intuitive. How is F3 intuitive?

It's not, but it makes up for it in being nigh-universal.

If you search for a common word, you get a trillion hits. If you
search for a rare word or a phrase, you get zero to a handful. The one
is simply useless; it's either a slightly faster or a slightly slower
page down, depending. The other requires you to know a fair amount
about the target already, likely only if you've already been there.

How is binary search better?

It probably isn't, in this case. If the only query you have to go on
is only a couple of letters long, you're fucked. Unless the help
system is semantically aware.

Ironically, in that case "man" *almost* got it right. It apparently
was set up so "man cd" went to the shell man page as "cd" is a shell
command. It dropped the ball when it didn't go to the specific section
of the shell man page that deals with the "cd" command, or to a
separate "cd" man page created because finding things in a single
monolithic linear file for every single shell built-in command will be
like finding a needle in a haystack.

All this means is that the help system in question is actually half-
baked instead of being *completely* uncooked.


Only in the specific case of someone doing the sort of thing you
describe. Requiring careful record-keeping and cataloguing by the
whole user-base strikes me as foolish and needlessly user-hostile.

Yeah, maybe. But at least it lets people who *do* want to have a
record do so, as opposed to point-and-click operations that leave
nothing recordable.

There's no obvious reason mouse gestures can't be recorded, though it
would be better to record the abstractions of the commands invoked
instead -- e.g. hit esc, or alt-C, or mouse1 over the "Cancel" button,
and in all three cases it just records that the command was "cancel".
And of course it would always be the case that the user could, when
recording a macro or whatever, choose to use only keyboard commands.
This is for macro recording and record-keeping of individual edits, of
course; for record-keeping of file versions, built-in versioning tools
in the editing tool seem sensible, and with a journaling filesystem
can just provide an interface to that underlying functionality,
focused onto a particular file. Failing this, the file's location can
be disclosed and the user can manually make copies and backups.

"Treat everything as a document for the user to edit" seems like it
might work here generally.

Yeah. And the person who doesn't mind remaining ignorant of better
ways to do things, and continuing to do manually things that could be
automated. (You do have a point. But I think I do too.)

Only when you *are* automating something should you need to invest a
load of time and effort into learning internals or whatever
complicated command language.

This doesn't sound much like my experience. Of course, I do things
like defining environment variables for directories I use a lot,
so navigation isn't as difficult as it might be -- $WEBDIR for
the directory where the files for my "Web site" live, for example,
so I type "cp file $WEBDIR" rather than giving the full path.

Seems like a kludge/crutch to me, patching over an intrinsically poor
UI with workarounds. Puts me in mind of working with a poor GUI where
a commonly used function lacks a keyboard shortcut so you either
always mouse it or use the shortcut for something nearby and then tab
to it. (Of course the something-nearby might actually be invoked by
doing so, as well, depending on what it is. If it's a text box you're
OK; if it's a command button...)

Still short on visual cues, but not, IMO, as bad as you're making
these systems out to be.

I dunno. Creating tons of invisible, undocumented aliases for
everything seems like a crutch and not a very good one at that. Even a
symlink from the root dir would be better; that will actually show up
in a directory listing. Environment variables lurk invisibly in what
passes for the command processor's brain somewhere; no amount of
dir'ing or ls'ing will reveal their existence, let alone what they
point to. You're creating more stuff for you to memorize in this case.
I wonder how cluttered your system is with environment variables you
set as shortcuts to something years ago and eventually forgot about?
How many shortcuts, all but one forgotten, to the same resource? Hmm.

Ultimately though it all comes back to the one fundamental problem and
that is the paucity of information and feedback to the user about the
current state of the system and the locations of nearby/related
things. If I found myself having to do all of my tasks by the narrow
cone of a flashlight beam I'd wonder why the power was out rather than
just live with that state of affairs.

So two of the three things are still technically separate with
Windows.

But the interesting question is whether you could replace one of
those pieces with something comparable -- or whether there even
*is* something comparable. Unix-y systems are apt to offer a
somewhat bewildering array of choices, and to allow mixing and
matching (possibly not arbitrarily so, though).

There's a tradeoff there -- does this get the user genuine added
flexibility or better features? And at what cost in complexity and
therefore undebuggability? Not to mention unsupportability. There are
that many more variables in play when a user complains of a problem or
tries to fix one himself. There's also that many more things whose
versions might get out of synch or something. How closely do they
stick to immutable, graven-in-stone interfaces regardless of
implementation? To the extent that they don't, changing one of them
can presumably bring the whole system crashing down and render it
fully unusable, save in command-prompt-only mode. So basically
unusable. :P

Not saying the old tools are always best, just that they provide
something that seems not to even be imagined by people who only
know GUIs. Something that somehow combined the best of both
worlds seems like a great idea, no? but it's not clear that it
will be invented by someone who doesn't know the benefits as well
as the drawbacks of the old tools.

I do know the benefits; they are simply inaccessible to non-expert
users, by and large.

But you claimed you could learn something useful and transfer the
knowledge to another application. That's impossible if they don't both
adhere to *some* standard, but rather each does everything in a
totally idiosyncratic way.

But they don't. What you learn from one application may not be
100% helpful in learning the next, but the odds are that it will
be more than 0% helpful, and I claim that for the kinds of things
we're talking about here, it will likely be a lot more than 0%.

Really? For example, what app 1 used for navigation that wasn't the
arrow keys -- if app 2 uses a completely non-overlapping set of keys
for this, how exactly does your learning finally how to get around
inside app 1 help you with app 2? It doesn't, and it might even
hinder, after a fashion, because you're now used to using the app 1
keys to navigate.

On the systems I've used (Linux, Solaris, earlier systems),
"man" finds the files, converts them to text, and pipes the
whole lot into your pager of choice (something akin to DOS's
"more" command, though possible more capable -- the one I use,
"less", is able to page ahead by arbitrary amounts, search for
text, etc.). I have no idea what tool you're talking about.
Could it be -- I think I remember an "xman" tool that ran under X?
maybe still does on some systems?

I'm referring to whatever pager or other displaying software presents
the file, along with what passes for something that might be a distant
ancestor of a true UI, to the user. :P

Now, the fact that some information is only available via the
"info" pages, and the "info" command has a different interface --
well, yeah, annoying.

"Annoying" doesn't begin to describe it. The one redeeming feature of
"info" is that it actually has hyperlinks. But how they managed to get
even *those* wrong I can't begin to imagine. Even the browser's back
button -- well, back keybinding -- doesn't even quite do the job. It
goes to some designated "parent" node, instead of the actual previous-
visited node, so it's impossible to properly backtrack. And of course
there's no "open in new tab" or equivalent either, so you can't get
out of the backtracking problem *that* way either, nor have more than
one thing open that you can quickly flip among without running
multiple instances and navigating separately and repetitively in each
in some embedding context with tabs or windows, e.g. using X terms in
X.

OK, there is another redeeming feature; it does seem to have been
designed by someone with enough sense to think that those little arrow
keys arranged in a cross would make for excellent and intuitive
navigation keys. That's not something you can take for granted over in
*nixland! Still, crufty wacky binary format + crufty half-assed
browser implementation = pain, and the parallel existence of HTML +
Lynx/firefox/whatever = no excuse. :)

There are text-mode browsers too, and in most of these tools,
trying keys such as "?" and "h" often provides some help that's
enough to get a person started.

When they don't just beep, produce unhelpful error messages, or
actually have unintended consequences. (And the unintended
consequences simply being the insertion of a ? or an h into the open
document is generally too much to hope for.)

A person that doesn't insist that
every new tool behave exactly like the ones he/she has used before,
anyway. (Not that I'm knocking consistency. Consistency is good.
It's just not the *only* good, and there can be trade-offs.)

I'd be satisfied, for now, if they simply started with not behaving
*entirely unlike* the ones I've used before. :P Baby steps, baby
steps. They can work on actually standardizing on the nearly-universal
basic navigation and editing command bindings later. Features that
have no counterparts in other applications I certainly won't expect to
"behave the same" in those ... that way lies madness, and everything
turning into an emacs clone - complete with kitchen sink. I won't have
it!

PostScript is being supplanted by PDF these days, as far as I
can tell. The ASCII-ness of PostScript is actually, in my opinion,
one of its attractions. You know why. :-)

It does have the ability to be zipped at least. PDF is proprietary and
evil, although at least you can usually find PDF renderers that don't
butcher the neatly typeset text into something resembling a turn-of-
the-century Nintendo game with blocky pixellated fonts. HTML plus
browser plus decent font is much more efficient and surely accessible
and readable than either, and once again uses an ASCII format. As an
extra added bonus feature, the same piece of help documentation that
takes up 80MB as a PS and 800KB as a PDF takes up 80KB as HTML, and a
lightweight browser is not significantly bigger for any of the three
formats than for any other. (For HTML this would mean a stripped-down
HTML browser lacking HTTP capability, used for local files only, and
lacking fancy CSS/JS/ActiveX/Java/etc. capabilities also -- HTML 4.2
only if you please, with inline images and the like working as
expected and most other binary file types besides images occurring in
links simply being launched with the native file associations in
appropriate viewer/editor software.)

.