Re: Great SWT Program

On Oct 3, 8:48 am, blm...@xxxxxxxxxxxxx <blm...@xxxxxxxxxxxxx> wrote:
I agree that it doesn't seem like rocket science. So why is it that
people who develop applications don't always do this?

Why do all kinds of bad design decisions get made? Who knows? :P

Some of them I attribute to insufficient imagination, or
insufficiently broad horizons.

I hope you aren't slyly implying that I might be guilty of this in
pooh-poohing the "see if you can find your way around my software
blindfolded" style of interaction design? :)

I can't easily say how other applications behaved in 2001.
What I can say is that a lot of the text-mode tools I now use do
respond to keys outside the old-style keyboard (page up/down,
function keys, etc.). trn is an exception, but it hasn't been
updated in a long time.

Probably two good reasons to get rid of it. (Abnormal navigation
controls, and no longer maintained, makes two.)

Yes, well, they are a rather odd lot aren't they? Chording and modes
seem to appeal to them more than actually being able to see WTF the
thing will do.

Right. Whereas looking at the keyboard rather than at the screen
makes so much more sense?

Well, glancing at it from time to time, certainly. It costs less time
than backspacing and retyping due to frequent typos, which is what
happens when you type blind! Actually I only infrequently glance at
the keyboard, even when intermittently using the numpad, arrow keys,
delete, etc. and even the mouse, myself. Mostly I have a good motor
memory for where the keys are, and having the keyboard in my bottom
peripheral vision suffices when that's not enough by itself.

There's also the quality vs. quantity matter. Typing 3000 words per
minute is overrated -- if all you want is to dump data into a
computer, making it digital in the first place or else using a scanner
and OCR is much faster. (OCR does necessitate running a spell checker
afterward, and then proofreading and manually correcting the few
remaining typos. Still faster than typing it all in manually for
sizable wads of old documents on dead tree media.) When actually
composing something new, taking the time to actually think and
consider as you go is beneficial. Particularly when entering code, but
also when entering prose.

There seems to be a lot of that going around lately. Perhaps a vitamin
that's usually missing from modern convenience foods?

I'm pretty sure that whatever might be wrong with "modern convenience
foods" doesn't explain any deficiencies in my sense of humor.

Chemicals then. Hormone-mimicking compounds or something like that.
Since so many are afflicted these days and there's at least one
documented cluster (cljp) I have to wonder about the possibility of an
environmental cause.

Really, though, LaTeX itself is stretched thin over the limitations of
the underlying TeX macro-processor. It *tries* to be a descriptive
document language but the nature of the underlying system leaks
through in various crufty ways, particularly in obscure and broken
behaviors that result from side effects. Between that and LaTeX3 being
vaporware it's probably time someone replaced it completely with
something designed from the ground up to achieve LaTeX's stated goals.

Yeah, maybe. Pitching out something that works pretty well
(though admittedly isn't very novice-friendly) and in which
some people have a significant investment of time and trouble
and existing documents -- well, whatever. I guess it's good to
imagine what an ideal tool would be like.

Who said anything about pitching out LaTeX? The existence of legacy
documents using it would ensure that it outlives the next Y2K-like
crisis, nevermind the next few years, even if a superior alternative
comes into widespread use for authoring *new* documents. :P

Now *that* would be nice (the two-views idea). I vaguely remember
being shown, many many years ago, a drawing program that presented
a similar interface, though it allowed making changes in the
preview/WYSIWYG pane as well. I thought then that it seemed like
a great idea, and I still think so, but as far as I can tell the
idea didn't catch on.

I'm not sure how useful it would be with drawing software. With 3D
software, obviously (in fact the most usable for me tends to use a
four-way split with a 3D view and side, plan, and elevation 2D views).
For word processing/HTML/etc. where you edit markup rather than just
text, it seems *damn* useful.

I think we're still not communicating, because I don't get how
a better shell would help. And current Unix shells seem pretty
good to me .... Well, not that that's likely to be significant
in this discussion. :-)

