Re: Great SWT Program

On Sep 28, 12:28 pm, 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

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.

Must be the exception that proves the rule, then.

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

How sucky.

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.

That's like designing the Space Shuttle to emulate some aspects of a
Model T. :P

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.

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.

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

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

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.

I'm not sure that qualifies -- I don't think it gives a "true" preview
(although I suppose it would be unable to in the case where the
document was not well-formed).

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.
This is one place where I'd recommend going functional and using some
kind of OCaml or Haskell derivative as the language. Many of LaTeX's
crufty bits stem from side effect inducing expressions, so a pure-
functional language replacing a crummy unhygienic macro substitution
one would be a big leap forward there. Functional seems to fit very
well here since the output is write-only -- generating the document is
a noninteractive process. This naturally suggests an implementation
consisting of a) a runtime in something like C or C++ for the language
in question, including possibly special functionality to support the
specific purpose of document-processing and including a front-end for
the tool, perhaps as a separate GUI-presenting application that
invokes the engine in the background; b) code in the functional
language that implements the basic essentials of the document
processor; and c) the document itself (including via include
directives) contains in its preamble additional functional code, as
well as the document content itself.

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.

There are IDE-analogues for HTML and for LaTeX too. You yourself just
mentioned LyX. Of course a lot of the graphical HTML editors blow
chunks when it comes to producing decent, standards-compliant code;
I'd be satisfied with a tool that let me edit the code in, say, the
right half of the screen while the left showed a real-time preview of
the page and let me scroll up and down. Ultimately though what seems
lacking is an easy way to generate lots of similar pages or "#include"
a standard header and footer in every page of a site or similarly.
Writing the same navigational boilerplate (or even pasting it) ten
zillion times gets old really fast. That HTML 4.2 still lacks an
include directive is atrocious. (No, frames don't count; I'm talking
an inline-include that still presents to the browser as a single frame
with a single document and doesn't depend on extensions, applets,
Java***, or anything like that. AFAIK it doesn't exist, save via
special server-side support and languages like PHP, which is no good
if the only hosting you have is of the "FTP us some HTML files and
they'll be world-readable at URLs that start with http://www.host.com/~youruserid/";
variety -- and I'm not aware of any ISP providing its customers
hosting of any other kind, nor of any free third-party hosting
services providing hosting of any other kind.)

Ability to interoperate with the environment, do search-and-replace
using regular expressions, record and play back macros -- those seem
more significant, I think.

I'm still of a mind that a better shell is what's really needed there
much of the time. Plus, regular expressions are overrated. In my
experience it's quicker to do a plain substring search that Just
Works(tm) and have to hit F3 a few times to get to the first hit that
I actually want than it is to spend several minutes basically writing
a short program to do my search for me, fiddling around with something
that resembles line noise and frequently referring to the help before
eventually doing the search and having it jump directly to my target.

Wildcard searches (that allow "" phrase grouping, * and ? with the
usual meanings, etc.) seem a reasonable compromise, since the added
bonus features are easy and obvious to use.

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.

I'd consider whatever comes with it to count towards bloat and stuff
you have to find and download separately to not count. Under those
rules, emacs at least definitely exhibits bloat.

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.

For all you know, the 4M emacs executable you examined is the emacs
idea of a stub, too ... ;)

(Where does it load all that elisp from? If the executable is just a
lisp interpreter and all of the actual text editor functionality as
well as all the addons are in separate files, then the binary really
*is* a 4M stub...)

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.

Eh? The help sharing the "basic editing keys" with the editor is the
worst design decision in history (I believe the second-worst was
something involving some things called "O-rings") since it means
someone to whom the "basic editing keys" are non-obvious is fucked.
They can't navigate the help to learn said "basic editing keys"; the
design creates a catch-22.

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.

Another case of having only one or the other of those instead of both.
Of course, if a tutorial is needed for people to be able to simply
start the editor up and do some basic typing, opening and saving, and
suchlike then you've already colossally failed in the usability
department. (Tutorial being needed to use advanced features is
obviously normal though -- regular typing, substring searching, saving
and opening, cut, copy, paste, undo etc. seem to belong under basics;
stuff like regexp search or the IDE-like behaviors described earlier
would qualify as advanced.)

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.

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.

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.

This sounds closer to the idea of a "word processor" that allows
embedding various objects -- calculations (like spread*** cells) and
the like -- whose capabilities are provided (and extended) via
plugins. In text mode this would sort of suck, though it could be done
passably using, say, background color to denote different "zone" types
and providing a way to insert a new zone type at a spot. In a GUI this
is dead simple in principle with different GUI components appearing
and the use of the mouse as well as keyboard to navigate. Microsoft
Word tried (and of course failed, since it came from MS) to be
something like this, via OLE. Perhaps one day someone will succeed
where Microsoft (inevitably) failed?

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.

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

