Re: Great SWT Program



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

How else do you account for the many, many programs that make
automation difficult if not impossible?

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

If it wasn't on the keyboard of one of those old-time text
terminals .... (I can't actually remember whether any of them
had arrow keys and am too lazy to research it.)

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.

Sounds like a job for gnuplot. I think I saw something recently in
comp.text.tex about a package that lets you invoke gnuplot directly
from LaTeX.

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.

Yes, quite. Do you know of any GUI tools that provide this feature?
It seems rather specialized.

[ snip ]

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.

Sounds interesting. When should we look for the first release? (Sort
of a :-) .)

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

Yeah. Which is why when I'm writing a script that does that, I'm
apt to start out by putting "echo" in front of the dangerous commands,
so at least I can preview ....

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, let's try a simple example -- computing the number of hours in
a week.

My way: Type input for "dc" calculator program into file I'm
editing:

24 7 * f

Type ".!dc" to pipe this line to "dc" and replace it with the result
(168).

In some ways it *is* a crude hack around not wanting to deal with
multiple applications/windows. I often find it useful. <shrug>

It doesn't work that well -- possibly not at all -- with commands
that invoke an interactive program. If that's what I want, I'll
do it another way ....

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

Yeah. Maybe. Since it's not clear we can have that right now ....

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.

These lines are the output of a directory-listing command and are
consecutive in the file being edited. Trying to find them among
unrelated lines is a non-issue.

Manual marking presumably consists
of something like type something, down, home, type something, down,
home ...

Dunno what you mean by "manual marking"; I was talking about either
setting (invisible) named marks, the old vi way, or using vim's
visual mode.

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!

In vim (and this would work in vi too as far as I know):

Go to first line. Type command to insert "Attach:" at the start
of the line ("0iAttach: <esc>"). Move down one line, type "." to
repeat the insertion command. Move down one line ....

vim of course has its own internal clipboard (27 of them, in fact).

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?

I hadn't realized it was possible to use a file-selection box to
select multiple files matching a pattern. That does sound useful.
As for cherry-picking files from all over .... Perfectly possible
from mutt; for that I'd do the attaching from its (text) menu,
which allows for browsing the filesystem.

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.

Yeah. But it allows me to stick with a tool I know and like, and
which has other capabilities I find useful.

[ snip ]

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!

Which you can do -- except that it's all text, and I don't know of
a way to select multiple files matching a pattern.

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.

I wonder now whether it *can*, but I just don't know it. (Don't
bother to tell me how this demonstrates the superiority of a GUI.
I have little experience with GUI mail programs so can't say how
obvious I'd find this feature .... )

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.

For suitable definitions of "blind".

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

Actually you do. (I suspect a lot of those text-mode programs
use the readline() function, which provides that autocomplete
functionality as well as a command history.)

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.

You can more or less have this with vim; its default behavior is
to save a lot of "state" across sessions. I find that more annoying
than useful, so I have it turned off.

May be a "your mileage may vary" thing again.

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

Are you calling me a liar?

No. I'm saying you're mistaken.

[ snip ]

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 you're willing to navigate the filesystem using autocomplete
features. Not quite as pretty as point and click, but far from
unusable. In my opinion, I guess.

[ snip ]

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.

Yes, invoking interactive tools .... In practice that seems not to
come up.

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

It was there, in the original example anyway: "r!ls *.tex"

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

Probably.

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.

That's not how it appears from my perspective; from my perspective,
vim hooks seamlessly into a system/paradigm I find familiar and
useful.

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

And your whizbang GUI tool might crash because of its *own* bugs,
losing 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 ... :)

I thought you knew about vi(m) being modal.

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

We might as well be discussing emacs, really -- emacs fans may not
like my saying this, but I think vim is starting to provide a similar
set of functionality.

As for it taking many hundreds of lines to explain the basics --
I'm not explaining basics here; I'm describing some features that
make the tool attractive to *me*, as someone steeped in the Unix
mindset and willing to do some learning.

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

Well, the first lesson in the interactive tutorial, which I think
is enough to get people started, runs to .... just over 100 lines.

[ snip ]

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

Sure it does; if I wanted to hand-hack a man page, I'd uncompress
the source, get a text file, modify it, compress it. Same as if
I wanted to change a PDF file produced by LaTeX -- I'd edit the
LaTeX source and rerun commands to generate the PDF.

