Re: Great SWT Program

In article <1190961037.906718.180670@xxxxxxxxxxxxxxxxxxxxxxxxxxxx>,
<nebulous99@xxxxxxxxx> wrote:
On Sep 26, 9:15 am, blm...@xxxxxxxxxxxxx <blm...@xxxxxxxxxxxxx> wrote:

[ snip ]

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

I agree that it doesn't seem like rocket science. So why is it that
people who develop applications don't always do this?

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.

Strange. I just checked, and mutt (on a Fedora system, but
I'm fairly sure this behavior would be fairly cross-platform)
has been using F1 to bring up help at least since 2001, based on
some e-mail I exchanged with a colleague back then.

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.

That's true of the original vi, as far as I know. (I think even
there the arrow keys *sometimes* did something useful, but it was
dependent on terminal type, and one learned not to rely on it.)

Of course, no one here is discussing "real" vi; we've been talking
about vim, which is a different program that as far as I know isn't
an offshoot of the original vi except in emulating some aspects of
its user interface.

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

Touch typists seem to really like being able to do everything from
the, um, "old"? part of the keyboard.

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.

Fair enough. But I couldn't know that until you told me, so again,
why would I lie when in principle if not in fact .... Well, whatever.

[ snip ]

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 feel sure someone can accommodate you, if that's your preference.

(Perhaps the above rant is an example of the humor someone
mentioned finding in your posts. I'm not particularly amused,
but then perhaps that indicates a deficiency in my sense of humor.)

I'm not aware of a WYSIWYG word processor with LaTeX-style logical
structure. Seems there's demand for such a thing though.

LyX? I haven't investigated it myself, though, only heard it mentioned
as a graphical front end for LaTeX.

[ snip ]

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.

Syntax highlighting could be useful in writing lots of things other
than program source code -- HTML and LaTeX source come to mind, though
perhaps one could argue that they're forms of source code too.
Ability to interoperate with the environment, do search-and-replace
using regular expressions, record and play back macros -- those seem
more significant, I think.

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.

Well, as far as I know vim and emacs both package this kind of
functionality in separate plugin-like files, which one could
install or not, so to me this doesn't quite seem like bloat.
But I could be confused, both about how vim works and about
what constitutes bloat.

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

Well, I just checked, and the executable for vim is about 2M,
and the one for emacs is about 4M. That seems modest compared to
current memory sizes. What to compare it to and how to compare --
I dunno. I thought it might be interesting to look at executable
sizes for some GUI programs, but the ones I've looked at so far
(OpenOffice and Eclipse) seem to be packaged in some way other than
"single executable" that I'm not sure how to assess. <shrug>
Maybe vim and emacs *are* bloated.

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.

Well, no. The basic editing keys are the same, and all of that
extra stuff (interoperability with the environment) is the same.

As for that gargantuan help file -- well, no. Actually that
might be better than how vim help is organized -- it's another
sort-of-hyperlinked system that's fairly navigable as a tutorial,
not so much as a searchable reference.

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!

Which is really kind of the Unix model -- a single text editor
called by all applications -- except that with the Unix model you
have a choice of editors. Which might or might not be regarded
as good.

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.

I'm not sure we're talking about the same thing here; I'm not
talking about using a text editor to do things I'd do in the
shell if it were more featureful. I'm talking about being able to
take parts of the text I'm editing and process them with outside
utilities, and get the results back into the file being edited.

An example would be using the "fmt" command to reflow text
into a paragraph of a specified width. Sure, the editor could
include that, and I think vim (as opposed to vi) actually does,
but it doesn't need to, when it's relatively easy to invoke the
external command to do it. *Less* feature bloat for the editor
that way, no? I think at one point automatic indentation and
reformatting of code also used an external program. Some of this
stuff is migrating into vim as far as I can tell, and I suspect
that's so vim will work on platforms that don't necessarily have
all those little external programs. (Windows, for example.)

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?