Also, this sounds like the sort of thing that's likely to go
Sorceror's Apprentice on you. A built-in format command would
obviously be scopable to a paragraph (e.g. via the selection). AFAICT
none of those unix editors even *has* a concept of a selection in the
normal sense, so any scoping would be arcane, and an external tool
would just act on the entire file anyway. I don't suppose it even auto-
saves before invoking the tool? In which case if it invokes the tool
on the disk file and then replaces the open document with the contents
of said file, you end up with a nicely-formatted document that is
missing your last few minutes' worth of edits. How nice.

Anyway I would argue that paragraph formatting of this basic sort does
belong in a plain text editor and doesn't make it begin to feep.

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.

Being able to embed the calculator into the text file would be even
better. See above -- no need to use some crufty command-line
invocation and have God only knows what happen if you mistype it; plus
you can edit the inputs to the calculation later on and have the
numbers update, instead of them turning into just text as soon as you
import them. Embedding lets you keep the abstraction and structure of
the source instead of converting it into something (text, a bitmap,
etc.) that's no longer editable that way. (E.g. import vector graphics
-> probably get an inline bitmap; embed vector graphics -> can edit as
actual vector graphics still.) Basically "the formatting gets lost" in
a sense using your approach but won't with an embedded-plugin based
system.

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.

I don't think so. See above; you "lose the formatting" and structure
when you import the output of those tools, and you have to manage all
the plumbing explicitly and manually, not to mention you need to do
this every single time. Every time you use that calculator to insert
an integer you need to reach for the command-processor-access command,
specify the command line to that calculator, etc. ... and then I
assume the output magically gets inserted at the insertion point in
the currently focused document. After which if you want to change it
you need to delete it and do everything over again; you can't just
navigate into it and be instantly working in the calculator with
numbers rather than merely working with ASCII; you can't just change
some of the inputs to the calculation and watch the output embedded in
your text reflect the change appropriately and automatically. And with
my idealized version of this functionality, of course, you only have
to drop the calculator tool into the plugins directory of the editor
the once, and it appears under C in the appropriate menu, and there'd
be some options dialog where you could bind a key. You'd only need to
bind the key the once and save the settings; subsequently you could
just hit, say, shift-ctrl-C to insert a new calculation. Just
navigating into an existing calculated value would summon the plugin
automatically. Of course it gets more complex if you want to be able
to specify calculations in terms of other calculations in the
document, so changing a number early in the text updates every other
number in the text that has some mathematical, specified dependency on
that number. Then there needs to be a way to name calculation cells to
use them in other cells spread***-style. (Drag and drop over long
vertical distances is way too big a pain to force people to use here.)

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.

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

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.

See above: the "plugins" that come standard count; the options don't.

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.

Exactly. You learn this stuff once, in grade school in the computer
class, and it Just Works(tm) in every application you use
afterward ... as long as it's not an old-style Unix app. Newer Gnome
or KDE aware stuff, Windows, and Mac though ... i.e. 99% of apps ...
yep.

Quite a timesaver!

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.

Well, I've already detailed the deficiencies of both "man" and "info",
but to summarize the worst issues:

Man: need to exit and restart to view different commands; one finds
oneself typing man this, reading and scrolling, exiting, typing man
that, etc. in order to do anything nontrivial. What a pain! The major
fault lies in the lack of hyperlinks. Also, many man pages are very
long and what you seek is halfway down, which means a lot of painfully
slow skimming and visual searching, unless you can figure out somehow
how to make the thing do an automated search AND you know a good query
that should jump right to the area of interest.

Info: there isn't a proper "back button" in the browser, or a proper
history or anything. Not all key commands are obvious or intuitive.

Replacing both with a combination of HTML files and your choice of Web
browser would seem prudent. HTML files are text whereas both man and
info seem to use a binary format (it's definitely not 7-bit clean
ASCII at any rate) and easily modified. 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.

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.

Yes -- it seems some people think it deserves a one out of ten on the
helpfulness scale while others, including myself, think it deserves a
zero. ;)

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

If you've got those sorts of hardware capabilities and only use them
to get more CPL in a terminal window, that's like having a hypersonic
jet and only using it to go to the corner store in 1/12 of a
second. ;P

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.

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

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

In this case it would make sense to have the names expand immediately
on rollover; no wait, no fuss.

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.

See above. If you have real video hardware why the *** are you using
text-mode applications at all??? :P

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

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

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

On the one hand, the tools in question are obsolete; on the other,
that anonymous ID is the subject of active (although so far
unsuccessful) attempts by certain individuals to pierce it. I'd say
that that makes defending the former rather silly and defending the
latter rather prudent.

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.

