Re: Great SWT Program

On Oct 4, 7:39 am, blm...@xxxxxxxxxxxxx <blm...@xxxxxxxxxxxxx> wrote:
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.

Odd that such people would program a computer at all ... :)

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.

Meaning arrow keys and other such emphatically not-weird keys? ;)

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.

I've had occasion to use xfig to make diagrams for inclusion in LaTeX
documents. The limitations get annoying, though. Ultimately it is
useful if you can have a high level representation of graphics -- for
example, in a math document just include "the graph of f(x) = x^3 - x,
x in [-3...3], y in [-3...3], graph lines thick, axis lines thin, grid
lines clear, axis ticks short and thin, grid intersections thin, grid
scalee 0.5" or whatever and have the computer actually generate the
plot on the fly.

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.

Another thing we want the computer to fill in for us.

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!

Actually keeping a record seems useful unless you're sure it's a one-
off, but being able to edit the script (one-off or not) in a nice IDE-
like editor, complete with the ability to test it in some consequence-
free way, would be very useful. Combine that with my transactional-
integrity ACID filesystem notions and the obvious test capability is
this: you tell it to "debug" and the system quietly spawns a ghost
copy of the filesystem as a RAMdrive. Of course it doesn't actually
copy everything; the RAMdrive it creates just "ghosts through" to the
real filesystem and then applies its own recorded transactions to
simulate a modified copy. So the script deletes three files, the three
deletion transactions are posted to the phony filesystem, and the real
filesystem is unmodified. Query the real filesystem and the files are
there. Query the mockup and it shows you every other file on the hdd
but those three are missing, because it sees deletion transactions for
them that postdate the hdd version. (This gets problematic if the real
filesystem is updated; if one of the three files is modified on the
real filesystem, the mockup will probably show it again, seeing it as
having been "deleted" and then "a new file with the same name written"
a bit later. But it suffices.) Now if the script ran amok deleting
things you don't want gone, you're not fubar'd -- just edit the script
and retry, and you'll see the effects on a *new* mock copy of your
filesystem. Eventually it doesn't do anything drastically wrong and
later still it works perfectly, and then you run it on the real thing.

Currently, you need to explicitly copy (at great waste of disk space)
the chunk of filesystem it may modify and make DAMN sure it won't
escape from the directory it's launched in up to parent directories if
you don't want to risk massive data loss. Of course this is really
only important for scripts that will overwrite or delete things...

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

It's one keystroke. If I have, say, notepad open, and I want to put in
calculated values, I can do this:

First calculated value: start->programs->accessories->notepad (with
mouse); a bit slow. (You'd type some command line like :r!calc x+y or
some such, probably taking a similar amount of time.) Then put in
calculation, hit ctrl+C to copy result, alt-tab (notepad comes back to
the front), and ctrl+V to paste. Calculator left running of course and
now the next window behind Notepad.

Second calculated value: alt-tab, type calculation, ctrl+C, alt-tab,
ctrl+V. Four keystrokes (admittedly chords) plus the actual math
expression. Yours I assume includes a command name at least as long as
"calc" and the math expression, for at least the same number of
keystrokes, plus mode switches, plus other cruft (:r! or whatever),
plus at least one space. Looks like the Windows method wins by a
handful of keypresses. Only the first use is slowed by having to go
find the application to launch, because you just leave it running
until you're sure you won't need it again for a while; the beauty of
multitasking instead of call-chaining. :)

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>

The problem being needing to build it over and over again and know how
to build it. Really, you should get the parts, the most usual useful
prebuilt tools using those parts, AND the ability to save the results
of combining the parts in a novel way so that you don't have to
specify it manually each and every subsequent time (and perhaps forget
how you did it someday).

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.

The file names might have nothing in common that you can use to
control a search-and-replace so that it "hits" all of them and
"misses" everything else. I don't know what you mean about "mark
them"; automatic marking amounts to the same problem again if they
have nothing in common textually. Manual marking presumably consists
of something like type something, down, home, type something, down,
home ... with the "something" being shorter than "Attach: " but
unique, and then using search and replace to expand them all. Still a
fair bit of typing. Of course I'll now tell you that with plain old
Notepad this can be easily done by a complete novice with only *three
keypresses per line* except the first: go to start of first line, type
"Attach: ", shift-home, ctrl+C, down, ctrl+V, home, down, ctrl+V,
home, down, ctrl+V ... yep: the notorious Windows clipboard strikes
again!

Now if vim can automatically prepend a chosen prefix to the start of
every line pasted in from an outside source, *then* you *might* be
able to beat that with the directory listing command auto-prepending
everything with "Attach: ". But I doubt that's easy, if it's even
possible.