I'm thinking if you're doing shell type stuff in the editor, it may
mean a shell with a better editor than the usual prompt line-editor
would be more useful than a text editor with some awkward way to
invoke external stuff. For other things, where you're mainly text
editing but using external tools to generate or use some of what
you're inserting, a windowed GUI with copy-paste is easier, and a
specialist editor (such as an IDE) sounds ideal (depending on what
exactly you're doing that consumes or produces text for you).

Okay, here's a short example: I'm composing e-mail in vim,
called from mutt, and I want to attach to the message all the
LaTeX source files in the current directory. ":r!ls *tex" gets
the list of files into the message-plus-headers; inserting
"Attach: " in front of each file name (easily accomplished [*])
means that when I exit vim mutt will use those files as
attachments.

Eh. This seems rather awkward and involved, complete with typing
arcane commands and hand-editing potentially dozens of lines of
directory listing.

Thunderbird (on any OS) equivalent: Attach menu item, file browser
pops up, locate directory containing tex files, enter "*.tex" in the
"file type" part of the dialog (or just as the filename and hit
enter), then select all. And bam, they're attached.

Other GUI mailers similarly. Often the file dialog will remember where
you had it last for that use, so if there's a directory you often
attach files from, you won't even need to navigate the directory tree
nine times in ten.

OTOH, your example above will obviously only allow you to attach files
from whatever directory was current when you launched mutt. That means
you need to anticipate that in your mail session you might receive a
message that prompts a reply including particular tex files, and cd to
that directory before launching mutt just in case. If you find some
message that prompts a reply including files from somewhere else, now
you have to exit mutt, cd to another directory, and run mutt again.

Particularly, one issue with non-GUI tools is the frequent requirement
to exit and do something, then re-enter -- what a colossal pain! All
because of the "current directory" concept of the shell being a mode
inherited by whatever you launch, instead of using the notion of a
file chooser UI that can be used to navigate the whole filesystem and
pick files, where it isn't simply bad design *cough*man*cough*

[*] Maybe by inserting the text on one line and then using "."
to repeat the insertion command on subsequent lines. Or there
are other ways, none of which involve typing "Attach:" more than
once.

Obvious to novices? No. But useful.

Whereas any random Windows user newly presented with a copy of
Thunderbird will have zero difficulty attaching a group of files
painlessly -- from *any* directory. Or even from *multiple*
directories; your mutt procedure seems to not permit *that* at all!
That means, in practise, that you'll be moving everything you might
ever want to attach to an e-mail into an "attach from here" directory
you cd to to launch mutt rather than keeping them in more logical
places according to their normal purpose, because otherwise you need
to keep "mutt"ing from various directories and sometimes even having
to send two emails instead of one to send two files just because they
happened to be in different directories. How silly!

I suppose you'll now tell me there's a way for mutt (or vi) to be told
to change directory, but if there is, it's by no means obvious.
(Changing directories in a dependent shell process won't change it for
the parent process, so executing a "cd" in a sub-shell spawned from
the editor will be of no use. So simply using your "run external
command" arcane key combination to run "cd" the way you did to run
"ls" won't do the job.)

For searching, maybe regular expressions *are* overrated, though
when I added them to my mental toolkit a few years ago, I did
find that there were some things that became easier. A lot of the
uses, though, are search-and-replace rather than just search, and
macro recording is sometimes easier for that too.

Search and replace with a fairly predictable substring query is
dangerous enough. Search and replace with a regexp is just *begging*
to have the target mangled in unforeseen ways due to unexpected
matches or even an unexpected interpretation of the query code by the
computer.

Could be. Of course, starting that 4M executable in an appropriate
environment brings up something GUI-ish, and the GUI code must live
somewhere ....

GUI code isn't inherently enormous; my Swing-using Java code produces
class files no bigger than Swing-eschewing console app code*, all else
being equal. Of course if the library is statically linked you can
expect serious bloat. That's why they invented .so (and .dll).

* Which would be either personal-use or noninteractive. I wouldn't
inflict a console mode interface like vi's on my worst enemy. ;)

That's not what I was talking about; I was talking about the
basic editing keys being the same whatever kind of file you were
editing.

That's just as true on Windows, and as an extra added bonus feature it
remains true whatever app you're editing it in! :) (Aside from the
niggling alt-E-F versus alt-S-F for search dichotomy; no problem since
ctrl+F works anyway.)

I've often thought it would be nice if an OS provided a framework of
interfaces and default implementations for things like file dialogs,
text boxes, and suchlike, but allowed third-party implementations, and
provided a way to set the system default, as well as overrides for
particular applications if so desired. Of course there'd have to be a
basic GUI tool to set and modify these that worked independently of
them, in case things got gummed up and you had to fix it.

I was agreeing with you right up to that last sentence. :-)

Why? The need for a "rescue tool" that won't be taken down by the very
problem it's supposed to help you fix seems obvious to me...

No, I'm not talking about somehow linking to sources of information
that will change over time; I'm talking about getting stuff that
should become part of the file being worked on.