Most Windows problems are solvable with a reboot, or failing that, a
reinstall of the offending application, use of System Restore from
Safe Mode, etc.; if you know how to do those things and don't
deliberately muck around with unfamiliar parts of the registry etc.
you're generally not going to need that expert.

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

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.

Your mileage obviously varies. I had the displeasure of trying to set
up and use some Red Hat based systems not that long ago (five years,
give or take one or two). An awful lot of stuff just didn't work right
or was a pain to set up or install. Dependency chasing was part of it
-- download this, it says you need that and those. Download that, and
it says you need these...

The machine lacked net access, so every newly discovered dependency
necessitated a trip to another machine, download, save to removable
media, and transfer ... that definitely didn't help, but it only made
it slightly more annoying. A lot of these things were elusive to find.
The machine was an x86 so compiling at least could be avoided by
finding binary distributions. Nevertheless, things often did not work
out of the box. A supposedly mature tool came with a help browser of
its own (HTML-based!) and various components for a search engine it
would use under the hood, but the actual documentation files
themselves were completely missing. Manually examining the insides of
the archive verified that the files were just plain absent. They could
not be found online at all, not with google, and not by asking the
people responsible for the tool's development for a zipped copy --
amazingly, one of them suggested that if I couldn't find the
documentation I should *write it myself*. What? Why reinvent the wheel
-- and how could I anyway, when the whole reason I was looking for the
documentation was because I did *not* already know all of the material
that belonged in it. Missing the obvious there, someone was.

As shipped, "sudo" didn't work either, so it was annoying to run
things as root on that machine. Obviously there was no easy
explanation for sudo to fail where just plain logging in a new session
as root worked; no doubt a lot of arcane fault-tracing through the
system's plumbing would have been required to fix it. I hadn't the
patience at this point to even try. The copy of KDE worked out of the
box (thank Christ) but an icon editor tool included with it would
actually hang the system -- something Linux is mythologically immune
to, but I know that reality is different. Even earlier I'd seen this
-- I'd had an application (XFMail IIRC) in a remote X session hang,
and killing it (I *think* telling the X session to "destroy" its
window tries to kill the process) crashed the X server, hanging my
entire session and everyone else's in a roomful of computers. If I'd
known it was going to do *that* I'd have just hidden the nonresponsive
window out of the way somewhere and started a fresh instance, and let
it complain of the stale lock left by the dead session. The icon
editor at least didn't bring down a machine other people were using;
it just spammed error dialogs (simply from launching it and attempting
normal use) at the rate of about 500 a second, far faster than a human
could hope to close them. Modal, so the app window itself couldn't be
closed. X rapidly became unusable, so there was no getting to a
console to go through the slow and laborious process of finding out
the thing's PID with ps and then sending sigkill to it with kill -9.
(Windows' task manager has a number of helpful features in this
situation: 1. it can be set to "always on top", so it doesn't get
covered by spammed windows; 2. you can just locate a process by name
and right click, "end task" to kill the fucking thing. No diddling
with consoles and multiple commands and pointer-chasing just to kill
something before it kills your X session. Yep, ps + kill is Unix
usability at its best folks!) Basically, the dialogs (and they stole
focus making a terminal window unusable anyway) forced me to cold
restart the machine, since there was apparently no escape (given it
had no net connection; it might have been rescued using some form of
remote administration had it had one and had it been configured to
permit remote login; but in reality, the only available UI was
effectively dead, so...).

These nightmares, by the way, were on a system *with* package
management. I don't even want to contemplate how much worse getting
things to install and work and dependency-chasing would have been
without it.

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

Why would you? You only learn what you're going to use. If you're not
planning on using a console-mode mailer (yuk) you won't know how when
some emergency leaves you with no GUI. :P

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.

And then what? You fix the problem together with exactly what guru?
Because it's sure to be something arcane that needs doing. Especially
if the problem is a failed fsck on startup secondary to a power outage
or X hang or similar abnormal termination of the previous session.

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.

It's the system hosing itself every time there's a thunderstorm that's
the bigger deal. Journalling filesystems offer the hope of rapid
recovery of course -- if you know which file needs to be reverted to a
good version.

What we really need in the very near future is a filesystem that
implements the whole ACID enchilada -- transactional integrity and the
works. It can do full (branch-capable) revision control as an extra
added bonus feature. Of course, the other thing we really need in the
very near future is cheap, reliable hard drives in the buck-a-TB
range. ;P

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.

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.

It probably *is* an unfair advantage of Windows that no-one ordinarily
has to install it from scratch except experts at computer
companies. :P

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.