And I did mention, didn't I, that a normal Windows mail client
obviates the need entirely by just letting you select a batch of files
to attach, and attaching them, or even cherry pick files from multiple
directories one at a time?

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.

It's no easier to use and it is harder to learn, in other words.

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.

Define "current directory"; the Windows equivalent for these dialogs
basically *is* "the last place you used them". You're not stuck with
only what's conveniently reachable from where you launched the
application, is all. You can be running six things at once and each
with its own location the file save or open starts from. It does annoy
me when they insist on always reopening at "My Documents" or some such
instead of remembering where I'm actually working at the time, but
when they do, that becomes the "current directory" -- it's wherever
I'm currently working.

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

It sounds like an awful lot of work and complexity compared to simply
selecting the files and clicking a button in the mailer!

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.

How broken of it.

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.

You could with a file browser, but you were entering command lines
blind as I recall. It could do anything or fail spectacularly with one
little typo if you use a relative path or other such prefix and
mistype or misremember something. And of course typing the command in
the editor you don't even have the benefit of whatever autocomplete
functionality your shell might provide...

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.

All that "state" includes "where you left off" and the like. What
isn't preserved across sessions by the software needs to be preserved
across sessions in your head, adding to the mental burden of the task,
in a way that get vastly worse with frequent exits and restarts.

Versus in Windows where you'll task-switch less often and when you do,
you aren't actually exiting anything, generally. You just tab away and
back and it should be how you left it. Insertion point in the same
place and all.

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

Are you calling me a liar?

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.

I know something about how command line shells work in general, and
some unix command names, at any rate. :) (The environment-inheritance
behavior I describe is identical in MS-DOS, although the directory
listing command is "dir" rather than "ls".)

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.

If you're willing to navigate the filesystem blind, of course. But
that way lies frustration, hair-pulling, "file not found" errors by
the bushel, and madness.

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.

So much for automation though.

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

But not "file dialogs"? I mentioned those well before "that last
sentence". ;)

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.

On any sane window system, one extra keystroke each switch. There's
also the nifty little bonus feature that the external tool you're
using besides your editor actually *has* a window. Yes, that's right,
it will actually possess a user interface, allowing you to actually
see what the heck you're doing in it instead of issuing commands blind
and praying!

As for "more controllable" -- I dunno, maybe if you're not very good
with the tool.

More controllable period. Anything that actually has a user interface
is more controllable than something where you push a button and off it
goes autonomously. And of course there's the added bonus feature of
interactivity: you can tell the tool to do X, get feedback, and then
use that to decide to tell it to also do Y. If you're calling
something from your precious vim you need to actually encode "if X, do
Y as well" on its command line and pray you don't muck up its command
syntax for this to happen. Or actually launch it twice; what a PITA.
I, of course, just launch it the once, do something in it, examine
something in it, do something else in it, and then copy and paste
something. No command syntax to worry about at all, and certainly no
conditional branch command syntax. Because my external tool has a UI
of its own it can provide feedback and interactivity of its own.

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.

Eh? I don't recall a "!" in the other one, your "ls" example...

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.

That sort of thing would explain all those unix tools that, when you
just run them to try to get some kind of UI or help, just sit there --
no more shell prompt and no feedback of any sort until you manage to
find a keystroke (often ctrl+C) that aborts it. :P

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?

Perhaps, but it seems messy tangles of cabling are hanging out of an
open case instead of being neatly packaged here. At least software
doesn't get prone to dust getting in and screwing up the heat
dissipation mechanics, so it's only a usability/esthetics problem when
the system's guts are exposed to the user.

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.

"fmt" might be proven formally, for all I know, or care; the point
still applies since you might launch something that isn't as
thoroughly tested and debugged, with Christ alone knows what
consequences if it then crashes while attached to the editor that also
holds your unsaved work...

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.

This naturally makes me wonder how you put words like "undo" into your
posts, if starting to type it would actually undo something ... :)

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

Let's hope not. That it takes many 900-line posts to even start to
explain the basics of your tool of choice makes it clear that it's not
for me, or most people for that matter. I mean sometimes complexity is
necessary. But it's a *text editor*. And it *isn't even emacs* we're
discussing. :P

Perhaps we should consider anything whose "required reading"
documentation (that without which you can't use it productively at
all) runs to over 100 lines a "feeping creature" ... it's arguably a
form of bloat after all. :)

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

vim is not for you, that's clear.

Or anyone else who isn't a memorization whiz and does prefer to be
able to actually see where they're going when they navigate or perform
work of any sort. :)

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.

Defaulting some of those things to off might've been nice.

And the paperclip was just *wrong*.

:P

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

It's a darn sight better than "well, you know you can actually type in
text to compose a text file, right?"
"You can??!! How? Please tell me!", which would be the likely
analogous situation involving vi ... :)