Well if it just needs to be static text, surely copy and paste is
faster and more controllable than :r!ls ... or whatever? Not to
mention easier, more intuitive, and so forth. And you can select what
you want from the other thing's output -- if it is a 500MB log file
and you want one entry in the middle you can select, copy, and paste
just that entry instead of pasting in the whole log file and then
having to delete reams and reams of crap from around the bit you want
-- which you have to find again first! (OK, rather extreme, but I
trust you get the picture. I'll bet there's some clever noninteractive
way to use sed, awk, and the like to pare down the more output to just
the entry of interest too; I don't wanna hear it. That's like
performing brain surgery blindfolded and will probably on the first
attempt just paste in the 499MB that is everything in the file
*except* the interesting entry or something. :P)

The previously-described scenario involving
generating a list of attachments is an example. The message
is going to be composed and sent; I don't need for it to embed
some reference to a list of files that might change.

In this case it should just embed a copy of the files. For that we
have the trusty file chooser dialog box and mailers with a sane
interface for adding attachments. :P Again, what you want via editor
functionality seems better served via specialist application
functionality, in this case mailer functionality. The mailer can know
all about attachments and therefore provide a much saner, functionally-
specialized interface for adding attachments than a text editor can.
Using vi instead of mutt to do the attaching (even if only by adding
lines that mutt will expand automagically) seems like putting subclass
functionality in a base class or something. :P

"Relatively easy", my left *** cheek. I'll bet it's a real pain
relative to click edit menu head, click "format". :)

Nope. Put the cursor at the beginning of the paragraph, type
"!}fmt -60<return>" to format the paragraph to max-of-60-characters
lines. I do this a lot, so I have a key mapping defined and just
type "V60<return>".

!}fmt -60

I'll try and remember that ...

Eh, was it {!fmt 60? Nah, !{fmt 60? Argh ... maybe it was !}-fmt60?

I give up.

And I rest my case. Painful indeed.

And that's leaving aside the niggling little matter than putting the
cursor at the start of a paragraph in a text editor and typing "!}fmt
-60" *should* result in your paragraph now starting with the
characters "!}fmt -60". :P

Hell, it even sounds like there's at least two ways to launch external
commands, !} and :r, in this thing ... I wonder how many more and what
subtle differences and gotchas exist among them? And why you claimed
it wasn't a feeping creature earlier? :)

I also don't see how the hell you can expect it to format the one
paragraph. Surely running "fmt -60" on a text file does the whole
thing? And if it does guess one paragraph to change surely it
sometimes guesses wrong fairly often? Not to mention that if the
editor doesn't save before invoking the external command on the text
file, and does load afterward, your most recent changes will
evaporate.

vim also has built-in formatting that does the right thing with
">" quoting. Usually I use this by first selecting the text I
want to reformat with vim's "visual mode" text selection commands
and then typing "gq".

Eh -- "gq". Yeah, that's real obvious. When you want to reformat
quoted text on usenet, the answer is the title logo of the magazine
Gentlemen's Quarterly! I'd have guessed that in a heartbeat! :)

Haven't used vim much, have you? It has a "visual mode" -- I
think it may even support making the selection using the mouse,
but I don't use it that way so can't say for sure. But there
is support for selecting text (first type "v" to start selecting,
then move cursor with usual cursor-movement commands), and the
selected text is visually distinct from non-selected text.

Of course, even given a selection, some external command invoked on
the same text file you're currently editing has no way of knowing
this, anymore than if I open "foo.txt" in Notepad and select a chunk
of text, then open "foo.txt" in another copy, the same text will be
selected there too (none will).

No. The point is that you can pipe *selected lines* into the
external tool.

Eh?

You have "foo.txt". You're editing "foo.txt". You invoke "fmt" on
"foo.txt". How does "fmt" get any scoping information in this
situation?

Probably not, but someone who's concerned can easily do a save
before making any change that might be dangerous.

I suppose; good advice before doing a search and replace ...
especially with finicky and unpredictable regexps!

I'm not really sure whether vim supports auto-saving; that's not
a feature I much like anyway -- I'd rather decide myself when
edits are saved.

Auto-saving with versioning of some sort might be useful though.

My guess is that what's really happening is that the selected
text is being piped into the external command from wherever it's
stored in vim's memory, and the results are captured from the
command's standard output and stored back into memory.

That sounds like some kind of interprocess communication. It still
sounds like it might go bonkers on you. For one thing, two processes
sharing address space become vulnerable to either one of them being
able to bring both down, so if your "fmt" catches SIGSEGV ... goodbye
unsaved changes in the editor too. Either the editor dies, or worse,
it doesn't, but the segfault might have corrupted the selection, or
even the whole virtual address space of the editor. Even if there's no
shared memory involved (temp files or something else safer but less
efficient instead), the thing might still output a pile of junk, or a
spurious error message, or goodness knows what else.