I'm not sure I can come up with an example here. Here's one
that's a bit contrived:

I'm writing something that talks about integer data types and
want to include the maximum and minimum values. Those are easy
enough to compute, and if I can do it with a text-mode calculator,
I can do that from within the editor. The alternative would seem
to me to be to bring up a separate calculator, operate it as usual,
and then cut-and-paste the results into the text file.

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

I almost think I could make a case for the notion that that's
exactly what those antique editors give you, but in the context
of text files only, and it *does* work. Of course the "text files
only" limitation is significant.

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.

It's also what you have with those old-style Unix programs: mutt
(for reading mail) and trn (for reading news) both call the user's
specified text editor for, well, text editing. I'm not thinking
now of other applications where another tool needs to interact
with a text editor closely. The tools I know about in that
environment for compiling are command-line tools rather than
anything like an IDE.

Now, emacs. emacs is a little different. But we agreed not to go
there, I think, and I strongly suspect that what looks like feature
bloat is actually a very featureful set of plugins. Maybe that's
the same thing, though.

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.

*WHICH YOU HAVE TO READ*. Hence not "completely intuitive". That
was my point. Agreed that once you pick it, it's broadly useful.

[ snip ]

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!

For suitable definitions of "navigating them in a decent manner",
I suppose.

[ snip ]

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 [ snip ]

Agreed. I guess the point I'd make here is that there are more
choices than just "best imaginable help interface" and "totally
unusable help interface" -- it's a spectrum, and we probably
disagree about where on that spectrum typical Unix help lies.

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

Oh, you're one of *THOSE* .... :-) I like my fonts fairly big.

But just on a quick check, I had no trouble getting a GNOME
terminal window that fills the screen and allows 200-character
lines without wrapping. How do I know it's 200 characters?
I have vim configured to show row/column position of the cursor at
the bottom. (I did have to peer closely at the monitor to read
the position. As I said, I prefer bigger fonts. But someone
with a different preference could be accommodated.)

allows ~200 characters per
line *without* scrolling" thing. That's 5/2 the character width of an
old terminal, in case you were wondering.

Which is largely irrelevant given that most of the applications we've
been talking about seem perfectly happy to make use of a bigger
"screen" if one is provided by the terminal emulator.

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

Tooltips, ack pfui. (I can understand the point, but they're
something of a pet peeve of mine. Something about that "hover
the mouse and wait" thing bugs me.)

[ snip ]

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

I don't understand why you keep talking as if text-mode applications
were still restricted to 80x24.

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

My perception is that I'm not evangelizing this software so much
as defending it from someone who appears to be poking fun based
on limited knowledge. As best I can tell from a quick skim of
saved posts, we got into this wrangle when you mentioned CharMap,
I said "I use vim", you suggested I should get with the times,
since console-mode applications would not and could not provide
decent support for Unicode, someone replied that in fact vim
provides support for Unicode, and we were off ....

I suppose defending one's preferred tools *is* in some way sillier
than defending the reputation of a supposedly anonymous ID.
<shrug>

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

Well, I think I've been fairly careful to mention from time to
time that I can perceive some benefits to GUIs, and to say that
some of my dislike of them is personal taste or based on my own
experience. Maybe that does count as "publicly blasting" them.
<shrug>

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.

Some luck, maybe. Access to a local expert to help, usually.
That does make a difference. I would claim that some Windows
problems are also solvable only with access to a local expert.

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.

Most of the times I've run into either of these, it's been with
very old and unsupported stuff I'm stubbornly trying to keep
alive, or with "research software" for which expectations are,
and should be, a little lower.

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.

Unless, of course, you already know how to use "the" console-mode
mailer. Oh wait, there are several (pine, mutt, elm, mailx .... ).

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.

Time to get out the rescue CD and boot from it. It may even come
as part of the distribution -- I think when I burned a copy of
the installation disks for my current system, they included one.
Also, as I understand it, there are "live CD" distributions where
the whole thing is on a bootable CD.

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.

Again, not much like my experience. Waiting for a full filesystem
check after an abrupt shutdown used to be quite annoying, but with
the availibility of journalling filesystems it's not the issue it
used to be.

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

I think ease of installation is an area in which some distributions
have made major advances in the past few years. I haven't really
experimented, but I hear good things about Ubuntu. Anyone else
still reading this thread may have another favorite to mention.
Problems are still very possible, but I don't know how much better
Windows would do if one had to install it from scratch.

But ....

I think a lot of what one finds annoying is conditioned by what
one is used to. I'm happy to overlook Unix's faults, but quick
to become annoyed with Windows's shortcomings. I know that.
I suspect for you it's the other way around, though it's only
a guess.

"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

Oh, get real. There aren't going to be 50K occurrences of an
unusual string such as "cd" in a document that's, hm, the one I
have access to here is about 4700 lines, and appears to contain
18 occurrences of "cd". Someone who knows the tools will also
be able to separate out mentions of the function from words
such as "anecdote" too, by searching for "cd" as a whole word.
Admittedly syntax for doing that isn't obvious. But it's there.

[ snip ]

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.

Make that 80% and I might even agree. :-)?

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.

