Re: Great SWT Program

On Nov 22, 11:49 am, blm...@xxxxxxxxxxxxx <blm...@xxxxxxxxxxxxx>
wrote:
It wouldn't matter which one you were "normally" in, although
not being "normally" in the mode where it actually accepts new text
seems rather strange.

To you, I suppose it does: I seem to remember that you've said
that mostly when you're editing a file you're entering new text,
whereas I'm more apt to be making changes to existing text.

Different patterns of usage then. But I imagine replying to a usenet
post to be something of a pain with vi, as you're alternately
selecting and deleting chunks of quoted material and typing paragraphs
of response to same. And the editing style becomes less fluid if you
have to think more about explicitly switching gears to go from adding
new text to fixing a typo or rewording a bit of a sentence you just
wrote. I can't imagine finding a natural workflow with a tool that
forced me to artificially structure it into separate and delineated
blocks of "inserting new text" versus "fixing typos and other
***". :P

In that example "what comes next" was absolutely nothing; it was just
"n:" without any more input besides the enter keypress that submits
the command.

No, it was ":n", not "n:".

Whatever; nothing came after the ":n". It was not ":n foo", just
":n". :P

I'm inclined to think that's an accurate description of your
knowledge of your platform. As a description of your knowledge
of my platform -- not so much.

???

extension type. Batch files too, when something is big enough and
"regular" enough to make it possible to exploit automation and,
moreover, worthwhile to do so.

And when you do this, you have to consult documentation, and it
takes a while ....

True, and it's a bit annoying that the scripting tools aren't a bit
less clunky, which is why it's reserved for big or especially open-
ended jobs (i.e. either for a job involving thousands of files, or for
at least hundreds in the current job and actually reusable for
further, similar jobs well into the foreseeable future).

In short, that work is done only if it will pay off in the foreseeable
future.

No normal human being can keep all of the hairy syntax of those things
in their head 24/7 and not need to refer to anything...Quick quiz:
which comes first in the argument list for System.arraycopy, the
source or the destination array?

I have no idea.

Well, there you go then.

How is one supposed to discover ..... <shrug> Maybe by reading
a good tutorial on Unix CLI tools?

*What* good tutorial? I don't seem to recall stumbling onto any, let
alone one being clearly advertised, the last time I worked with such a
system. There were man pages, as usual, and very little else.

Your tools don't let you do that save by the tedium of retyping the
names you'll be acting on, unless perhaps you can save the results to
a file, edit out some of them, and then feed the reduced list to some
other process --

I do just that on occasion.

Still awkward compared to the natural visual-selection way of doing it
that my tools support, while still enabling more archaic methods, of
course, if I decided to use CLI commands instead of Explorer for some
strange reason. In practise, even if I need the CLI (e.g. to do a ren
*.foo *.bar) for something I'd use Explorer's search to find the
files, then move the matches to a working directory, perform the CLI
command there, and move the files back. This is easy if they all come
from one source directory. It's a bit trickier if they don't, but I
can exploit the fact that Explorer's undo doesn't see operations done
from the CLI and doesn't see undeletes either: do the search, *delete*
the matches, do a same-scoped search for *, move the results, mass-
select the just-deleted files in the recycle bin and "restore", which
puts the original matches back in their original respective locations,
then rename everything in the search scope with the CLI, followed by
"undo move" in Explorer to put the non-matches back. But that
situation's very rare. Most often if I needed to do something like
this the search scope is everything with a given file extension, and
then the rename at the CLI is scoped correctly by the wildcards
anyway, obviating the need for any other commands. There's two
situations that call for mixing the two. One is this sort of rename,
but the criteria include file contents, which Explorer's search can
use to decide matches but can't be expressed as a wildcard expression
at the CLI, and the other is when I want to rename everything that
does NOT match something, in which case an Explorer move of the things
that do can be followed by a CLI rename and then an "undo move" in
Explorer. Of course there's a CLI "move" command but there's no "undo"
for this, so if the files came from multiple directories and get
jumbled into one temporary directory there's no easy way to unscramble
them all back to their places of origin at the CLI, while Explorer's
undo should remember what came from where, just as its undelete does
(recycle bin "restore" command). Most commonly I use the "move"
command in the CLI as a more powerful rename, able as it is to change
the path of any object to an arbitrary new path in general. (AFAICT, a
typical unix CLI provides *only* a "mv" command, which is used for
renaming in place as well as actually moving files.)