Of course you've neglected to explain how simply moving to the start
of a paragraph selects the paragraph in the first place (or how to
avoid such unwanted auto-selection-changing when navigating, for that
matter).

And it remains the case that powerful (and risky) as some of this
functionality might be to use, none of it is at all apparent from the
thing's interface, or easily discovered; and all of it is brittle to
invoke. You miss with a mouse click and nothing happens; and it's
rare. You mistype !{-fmt 60 or whatever it was (and I'm sure I just
did!) and Christ only knows what will happen. It might reformat the
whole document. It might insert some error message into your text. It
might run amok appending every file on the hard drive to the buffer
until the editor blows chunks with an "out of memory" message. It will
probably just plain fail, of course, but I get the feeling that with
regexps, wildcards, confirmation-free commands like "rm", and the
like, oftentimes one typo is all that separates you from disaster. And
the system is reliant on all of this typing, of nonobvious and cryptic
strings deliberately chosen for brevity rather than readability (or
distance in the #-of-typos metric from anything that will do something
drastic instead of quietly fail). It's not just novice-hostile, it's
hostile to anyone who ever makes a typo, and to anyone who has a less
than eidetic memory. Phone book memorizers can use it safely and
reliably. No-one else is likely to avoid eventual serious trouble
stemming from gumming up one of those little snippets like :rt?ls
whatever-it-was.tex :P (And yes, I know, I probably didn't get that
right either. See what I mean?)

"Undo" works pretty well too, and is one way in which vim truly
is "vi improved" -- straight vi supports only a single undo, but
vim stacks them.

Another negative point for straight vi then. Especially if it's as
crazy as to support regexp based replace but not multiple undo.
(Though a replace that does many individual changes should count as
only one undo anyway.)

Being able to embed the calculator into the text file would be even
better.

But it's kind of silly when the result of the calculation isn't going
to change, right?

In that case, copy and paste seems much easier and more intuitive, and
less typo-prone, than }!fmt 60 or whatever the *** it was. :)

More or less -- the two ways I use this stuff are (1) to replace
selected text with the result of running it through some external
program, and (2) to insert the result of some external command.
For the latter, you choose where to insert.

And as far as I can tell, (1) indicates functionality that the editor
itself should really include, or a specialist application like an IDE
that includes a (or hooks a system) text editor, whereas (2) is a
crummier, slower, and more error-prone equivalent of copy and paste in
a GUI.

Still involves manually micro-managing the plumbing in the tool chain
instead of automating all of that crud.

Dunno what you're talking about. mutt and trn decide what editor
to choose based on the setting of the EDITOR environment variable.
Command-line tools for compiling -- yeah, automate with makefiles.
Not so good for Java, but there may be other tools (Ant?).

Yeah, ant. But the plumbing I'm talking about here is having to name
and specify external files, utility binaries, and the like repeatedly.
Instead of the editor having a format command you need to use a launch-
external-app command and then specify some executable from your
filesystem to run, and so forth. In your case you apparently have it
aliased to just "fmt" and on the command path somewhere, but still.
It's typing intensive compared to other alternatives; it's also error-
prone; using longer names to make it less likely typos or
misrememberings will have drastic consequences instead of just beeping
at you reduces the error risk but makes it even more typing intensive.
Compare copy and paste, or a built in "format" command in a text
editor, or specialist commands in a mailer, IDE, or other editor-
embedding tool.

I don't get that this is significantly worse than navigating a
typical GUI help system, and at least you *CAN* read the whole
thing sequentially if all else fails.

The usual GUI help systems in my experience provide ways to navigate
to individually-small chunks, and of course provide an obvious, easy
to find and easy to use search capability too. I've *never* had
trouble finding what I needed in one unless it wasn't there to be
found. Whereas Unix documentation produces a feeling of "water, water
everywhere and not a drop to drink!" ... it's somewhere under all
those sand dunes, but all I've got is a hand trowel to dig with. Even
knowing there's a large front-end loader buried nearby that is easier
to reach with the hand trowel than the water doesn't help much since
I've no idea where the damn thing is and the dunes stretch to the
horizon in every direction.

Unix documentation really is a weak point. I just don't think
it's as unusable as you claim, and I think typical GUI help has
its weaknesses as well.

I'll take navigability and searchability over comprehensiveness
anyday.

As best I can tell, the "source" format for man pages is compressed
ASCII text representing input to the old text-formatting program, hm,
nroff? troff? something like that. Source for info pages appears
to be similar -- ASCII text consisting of text to display plus some
sort of markup.