Someone who knows the tools won't be searching the help on "cd" in the
first place. :P

The really silly thing is that it knows exactly what "man cd" means
you want help on and which file contains that help; it just won't go
that last mile and open the browser to the part of the file that's
relevant, leaving you to go hunt for it yourself. HTML with anchors
would help here.

Google on the other hand has no excuse, since what it indexes IS HTML
with anchors. I refer, of course, to the increasingly common
phenomenon these days of performing a search, seeing a hit with
excerpt text that looks interesting, clicking it, and getting a page
that's taller than the Empire State Building and consists of a
trillion little fragments each on a different topic but all glommed
together on one page. I suspect the rise of the blog is responsible
for this. But if the relevant-looking area of such a page is halfway
down it could Google not easily make the search result link be to the
last anchor in that document prior to the interesting area? :P I think
this would be fairly easy for Google to program. Instead you wind up
doing two searches in a row, first with Google and again with the
browser's internal search tool. What a colossal pain. :P

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.

Instead you have to learn so much about their internals (to even know
where these files are) that you probably now have the expertise to
*make* those modifications, assuming you know C. :P

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?

It should. If it doesn't someone should fix that.

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.

Yeah, but ... env vars? Hidden away wherever they hide? Symlinks would
make more sense. DOS/Windows users with a bit of savvy can use subst
to achieve the same effect, limited by the availability of otherwise-
unused drive letters.

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.

Along with a bunch of unrelated stuff, probably outnumbering them 10
to 1. Of course, even so, this is like winding the clock back to the
bad old days of having six-character all-caps filenames in a flat
directory listing (no subdirectories!); only manageable because the
media of the time had a typical capacity of only 360K.

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

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

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.

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?

The multiple copies was not being criticized as such, but indicating a
symptom of how this system depends on blind memorization so you'll
forget one and make a new one to replace it until dozens
accumulate. :P

It's not as if symbolic links take up a lot of space (I wouldn't think -- it's just a path name),

I thought we were discussing env vars? ISTR env vars carry a bigger
burden, and in particular consume RAM continually as well as disk
space. (That's if you somehow preserve them across sessions. I also
thought they'd normally evaporate at shutdown, which also reduces
their usefulness relative to symlinks.)

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
(which env vars (and Windoze shortcuts; not sure about Mac aliases)
cannot).
* Don't need to be used blind (GUI file browsers etc. can see and use
them; ls can show them)

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.

See above re: filesystem upgrade suggestions.

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.

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

Perhaps text-only interfaces are more usable by the blind though;
though that's a narrow niche indeed.

Don't you agree about the "best of both worlds" thing being
desirable?

Yes.

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.

Yes, I'd have to agree there -- zero *is* "a smallish number", indeed
as small as can be. ;)

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.

Designing an application around that is like designing a GUI
application with only one control used for everything: a combo box
with autocomplete history functionality. :P Or doing the other thing,
text editing and then running noninteractive jobs 70s-style -- using
edlin. Ugh!

A "combo box only interface" would at least have the redeeming feature
that the drop-down part could be pre-populated with a list of valid
commands, taking the guesswork out of using the darn thing.

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

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.

Only the latter really count, since in the usual situation with unix
tools where the help ranges from unnavigable to nonexistent, those are
the only ones you can ever discover absent live mentoring by a guru.
Undiscoverable capabilities might as well not be there -- it would
save disk space. Of course removing them is a poor cousin to making
them discoverable, but apparently making them discoverable (and the
help navigable) is anathema to the developers of this type of app.

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>

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

Ultimately, it's the non-idiosyncratic thing that wins out.
Application-specific functionality is in menus and the menus document
the keyboard shortcuts; and there's generally navigable help of at
least a rudimentary sort. So this functionality is discoverable.

Widespread functionality OTOH adheres to system-wide standards, and
these even translate to the Mac with minimal modification (mainly
owing to the alt and ctrl keys being replaced on the Mac keyboard by
cloverleaf and something-or-other that end up, in one order or the
other, doing the same things). As a result the basic navigation and
stuff needs to be learned only once.

There's also something to be said for a system-wide clipboard. 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. And
transferring data between applications requires outputting to a disk
file in one, then reading it in in the other, and remembering to
delete the temp file later to avoid slowly exhausting your disk space
with clutter. What a colossal pain! (Interactive applications anyway.
Noninteractive ones can use pipes and redirects to obviate the need
for an explicit temporary file, though the system probably uses one
anyway under the hood -- and deletes it for you automatically too. Of
course ALL the output from one is fed to the other, instead of a
subset selected by the user's choice...)

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

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.

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.

That wasn't an attraction; it was a redeeming feature that makes the
giant size of .ps files *slightly* more tolerable.

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

.

Loading