Re: Great SWT Program

In article <1191463222.077099.294270@xxxxxxxxxxxxxxxxxxxxxxxxxxx>,
<bbound@xxxxxxxxx> wrote:
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? :)

No. You claim that you do know about automating things. Apparently
there are people who don't. They're the ones I'm slurring here.

[ snip ]

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.

Maybe another "YMMV" thing. Touch typists trained on the
old-style keyboards probably have good motor memory for where
the keys standard with those keyboards are; sufficient practice
in using Those Weird Keys With Funny Names probably develops a
similar ease in finding them.

[ snip ]

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'm not sure I remember exactly what made the two-views thing
seem useful in the drawing program; I think it was something
about being able to position things more precisely than one
easily could by pointing/clicking/dragging. I usually use xfig
for drawing figures (mostly because it plays nice with LaTeX),
and more than once I've found it very useful to manipulate the
text files in which it stores information with a text editor.
An example would be drawing a figure of a matrix and wanting to
label each element with the right indices -- you can copy and
paste to create the figure, but getting the right text into each
little box is kind of a pain.

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.

Nah. If I want to do something in the shell for which the
line-editor prompt isn't good enough, I'll write a throwaway
shell script. Being able to write such a script without actually
putting it in a file .... Oh. Cool. I hadn't thought about
it before, but I can just start up vim, type in the commands,
edit to my heart's content, and then execute them without saving
to a file that would then need to be deleted. Thank you!

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,

Easier to learn, or easier to use? I say "probably" on the former,
but "no" on the latter. I don't get how switching back and forth
between windows 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).

Well, it's the usual Unix-philosophy debate: Is it better to
have a set of tools/parts from which you can build whatever you
want, or something prebuilt? The prebuilt thing is great if it
provides the functionality you want, and admittedly people who
design such things often get it right. But what if they don't ....
<shrug>

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.

If there are dozens of lines, I'll mark them using one of vim's
ways of doing that and do the edit with one search-and-replace
command.

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.

Seems to me like six of one, half dozen of the other. My way is
harder to learn, but once mastered doesn't seem like significantly
more trouble.

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.

File dialogs, don't get me started .... Somehow it feels wrong to
me that they typically start either in some top-level place, or in
the last place you used them, rather than in the current directory,
which is what would feel natural and reasonable to me. Probably
a matter of what I'm used to.

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.

No. "ls otherdirectory/*" works, though it would require a little
more postprocessing to put the full pathname into the Attach: line.

Just so you know, mutt also has a way of attaching files via text
menus, including the ability to browse directories. But it doesn't
have the kind of nice "select multiple files" feature you describe.

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*

Huh. While to me the "current directory" notion seems like
a *good* thing .... And of course one entry in the current
directory always points to the parent, and one can go directly
to the one's top-level directory as well, so I don't get how this
is a significant limitation.

As for exiting and restarting -- the old text-mode tools generally
launch very quickly compared to typical GUI applications, and they
tend not to have a lot of "state" that would need to be preserved
across sessions. That's one of the reasons I chose vi over emacs
all those years ago; emacs was slower to launch.

[*] 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!

It would be silly if it were true. But it's not. See preceding
discussion.

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

So you do know something about how Unix works. Duly noted.

All of these tools of course can find files either using pathnames
relative to the current directory or full pathnames, usually with
"~" expandable to the user's home directory.

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.

If that's at all a concern, one performs the search-and-replace with
options that show each change and ask whether you want to perform it.

[ snip ]

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

It was the mention of GUI that set me off. Sort of a :-).

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?

No. Copy and paste requires switching between windows, at least.
As for "more controllable" -- I dunno, maybe if you're not very good
with the tool.

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)

If I wanted to select just a line or two from some file, I'd use
":split" to get two windows, switch to the other one, use ":view"
or ":edit" to view/edit the file I wanted to get text from, and
cut and paste using vim's normal mechanisms for doing that.

[ snip ]

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

Well, I didn't remember it either. That's why I mapped most of it
to "V". (I didn't include the linewidth in the map because I want
to choose that when I use the command.)

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

Well, the "!" means invoke external command, the "}" means "to end
of paragraph", etc. Greek, or worse, to you? Yeah. But not to
a vim user.

[ snip ]

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

Modal versus non-modal. Whatever.

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

No. One way to launch commands ("!"), but two choices about the
command's input/output -- whether you want to just get the command's
output (":r") or use it to process part of the file being edited.

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?

Sure. But that's not what's being done. Run without a filename
argument, "fmt" takes its input from standard input (stdin) and
writes to standard output (stdout). So it's perfectly possible for
vim to use only part of the file being edited as input to "fmt",
and to take the output and use it to replace part of the current
file.

Many of the old Unix tools work this way -- read from stdin,
write to stdout. I guess that's something one might not know
or remember if one doesn't use them often.

[ snip ]

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?

Well, it doesn't. But that's not what's being done; "fmt" isn't
being invoked on the whole file, but in the mode in which it reads
from standard input (presumably supplied by vim and consisting
of a selected part of the file) and writes to standard output
(presumably captured by vim and used to replace the selected text).

Now I'm curious about exactly how vim is invoking the external
commands and hooking up stdin/stdout appropriately. But perhaps
even without those details it's clearer what's happening?

[ snip ]

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.