Compressed being the operative term, I'm guessing. I know both formats
have high-bit-set chars in them. Obviously makes them uneditable (edit
them, then attempt to view them, and it will presumably choke on all
the funny chars that have been converted into ? or a square or
character 127 or whatever).

HTML supports anchors within a
page, as well as hyperlinks. Of course one also wants a system-wide
help interface of some sort; a "help" command seems in order that
would invoke a search engine. The obvious implementation is to start
from a standard root node and spider the HTML files from there, and on
a null result offer to search the whole filesystem for HTML files
containing the query (skipping those already tried). For speed, this
latter could build up an index Google-style as it examines HTML files;
for broadness it could extend to other ASCII files as well. On
success, the "help" tool would generate a temp file in HTML format
with the results page and invoke the browser on it.

That does sound like it might be nice. Does it exist somewhere?

Oh, didn't I mention that? Implementation is left as an exercise for
the reader. >:>

"Unix isn't user-friendly? Sure it is; it's just choosy about
its friends." Quoting, or possibly mis-quoting, some person
whose identity I probably should know, but don't.

That can be embellished to remark that its preference is apparently
for autistic savants. Guys that can memorize entire almanacs of
baseball scores in a single bound will have no trouble with unix. As
for everyone else ... well, a quick check for desktop market share
still shows unix a tiny minority, even if you count MacOSX as unix.

Most of the applications we've been talking about are automatically
obsolete on any hardware that has those capabilities. Their numerous
and severe UI deficiencies are a direct consequence of design
constraints so that they can operate in such shoddy circumstances as
"on a 386 with 4MB RAM over a 300-baud remote telnet session". When
you have a decent graphics capable machine right in front of you
you're far better off using something like KWrite (or Notepad, or
whatever the Mac uses).

Could be. The point I've been trying to make is that the "modern"
tools have their drawbacks as well, and it seems to me that you're
persisting in saying things about the text-mode tools that aren't
true (limited to 80x24, for example). Maybe I'm mistaken and
you're not really saying that.

I didn't say it was. I said the UI design is full of compromises made
to ensure it would still be (and I use the term loosely) "usable" even
under such constraints.

Compromises that are no longer important; designs that are therefore
obsolete.

Because I find them familiar, comfortable, and -- best of all --
almost entirely predictable in their operation, none of which I can
really say about most GUI-based tools.

Predictable? I find this especially odd. Comfortable seems odd, since
these tools have all the ergonomics of a fifty-ton cube of solid lead,
but I'll grant that; humans can get used to just about anything. But
predictable? Let's see, shall we?

* Emacs: it's so malleable, Christ alone knows what will do what if
you start up a copy other than one nobody else has ever had access to
to reconfigure. A shared copy? *shudder*
* Vi: There's nothing predictable about "open up a text editor and try
to type, and it goes bonkers!" outside of a funhouse.
* Anything involving command lines or other textual commands: one
little typo is all it takes for chaos to ensue.
* Anything involving semantically-significant line noise (so regexp
searches and replaces, sed, awk, wildcard-filled commands, any vi
command at all, and some emacs commands): one little typo is all it
takes, but even just not perfectly remembering the exact semantics is
sufficient to ensure complete and total chaos.
* And of course the only thing you can predict about the available
functionality is that there will be a whole ton of stuff you'll never
stumble upon, in addition to the relatively puny amount you've
mastered, slowly and painfully over the past six years, and whose
behavior is still sometimes surprising.

I dare say that there isn't a unix commandline/console-mode tool made,
interactive or otherwise, that *fails* to violate the principle of
least surprise.

Predictable?

*shakes head*

There we are then ... you said "I use vim" and someone naturally
suggested a superior alternative. If you'd just quietly gone on using
vim without mentioning the fact then it would be another story. :)

Here's what I wrote in response to your suggestion:

It will probably happen someday, though more in spite of your
suggesting it than because of it. I've spent a lot of hours
editing text with vim (and vi before that), though, and I'm
reluctant to set that aside. "Modern" tools are superior in
some respects, inferior (IMO) in others. <shrug>

A lot of the rest of the discussion has resulted from...

You did not only evangelize vi, but shortly afterward called all GUI
tools "inferior". Oh, and added (IMO) and scoped it to "in some
respects". No wonder this blew up ... :)

[appears to accuse me of lying]

Say what?!

Ah yes, an opportunity to repeat what I've heard as the Windows
problem-resolution mantra: Retry. Reboot. Reinstall. Linux
people used to add a fourth step, Red Hat, before Red Hat became
a for-pay thing.