All of this seems possible. But do you know of any programs that
actually do it? I don't. The "archiving text files" approach is a
pain, but at least it can be done without modifying the applications.

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

Wasn't that what I was saying .... :-) (Well, not exactly, I know.)

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.

In a perfect world, yes. If I have to choose between something
that makes easy things difficult to learn, and something that
doesn't allow automation at all, well, I'm glad to have the choice.
If I didn't have to choose, if there were something that made easy
things easy but also allowed automation, that would be better.
But does it exist?

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.

In some ways it is. I'm kind of stubborn about using CLIs for things
where most people would use a graphical file browser. Again, I'm
glad to have the choice.

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.

"printenv" lists them.

You're creating more stuff for you to memorize in this case.

Like I "memorize" the route from my residence to my office.

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.

Not as much as you seem to think -- I count 17 of those environment
variables pointing to directories. I *had* forgotten about a few
of them, but -- 17. <shrug> As for having many shortcuts to the
same resource -- why not? It's not as if symbolic links take
up a lot of space (I wouldn't think -- it's just a path name),
and if I ever do want to look at not-much-used stuff again, it
seems useful to retain the shortcuts to relevant shared resources.
I think on the whole my files are probably less cluttered than
the average person's. Admittedly I could probably do a lot better
if I knew how to make good use of version-control software.

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.

Yeah. I think there really may be a "different styles of thinking"
thing going on here.

[ snip ]

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.

Not saying *you* don't -- though given that you seem unfamiliar with
current versions of Unix tools, I don't know -- but that most people
don't. Don't you agree about the "best of both worlds" thing being
desirable?

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.

This is a problem, but in practice most applications adhere to one
of a smallish number of standards. The situation is not wonderful,
but I don't think it's as bad as you make it out to be. Some of
the commonality comes as a result of applications using library
code for command-line editing; there's a readline() function used
by bash and probably many tools that involve getting a line of
text at a time, and it provides a lot of stuff I find useful, such
as maintaining a (searchable) command history.

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

So again it appears that what you're critiquing is not the tool's
actual capabilities, but the ones that are apparent to the novice.
I don't know, maybe that *is* fair. I just claim that there are
also things about Windows that are equally unobvious to newbies
but taken for granted by experienced users. Maybe there are fewer
of them. <shrug>

[ snip ]

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

Perhaps because this system pre-dates the Web, browsers, etc.?
though I'm not sure about that.

[ snip ]

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.

That wasn't the attraction I meant.

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

Yeah, yeah, we probably sort of agree here, though I'm glad to
have a format (PDF) that's suitable for documents where you *do*
want to control the formatting and for which readers exist for
many/most/? popular platforms.

--
B. L. Massingill
ObDisclaimer: I don't speak for my employers; they return the favor.
.