Re: Great SWT Program

In article <7b967285-5495-4b93-8728-b13b94f4f44c@xxxxxxxxxxxxxxxxxxxxxxxxxxxx>,
<nebulous99@xxxxxxxxx> wrote:
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

I can believe that your description might be accurate for a
new user. Since I've been using this tool (vim, and vi before
it) to compose many kinds of text for almost twenty years now,
however, it bears little resemblance to my perception of what
I'm doing. All of the mechanics of switching between modes,
remembering what to type to do stuff -- it's no more conscious
than deciding which pedal to press to make the car go faster and
which to press to make it stop. I guess it's possible that it's
actually costing me lots of brain power, in ways I'm not even
aware of, but I'm not sure how one could measure that. That it
seems obvious to you is not, frankly, very convincing to me.
After all, you think my brain's broken.

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

This is so silly .... I said that ":" indicated something about
what came after it, you said "nothing came after it", but clearly
something ("n") did .... Whatever.

[ snip ]

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.

Right. I don't have the entire Java API in my head. So?
Where did I claim I did? Oh right, you apparently *think* I said
something like that, but -- a misunderstanding, possibly explained
in another post today.

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.

I also am not aware of anything for Unix analogous to Sun's Java
tutorial -- i.e., something widely recognized as canonical. But a
Google search for "Unix" and "tutorial" turns up lots of hits.
I can't be bothered to sort through them and look for good ones,
but the first few at least look promising. Whether the situation
has improved dramatically since you last worked with Unix --
hard to say, but it seems possible.

[ snip ]

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,

"Working directory"? Isn't this as clunky as those temporary files
I sometimes use to get around not having easy access to a clipboard?
Just askin'.

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:

So you're exploiting the fact that the interface lies to you.
Uh-huh.

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

Very interesting. I'm not sure I followed all of that; I suspect
I'd have to boot up a Windows system and try stuff, and I can't be
bothered right now. Maybe some other time. The fact that "undo"
puts renamed stuff back into its previous location -- interesting.
I wouldn't have suspected that, though I can sort of vaguely
imagine how it might be done.

(You are correct that the Unix "mv" command performs both renames
and moves. The Linux systems I've used (RedHat and Fedora) also
provide a "rename" command that will do the kind of mass renames
that previously required a shell loop. FYI, I guess.)

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.

Probably so. But this has never been about what's easy for a
newbie -- or at least, that's not what *I've* been arguing about.

You seem to be similarly adept with features that wouldn't
be obvious to a newbie -- or at least, not to this newbie.
Of course, with my poor broken brain .... (Are you sorry yet
you used that phrase? No, probably not.)

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

"For a while"? that seems a little, um, imprecise and
unpredictable? but I may be projecting my overall impressions of
Windows as a platform on which strange and unpredictable things
happen routinely.

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.

Interesting ....

[ snip more stuff that might be useful next time I try to get
better with Windows .... ]

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