Eh? It's GPL. You can surely get, install, and use a copy gratis just
as you could in the past. If Red Hat won't provide a copy without
money someone else surely will.

To me all of these seem like "kill a fly with an elephant gun"
approaches. But -- whatever.

Fixing a system hang with a reboot seems closer to killing an
elephant, or at least a rhino or so. Annoying is the need to reboot
when it really is a fly -- Explorer's memory leak, for example. It's
over 450 megs on my current session and counting; it leaks something
fierce and has since Win98 or earlier, and never gets fixed by any of
Microsoft's copious spew of "critical" updates. Eventually it forces a
reboot, because although you can kill the Explorer process and restart
it, you can't do that without losing session state (such as open
folder windows) that is preserved if you reboot. Of course, rebooting
means you lose session state in darn near everything else, but mostly
those don't require a load of directory tree walking to recover.
Restarting Exploder without a full reboot also loses you some of your
tray apps -- they're still running but will have become unreachable UI-
wise.

OTOH, as soon as you fire up a unix box and type "vi" at a shell
prompt, you *already* need a local expert to help. And that's before
anything has even gone wrong! :P

Only if you haven't used Unix/vi before. If you haven't used Windows
before, you also need help.

Yeah, but if you've used Windows before and start up Notepad, or Word,
etc. for the first time ever, you don't. If you've been happily using
unix and emacs for years and start up vi, you're stumped! And of
course, from what I can recall, you may even be reaching for that old
reset switch -- it's unobvious how to exit vi, and if you were not in
an xterm but at the actual console, you've just effectively hung the
machine. Ironic, given that the chief unix-lover complaint about
Windoze is the need to reboot a lot. :)

I also strongly suspect that things have changed a lot in the past
five years.

Could be.

What tool was that?

For reasons difficult to explain, it cannot be divulged here.

It sounds awful -- and unlike my experience. Huh. Something else
to add to my collection of anecdotes, I guess.

It wasn't one system that happened to be a lemon -- the XFMail hanging
(a common problem on the system where I used it) and its forcible
termination crashing the X server (which only happened the once) was
on a completely different system. (The X server was some unix box;
unsure of the details. But certainly not the same exact Linux distro
as the other anecdotes. The remote X sessions were accessed from WinNT
workstations using some kind of X client port or something.)

Yeah. I was going to say "at least you can save all the user
files, and then reinstall", but -- save them to where, maybe,
since if you're using the CD drive to boot from, you can't write
to there .... One of those little memory-stick gadgets maybe?

I suppose. And you'd have these same issues with a dead Windoze
installation *and* a dead Unix, I expect.

But that presupposes that you have another computer from which to
get online. <shrug>

Not a safe assumption on which to architect the last-resort help
functionality. :)

I think we may be using different definitions of "journalling
filesystem". The one I know about doesn't require any user
intervention; it just means that after a not-clean shutdown,
the system doesn't have to do a full filesystem check, but can
recover using the journal (record of recent transactions, is the
way I understand it).

Does it try to maintain actual transactional integrity, then? The
impression I'd had was that it simply did automatic versioning,
probably of a primitive (no branch support) sort, enabling better
recovery from corruption and other disasters.

We just had a power glitch at my current place of employment
yesterday. All the lab computers came up again okay as far
as I know. One of my desktops decided it needed to do a full
filesystem check because it hadn't done one in, hm, about six
months. The rest of the machines rebooted about as fast as they
would have if they'd been shut down cleanly.

Lose any recent files/changes? (Although anything with write-back
caching risks such loss including NTFS.)

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.

If it's solved the dependency-chasing hell described above, it's got
my vote.

Oh, you don't have to vote until/unless you try it and like it.
In fact I'd rather you didn't. Too much of that already.

Hrm.

Some recent distributions, Ubuntu probably among them, provide
something on top of the package-management scheme. Fedora
calls theirs "yum". I think Debian calls theirs "apt-get".
It's supposed to pretty completely automate downloading and
installing selected packages and any needed dependencies.
I'm sure it can sometimes fail in infuriating ways, but in my
experience it usually works well.

I expect I'll quickly find out all of the ways it can "fail in
infuriating ways" as soon as I have access to one. :)

Obscure ways, too, I'll bet. As in it's not *obvious* that pressing
ctrl-alt-meta-ZXCVBNM and then holding down shift and clicking
"retry" (or whatever) will fix it, when plain clicking "retry" just
repeats the same failure mode. :)