[ snip ]

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

But this is kind of a problem with any system that's configurable,
isn't it? (By the way, emacs does have a "vi emulation" mode.)

I had a student a while back who liked to remap the keyboard
Dvorak-style. Now *that* was disorienting.

[ snip ]

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

That's not how I remember it: What I remember is you making claims
about my preferred tools, and someone else saying "not so, vim
supports Unicode", and my reporting on some experiments to confirm
that, or not, and your being consistently disparaging, and my
getting defensive ....

Well, whatever. I think I might be about ready to wrap this one
up; it's getting to be too much of a time sink, though it's been
fun in its way.

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 didn't ask. I actually didn't know -- needing something like
this just doesn't come up very often for me -- but it turns out
that there's something called "Character Map" in one of GNOME's
menus, and it behaves very much like what you're describing.
("But it doesn't paste to the clipboard!" ? Actually I think
it probably does paste to GNOME's equivalent of that; it also
pastes to X's possibly-primitive clipboard. I didn't have any
trouble getting some Cyrillic characters pasted into a file
being edited with vim.)

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.

Well, no. vim will display a list of allowed glyphs and the
arcane key combinations, etc. That's admittedly not quite as nice
as what you describe, but it's not as bad as you make it out to be.
As usual.

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

Yup. As long as you say things I believe to be factually untrue,
whether deliberately or not, I'll consider myself free to dispute
them. I don't think that's an insult, and if you think it is --
I think that's such an unreasonable position that I'm not going
to cater to it.

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.

Now that you mention it, I believe you're right. No idea what I was
thinking, perhaps that if you wanted to get RedHat's stuff directly
from them you have to pay. I'm not sure about that.

[ snip ]

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.

And yet there's a regular in alt.folklore.computers who claims she
was able to teach non-technical people all they needed to know to
be productive with TECO in an afternoon. But that was long ago.

[ snip ]

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

That you seem to have a knack for getting Unix to misbehave.

[ snip ]

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.

Actually I think I was wrong about that: It's not a restriction
imposed by the implementation, because the ".." entry in a
directory, pointing to its parent, is apparently a hard link.
As best I can tell from a quick Google search, disallowing other
hard links to directories is an attempt to avoid some sort of
unbounded recursion. You're right that it seems like an annoyingly
inconsistent restriction.

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.

I am able to get meaningful information out of man and info pages,
and not because of some superhuman powers, either (which I don't
claim to have, an assessment with which I'm inclined to think
you'll strongly agree). I'm sure there was a time when I found
them baffling. Experience helps.

[ snip ]

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?

That's about it, yes.

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

Insert mode versus command mode. I thought you had used this tool,
at least a little.

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



Relevant Pages

  • bringing ee up to date
    ... -is a simple screen oriented text editor. ... +.\" To format this reference page, use the command: ... -Turn off display of information window at top of terminal. ... -.Ss "Control keys" ...
    (freebsd-hackers)
  • Re: When will MS fix the WinCE USB Mass Storage Problems?
    ... In SCSIGetSenseData under SENSE_UNIT_ATTENTION, some keys reported ... I think the spec does not say that this is a valid response to this command, ... In the mean time I got about 50% of my non-working USB keys working. ... Attachdevice fails, the sequence of state-transitions there, fails. ...
    (microsoft.public.windowsce.platbuilder)
  • Re: Intemittent operation of some keys
    ... Laptop keys are fragile beasties, I don't recommend prying them off ... I have had computer keyboards since 1981 and I learned to type on an old Remington typewriter that you really had to smack the keys to make a good impression on paper. ... Laptop keys are typically closer together. ...
    (comp.sys.laptops)
  • Re: Keyboard lubricant?
    ... >>Now it seems as if the keys are harder to press. ... > It take an extremely small amount of silicone to do the job. ... Most of the problems I've had were with laptop keyboards. ... Lubricant hasn't fixed one yet for me. ...
    (sci.electronics.repair)
  • [PATCH] input / keyboard / Scancode Set 3 support broken
    ... autorepeat for all keys. ... One example is the LK461/46W series of keyboards from Digital ... These keyboards support Scancode Set 2, but for some keys this support is ... Scancode Set 3 works perfectly if all keys are programmed to give make/break codes. ...
    (Linux-Kernel)