A lot of what you describe strikes me as relatively straightforward
to do with my tools of choice, though I strongly suspect that what
I regard as relatively straightforward here -- well, you might not
agree.

You're so used to the complexities that you no longer notice them as
much.

I *am* curious about how you sort search results by image size in
pixels, or audio by bitrate; I don't remember seeing that kind
of information displayed in graphical file browsers, but then I
don't use them much,

Explorer, since Windows ME, is aware of such data for a wide range of
supported media formats (generally anything either the Microsoft-
supplied image previewer or Windows Media Player would recognize) and
I think this is susceptible to third-party extension also. Out of the
box, it can sort a directory of MP3s by bitrate or duration, or JPEG
images by dimensions. Any Explorer window can be put in "details"
mode, and there's a View->Choose Details... option to check and
uncheck various things, but it tries to guess based on the prevalent
file types in a directory how to present it. (Sometimes it guesses
wrong but you can change it, and it will remember your overriding
choices for that directory for a while.) So you can make sure it's
including duration and bitrate, or whatever, and there will be columns
for this. It's like a "super 'ls -l'", I suppose. Clicking columns
sorts by that column. Search result windows are subject to the same
general behavior.

Even when not in "details" view sorting on the various metadata
remains possible, but you need to use "arrange by" on the right click
menu or View menu to sort the files. Views other than "list" and
"details" have an advantage to match the disadvantage of fewer files
at once (most is with "list" view) or no column heading click sorting
(only in "details" view) though -- you can manually arrange files. And
the order determines the order of traversal by the previewer, so you
can actually drag images' thumbnails adjacent to each other and then
use the previewer and arrow keys to flip back and forth between them
(useful if you have occasion to compare images for differences, even
more than having them side by side, as rapid flipping makes
differences appear to be motion, to which the human mind is especially
attuned; works well so long as the images are either the same size, or
the same crop region and large enough to be scaled to fit the
previewer window, and somewhat well the rest of the time).

Certainly I don't want to be organizing or working with collections of
media files from the CLI when a graphical shell can provide these
kinds of functionality without messy manual invoking of specific
commands.

And if something's in that list that shouldn't be it's too late so
what good does it do?

Confirmation that things are working as intended. If I have any
doubts about the proposed deletions being what I intend, I'll either
use "rm -i" or do a dry run of the delete command first.

So we're back to the unsafe-by-default problem, I see.

Recycle Bin versus "delete it and it's gone" -- yeah, that's a
separate argument. I can see benefits to the recycle-bin idea,
though to me it seems clutter-y .... <shrug>

Why? With modern storage hardware, you can completely ignore it as a
general rule except when you need to undelete something, when if it's
still in there it proves to be a godsend. You can also exploit the
delete/undelete mechanics and Explorer not considering an undelete to
be an undoable action to do a temporary move of files from multiple
directories that you can undo without clobbering some other undo
action OR manually tracking where each file needs to be moved back to;
see above. And you can vaporize a file if you really want to be sure
it's gone for some reason, using shift-delete. (Of course, at least
until the next defrag it might be forensically recoverable. There are
also "file shredder" utilities you can find that will overwrite the
file repeatedly, stomp all over it, light it on fire, and douse it in
acid, *then* delete it, if you really don't want your ex-wife's
private detective to find those steamy e-mails for her attorney to use
in court, or something like that. :))
.