Seriously? Yes, it is an unfair advantage, and I rather suspect
that the reasons for it involve corporate skulduggery of various
kinds -- but I'll admit that I'm basing that opinion on not much
actual knowledge.

Oh, there's lots of evidence of corporate skulduggery alright, mainly
involving deals between supposedly-independent hardware vendors and
Microsoft that should (and do) raise the eyebrows of antitrust
authorities (but that, oddly, provoke no more response from them than
that).

Exaggeration for effect, I'd say.

But of course.

Eh -- no, not like that at all. That is geographic memory, which works
very well for finding things later. The output from "printenv" is just
a long list of words. Closer to memorizing the phone book than
memorizing a route, I'd suspect.

Actually, closer to "memorizing" the half-dozen phone numbers I call
most often. I find it easy. Some people don't. Probably they have
other skills I lack. <shrug>

Add all the other random strings like "fmt" that bear only passing
resemblance to any given English word and are semantically significant
to the system as a whole, and soon you're looking at at least a
thousand of those half-dozens ... :P

With regard to environment variables, since all the definitions
are stored in one of the files read by my shell at start-up,
duplication isn't going to be an issue; when I add a new one,
I can tell whether there's already something there pointing to
the same place.

They're stored in a file somewhere? I guess they'd have to be to
survive reboots. Even then, unlike symlinks they won't be visible to
filesystem tools based on filename searches (and I never resort to
whole-filesystem-scoped searches based on file contents, because
opening all 500,000+ files on a modern filesystem takes hours, and I
want results sometime *before* this evening's Star Trek comes on TYVM;
it doesn't help that the Windows search tool has been known to
leak ... no, *hemmorhage* memory when it does this, bloating to half a
gig or more, but even if it didn't, the search will take as long as a
full virus scan, i.e. an hour or two, since it basically does the
exact same thing).

With regard to symbolic links, I can't think of any instances in
which I have multiple links to the same place because I forgot
the first one and made a second. Rather, they're useful in making
the same shared resource (a makefile, say) appear to be local in
a lot of different locations.

Of course. And you can find them without doing file-contents-search.
And it may even be that you can find all the ones that reference a
given destination somehow. (I don't know, but it sounds plausible, and
perhaps useful.)

Symlinks on the other hand:
* Survive shutdown
* Are visible in the filesystem
* Can therefore be found with the filesystem search
* A filesystem that has subdirectories and longer file names! compared
to a printenv listing
* Don't consume RAM when idle
* Can't have unexpected side effects unlike env vars that something
might use for some reason
* Can, IIRC, be rigged to automatically track if the target is moved

Don't think so. That would be nice, but no. (Maybe you're
thinking of hard links? but they can't point to directories.)

Eh, that's odd.

Yeah, it kind of makes sense, but to me putting another half-dozen
symlinks in my home directory would make it feel cluttered.

Use another directory then (a subdirectory, or laterally elsewhere).

Though ultimately, I guess, it's your choice, weird though yours seems
to be.

Looks like it. Though any "different style of thinking" that actively
prefers to try to be productive while blindfolded is clearly not only
non-mainstream, but probably certifiable. :)

To me keeping some system state in one's head is not fundamentally
different from, oh, learning to touch-type.

It's when you're keeping ALL the system state in your head that I get
worried. :)

Actually it probably *is* less than optimal, but I'm stubborn,
and I'm not entirely convinced that an effort to improve it would
pay off overall.

Stubborn ... yes, I'd have to agree there. :)

(Also, note smileys. None of your questioning of my mental health were
accompanied by such, none that I recall anyway.)

(Or were you figuring this thing to have actual, easily navigated help
for once?)

No, I was figuring a user who didn't mind doing a bit of learning
before being able to make much use of the tool.

Yuck -- what if they only need it rarely? If it's something they'd use
day in and day out I might see justifying that, *IF* additionally the
problem domain is inherently complex and difficult to translate to a
user interface that won't be unobvious. 3D modelling tools come to
mind here; most of those are unusable without a cheat-*** and it's
hard to imagine how they could be any other way because of the very
nature of what they do. Some kind of three-dimensional, orientation-
sensitive "floating mouseball mouse" might fix that if Xerox Parc has
another miracle insight in UI hardware design, but until then ...

OTOH, if we're talking a text editor ... yuk. If we're talking
anything that will be used infrequently ... suk. Use a "wizard
interface" for those, that guides the user through each step; nobody
will learn and internalize the command set for something they only use
at tax time or when the system is hosed enough for the next full
reinstall or whatever. So rarely-used configurators, tax-preparation
software, and so forth better provide step-by-step instructions (and
some kind of "back" button, and other help) or else. :P