I'll take navigability and searchability over comprehensiveness
anyday.

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

Not really; comprehensiveness that's tucked away somewhere where I'll
never find it doesn't benefit me a whit, unlike mere adequacy where I
actually can find it.

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.

What ever it is, it certainly doesn't pass *your* muster where if it
isn't hand-hackable in a text editor it sucks. :)

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

Devil-grin.

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

Emacs. It's so changeable and configurable that if you use a copy that
isn't exclusively yours you have no way of predicting how it may
behave. The previous user might have rebound every key to "blink and
beep" to make it emulate vi, for all you know. ;)

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

Most illogical.

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

Agree with me where? I didn't display any partisanship until after you
did. Well, unless merely mentioning the (handy!) charmap tool is
somehow sufficient. :) (And you *still* haven't indicated that you
have anything like its functionality. You can apparently blind-insert
unicode into your stuff, and maybe even with a graphical system see
the glyphs you typed after the fact, but if you're looking for say U-
umlaut and can't remember what arcane key combination summons it forth
from the netherworld, you're screwed. I, on the other hand, may forget
the alt+numpad combo for it, but all I need to do is fire up charmap,
pick it out *visually* (a U with two dots above it is easy to spot),
and copy it, then paste it. (Oh my -- the Windows clipboard strikes
again!)

[appears to accuse me of lying again and then...]

I don't accuse you of "lying" in the sense of deliberately saying
things you know to be untrue. However, sometimes I believe you
[insult deleted]

Oh boy. Here we go again...

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.

I don't see how they can restrict others from *re*distributing it
freely, given the requirements of the GPL that they must adhere to.

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

Long-time Unix users probably either know how to use vi, or know to
avoid it. :P I'm talking relative newbies here. I suppose it *was* too
much to ask that they use the standard ctrl-alt-del for this purpose
though. :)

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

I hope to Christ I never run into that in the wild ... and that just
from hearing you hint about its horrors here.

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>

Well, it isn't X or the X client. XFMail hung first, instead of the
whole thing just dying. And that seems to clear the client's name too.

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

A luxury J. Home User doesn't have of course.

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.

What the hell is that supposed to mean? :P

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?

Made-up example but meant to reflect the reality of trying to make
something work on unix that didn't "just work" right away: there's
always some complicated stuff needed to even interpret the error
message (assuming the system was kind enough to provide even a really
cryptic one, rather than silently do nothing or quietly behave in an
unexpected way instead), let alone fix whatever the cause is.

On Windows, either it works or it's broken. If it's broken, *you*'re
not expected to fix it; which means there seems to be more attention
paid to making the basics at least work out of the box for everyone.
The only times I've had Windows stuff fail out of the box have been:
a) A few cases involving things that work at the device driver/kernel
mode level; and
b) Something that came with several installer versions for different
system configurations, and that were not properly labeled so that it
would be evident which to use on systems that had hybrid
characteristics in a relevant area.

It should be noted that the which-installer-is-the-right-one-guessing-
game case was ported unixy stuff instead of native. Native would
probably have had a single installer detect the relevant configuration
stuff and install the appropriate version of everything automatically,
instead of a not-necessarily-expert user having to make these
judgments manually. It's obvious which of those approaches is going to
be more robust...

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.

That figures. There *is* a reason, and it involved how they're
implemented, but I'm guessing there is *no* good reason from a problem-
domain perspective for such a limitation. So the user encounters
arbitrary restrictions on seemingly-useful functionality that cannot
be explained without learning how the damn code works under the hood
(which isn't supposed to be necessary for the end user at all). How
typical.

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.

Erm ... *what* ability to get meaningful information out of *what*
online help? Unnavigable help with no or concealed search
functionality isn't amenable to extracting meaningful anything.

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.

No, but I'm not talking about that sort of thing. I'm talking about
the specific individual tools (including anything used to display
help) all varying idiosyncratically so there's no one thing or small
set of things you can learn and then you're golden, because you can
easily access the documentation to quickly find anything else out;
instead every new app adds its own bunch of stuff you can't learn
because you can't even access the help properly ... well, unless of
course you have live guidance, or perhaps a cheat *** or something
like that.

[school and computers anecdote]

Ah; your school provided years of shelter from Windows exposure. I
see. But meanwhile the PC grew up and became powerful ...

I guess working with mainframes/minis for years got you used to having
to wrestle with the system to even find out how to make the UI work
properly, or use cheat sheets and experts in lieu of missing/
unnavigable/unsearchable help or something?

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.

Text-mode being the operative phrase here. (Though yes, a lot of the
times JS is evil.)

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.

:P

It figures.

How did you get the "u" in "um" then, since vim apparently treats that
as "undo" rather than "insert the letter 'u' into the open
document"? :P

.

Quantcast