Re: Great SWT Program

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

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

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.

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.

[ snip ]

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.

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

[ snip ]

(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 pretty sure that whatever might be wrong with "modern convenience
foods" doesn't explain any deficiencies in my sense of humor.

[ snip ]

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.

[ snip ]

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.

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.

[ snip ]

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.

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

It's possible that a lot of the ways in which I use this stuff --
well, someone else would just use a different tool. I'm pretty
sure whatever you're imagining doesn't really correspond to how
I use these features, but I don't have the time and energy ....

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.

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

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.

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.

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

Very true.

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

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

[ snip ]

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

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.

[ snip ]

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

<shrug> We're not going to agree here, but I maintain that if
I have to choose between something expert-friendly and something
novice-friendly, well, I like having the choice and will sometimes
choose the former. Tools that are friendly to both novices and
experts -- that would be ideal, but I'm not sure there are very
many of those.

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

[ snip ]

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.

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. I'm not saying
what you're describing wouldn't be useful -- I can imagine
circumstances in which it would -- but they're not what I'm
talking about. 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.

[ snip ]

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

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

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

Obvious? No. But easy once you learn it.

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,

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.

so any scoping would be arcane, and an external tool
would just act on the entire file anyway.

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

I don't suppose it even auto-
saves before invoking the tool?

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

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.

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.

That would be annoying if it were what happened. But it's not.
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. If files
are involved, I'm guessing temporary files rather than the actual
file being edited.

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

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.

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

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.

We're talking about different things here. I'm not saying what you're
talking about wouldn't be useful, but it's pretty different from what
I'm describing.

[ snip -- losing a bit of context, but I don't think it matters
much here ]

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.

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.

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.

Very true. If I wanted that functionality, I'd use other tools --
perhaps a makefile. It would be more trouble to set up than what
you're describing, true. But for what I'm talking about, the
ability to recalculate isn't needed.

[ snip ]

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.

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

[ snip ]

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.

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.

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.

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.

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.

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?

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

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

[ snip ]

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

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.

[ snip]

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

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

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

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.

[ snip ]

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 your saying
things about those text-mode tools that, as best I can tell,
aren't true. We'll have to agree to disagree about whether
they are simply obsolete junk that no sane person would use,
but when you make claims that are *not* a matter of opinion
(such as claims about 80x24 only), well ....

[ snip ]

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.

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.

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

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.

The four failure
scenarios I'm familiar with on unix are:

[ snip ]

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

I've heard stories like that too. I don't know how common they are.
My mileage installing Fedora Core 4 on a stock Dell PC was different.

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

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

What tool was that?

[ snip more tales of woe ]

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

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?

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?

A guru helps. If you can be patient, the Fedora mailing list seems
pretty helpful in telling people how to recover from bad situations.
But that presupposes that you have another computer from which to
get online. <shrug>

[ snip ]

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.

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

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.

I do wonder why your experience is so different from mine, and
which is more common. Huh.

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.

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.

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.

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

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.

[ snip ]

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

Exaggeration for effect, I'd say.

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.

Sure. Are you volunteering? I'm not; I don't have the time and
energy, though I'm sure it would be interesting and valuable.

While we're waiting for someone else to do this, what do we do?

This doesn't sound much like my experience. Of course, I do things
like defining environment variables for directories [ .... ]

[ snip ]

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 use a mix of both. It works for me.

[ snip ]

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.

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>

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?

We were, and then you said "shortcuts", and I interpreted that to
mean "symbolic link", thinking you meant "shortcut in the Windows
sense". Come to think of it, maybe that wasn't what you meant.

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.

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.

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

Well, not if you put their definitions in one of the files read by
the shell when it starts up. As I do.

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

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

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

[ snip ]

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

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

I guess it's a good thing that I don't regard any suggestion that
my mental health might be less than optimal as a mortal insult.
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.

[ snip ]

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

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.

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.

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.

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.

"Whatever"?

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

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

It could easily be that I'm just not as smart as I think I am.
Exactly how smart *that* is varies from day to day. :-)?

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.

Yeah ....

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.

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

Yeah ....

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

[ snip ]

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.

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

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