I've said before that I've figured out how to use at least one
tool (gnuplot) without a live tutor. Now that I think about it,
I don't remember having a live tutor for vim either -- maybe for
vi, years ago, but I'm pretty sure most of what I know about vim
I've learned on my own. It does help to have had someone show
me the basic Unix ropes, years ago. But past that I seem to be
able to get a lot of stuff without the live tutor.

What "basic Unix ropes"? Given that vi is utterly unlike emacs, yet
both are Unix text editors, and vim is even apparently utterly unlike
vi, it's hard to see what "basic Unix ropes" will help with all three,
or any one of them even. As for the rest, I don't have even a good
guess at an explanation. Luck seems out of the question, as it would
have to be frankly astronomical. Unless it hit a key area, such as
stumbling on an effective way to search, and jump around in, man pages
perhaps, or quickly getting the hang of the emacs internal window-
switching command so you could use the emacs help without always
winding up leaving it on "help on switching windows" when the focus
was in the document you were working on.

I think there are fewer of them mainly because there aren't different
ones for every application, but a single group of system-wide "tricky
things". Which you only need to learn the once. Most of which are
documented in relatively usable help, too. Also, training on basic GUI
usage is normal in school nowadays; you may have just missed that. (I
did too, but have had no difficulties with Windows UI basics the way
you claim to have had. Hmm.)

"Hmm" yourself. As for "just missed that" -- I graduated from high
school in the early 1970s, so I missed training in Windows usage
by many years. My first non-trivial encounter with Windows was
in 1997, after a couple of decades' worth of mainframe/mini usage.

Eh -- Windows was around a *lot* longer than that. Windows 3.1 is when
it went mainstream, and was in wide use quite early in the 90s.
Windows 95, the first "modern" Windows, was of course already in
widespread use by 1996, let alone 1997. I don't see how you could
avoid something that ubiquitous for most of the 90s. *puzzled frown*

It
allows all kinds of things. For example I'm going to make sure this
isn't destroyed by GG again by copying it and pasting it someplace
before attempting to submit it. On a Unix system there's no way to
preserve something from an application with no save command, which
includes any and all web forms, at least outside of X.

True. But most Web forms are only minimally navigable without a
graphical browser anyway.

But of course. Just like most anything else is only minimally
navigable without a GUI. Haven't I been saying this all along? ;)

Regardless, HTML + browser is a sane modern replacement for all sorts
of older help systems, given a suitable search tool (see above), and
lets the user use their choice of browser if implemented right.

Yeah. But while we're waiting for someone to invest the time and
effort of making the conversion ....

Well, the Windoze apps I tend to use are by and large using HTML for
help these days. (Sometimes in a crufty compressed, binary CHM form
instead of plain HTML; often via Web site. I've come to expect F1 to
change the focus to Firefox in any given random new app if it doesn't
pop up a purple ? book window open to a CHM file instead.)

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.

Even if the reader in question throbs with evil, takes up 666MB of
disk space, and was coded in goats' blood using a pulsing red
pentagram-shaped IDE by a creepy necromancer and his Zombie Legions of
Doom(tm) as part of a plot to take over the entire Internet? :P

"The reader"? There's more than one available for my platform.
Admittedly only Adobe's seems able to recognize recently-added
PDF features.

It's also the only one (obviously) usable with Windoze. Probably
there's a port of some unix pdf tool to Windoze; almost certainly it's
unusable by comparison with Acrobat Reader (where it's as shockingly
simple as install it, double-click a PDF, and read; and navigate in
the obvious ways). Most likely you need to configure all kinds of
plumbing (this is certainly true with GSView and Ghostscript for .ps
file viewing); most likely you either have a command line tool or a
cruddy GUI that is obviously a port of something non-native or else
bolted onto something else in a hurry because, well, the rivets are
showing. GSView has a nearly-normal GUI but an annoyingly pixelated
rendering of what looks nicely antialiased in Acrobat Reader; it's
frankly headache-inducing. I doubt a hypothetical non-Adobe PDF reader
is much better. A lot of ported Unix apps that have a GUI have such
brokenness as non-realtime scrolling (reminiscent of Windoze 3.1) ...
it seems navigability is an alien concept to Unix tool authors, even
trying to port to a platform like Windows where users expect it and
take it for granted. :)

(Maybe I should add that on the whole I appreciate that you rekeyed
your reply, since I don't like to leave discussions unfinished.
But this *is* turning into a bit of a time sink for me .... )

It is, is it? For just you? Hmm. I wonder. :P Thank you anyway.

.