It appears to still be on the "todo" list for vim. (":help
autosave" actually shows it as part of a "todo" list.) Free
software, and all that.

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

My guess would be pipes, which have been a standard Unix thing for
a long time, and I'd be surprised if they didn't work. As for
"fmt" generating a SIGSEGV -- how likely is that? It's a very
old program and unlikely to still have bugs.

the thing might still output a pile of junk, or a
spurious error message, or goodness knows what else.

Yeah. In which case you type "u" to undo the change, and no harm
done.

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

It's all pretty straightforward when you know the tool. I'm not
writing a complete tutorial here.

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.

[ snip rest of -- may I call it a rant? ]

vim is not for you, that's clear.

I could make similar complaints about some of MS Word's behavior,
such as its auto-this and auto-that. You might respond that all
of this can be turned off, and you're right that it can, and
perhaps any reasonably savvy Windows user would figure that out.

But again I think you're underestimating the potential difficulties
of the platform you know so well, just as I'm apt to pooh-pooh the
difficulties of *my* preferred tools. Example:

Some years ago I was talking to an elderly friend of the family,
and she was complaining about how Word messed up her documents
(with all of those auto-something features). I said "well,
you know you can turn those off, right?" "You can??!! How?
Please tell me!" This isn't an especially stupid person, but she
didn't grow up with this technology and probably doesn't find it
especially "intuitive".

[ snip ]

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.

Really. That seems like a surprising statement from a technical
person. Well, whatever.

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.

Yes, with gzip.

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

What you might be seeing is the output of whatever tool processes
the "source" files (nroff/troff for man pages, I think texinfo for
info pages). It may well include things other than 7-bit ASCII.

HTML supports anchors within a
page, as well as hyperlinks. Of course one also wants a system-wide
help interface of some sort; [ snip ]

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

Seems to me it should be left as an exercise for the person who's
proposing it. I'm not sure I recognize the ">:>" emoticon (?).

[ snip ]

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*

What in the world are you talking about here.

* Vi: There's nothing predictable about "open up a text editor and try
to type, and it goes bonkers!" outside of a funhouse.

I find it utterly predictable. That people new to it don't -- so
what.

[ snip ]

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*

"Choosy about its friends".

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

"In some respect" .... "(IMO)" .... I don't know what more I
could do to avoid a flame-fest, short of just keeping quiet when
I don't agree with you.

If I appear to be evangelizing for vim -- that's not my intent;
my intent is to explain why *I* like it, and to correct statements
about it that, based on my experience, are in error.

[appears to accuse me of lying]

Say what?!

I don't accuse you of "lying" in the sense of deliberately saying
things you know to be untrue. However, sometimes I believe you
say things that aren't true out of lack of knowledge. If you
think it's an insult to point that out -- yeah well, I think
this point has been hashed and rehashed with you. "Whatever."

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.

Correct. But the joke doesn't work as well as it used to,
because Red Hat's particular distribution is, as far as I know,
only available by paying their support fee.

[ snip ]

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

Control-z to suspend the application works. Long-time Unix users
would almost certainly know about that.

Now, the time I fell into the TECO editor by mistake .... :-)?

[ snip ]

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

So, is the problem X, or XFMail (a name I don't recognize, but
whatever), or the X client running on That Other Operating System,
or what .... <shrug>

[ snip ]

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?

That's exactly what it's intended to do, and what I understood
"journalling filesystem" to mean.

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.

I'm not aware that it provides anything like that.

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

Work that hadn't been saved, maybe. Work that had been saved
to local directories, possibly. As you say, if disk writes are
cached at all that's kind of hard to avoid. Work saved to users'
home directories on the file server, no, since it's somewhat
insulated from power glitches (UPS? something like that).

[ snip ]

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

Probably. You seem to have a knack for that.

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

Huh?

[ snip ]

Symlinks on the other hand:

[ snip ]

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

What, that hard links can't point to directories? I'm drawing a
mental blank here on why it's not possible, but I seem to remember
that there *is* a reason, and it involves how they're implemented.

[ snip ]

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

Quite. Agreed that for something that's only needed rarely a GUI
may make more sense.

[ snip ]

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

The closest I can come to describing it is something about the
overall philosophy of the system -- designed by techies for
techies -- plus an ability to get meaningful information out of
the various (admittedly incompatible) sources of online help.

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.

My mileage varies. Before Unix, I had used a number of other
systems with command-line interfaces, and the idea of "okay,
new system, what command do I use to list files in the current
directory" was not foreign.

[ snip ]

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

I was in the mainframe/mini world until almost 1990; for part of
that time I had a PC on my desk, but I think it ran some version
of MS-DOS, and it was used mainly as a terminal to connect to the
company's mini and for dial-up access to other mainframe/mini
systems. I then went back to school (grad school), and mostly
the department used Suns running Sun's Unix. At that point I
asked one of my mentors about buying a PC, and he said "don't
bother; the school's computers are much better than anything you
can afford, and you can access them with a terminal and a modem".
The idea that a PC at home would be desirable -- I came very late
to that idea. I think I said in some other post somewhere that
for a long time I regarded them as toys unsuitable for serious
work; I was more interested in what I could do with the "real"
computers at work/school. I don't say that's a good attitude
necessarily, but it's the one I had.

[ snip]

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

But the problem with Web forms is often that they make use of stuff
that isn't supported in text-mode browsers, at least not the ones
I know about -- JavaScript, in particular.

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

Yeah. Hundreds of lines of reply .... I'm trying to prune a bit
more, but obviously not succeeding, as this is line 774 of the
post as I'm editing it in, um, vim.

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