Re: Great SWT Program

On Nov 19, 7:21 am, blm...@xxxxxxxxxxxxx <blm...@xxxxxxxxxxxxx> wrote:
Four keypresses rather than two. Doesn't seem like "much more work"
to me. As for switching into command mode -- normally I *am* in
command mode.

During complex edits you'd have to flip back and forth a lot, if the
edits involved inserting new text as well as rearranging pre-existing
text. 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.

And didn't a : indicate a command to operate on an external file, or
to launch via the shell, or something of the sort, earlier?

So once again you know better than I do how this application
actually works .... (":" indicates that what comes next is an
'ex' command. Some of those commands do involve external files
and/or programs. Some of them don't.)

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.

I'm betting that there is none or else the only ones involve a lot of
typing and even debugging of some sort. Trying to do any sort of
complex mass file manipulation from a command line has always put me
in mind of fumbling around and bumping into furniture in the dark.

Whereas trying to do it from a GUI always strikes me as unbelievably
tedious. But apparently I've been unaware of some of the capabilities
of graphical file browsers and selection dialogs. I don't suppose
you also don't know everything .... No, no, of course not.

There may be a trick or two I haven't picked up yet, but I know the
ropes well enough to work efficiently (and to know when I need to
automate). Don't forget that having graphical tools does not render me
mysteriously incapable of using a command prompt; on rare occasions
the command prompt sees use, for instance for mass renames of
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.

Bull -- if it involved any kind of regexp or scripting you'd need to
refer to the reference manual for the syntax and semantics of the
language involved, unless you're superhuman in some way. :P

Not superhuman, but experienced with my tools of choice.

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. Can you program
a mid-sized Java program without ever referring to any of Sun's
Javadoc (or the tutorial, or Thinking in Java, or any other similar
information source)? Quick quiz: which comes first in the argument
list for System.arraycopy, the source or the destination array?

Which in practice doesn't seem to happen very often, and if it
does one can use "xargs".

That again! What *is* it, and how is one supposed to discover that it
exists?

So before doing anything that might be difficult or inconvenient
to undo, I'll first preview it in some way (e.g., echoing the
list of selected filenames rather than applying some command
to them -- and no, that doesn't mean I have to type the whole
selection command(s) again, since my shell keeps a history of
previously-typed commands).

Still awkward compared to using visual tools. Visual tools also let
you use a search to narrow things down, and then cherry pick a subset
of the search results to do something with, in case some of the
selection criteria are AI-complete or at least ridiculously hairy.
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 -- all of this STILL more tedious and painful than using
a GUI, and all you can see when doing the manual-weeding stage is a
list of file names without any other information about the files.
Whereas I can examine their modification dates and other filesystem
metadata, preview image files, sort the search results by modification
time or other criteria, including with images by size in pixels, with
audio by length or bitrate, etc.; you could only do that by using a
primitive means of task switching and typing names from the list to
launch the files or get details about them with ls -various-hairy-
options thepath/thefilename.ext or similarly.

All of which also requires poking around in man pages to find which
exact -various-hairy-options to use here and there, OR a huge amount
of memorized information, far more than a Windows user needs to do the
same job equally fast or faster.

If I want to be sure I see the output, I'll either redirect it to
a file, or pipe it into a pager such as "less". For "rm", I'm apt
to do "rm -v" (for "verbose"), so I do get a list of what's being
deleted.

And if something's in that list that shouldn't be it's too late so
what good does it do? Of course, Windows gives you plenty of time to
recover a mistakenly-deleted file before it's *really* gone, via the
Recycle Bin. (Except if it's deleted with a "del", e.g. in a batch
file. A good reason not to make scripts actually delete things on
Windows, but rather make such a script move them to someplace where
you then select what shows up there and hit del. This gives you the
possibility of recovery if you later decide you should have kept one
of them.)

True. Of course, that's not the only way to make an opportunity to
correct potential problems.

No; a recycle bin would be useful instead of deleted files being
promptly vaporized.

Errors creep in the less double-checking, noticing stuff, etc.
opportunities the user has.

It would seem so. But the double-checking mechanism -- for
example, "rm -i" (prompt on every file) isn't perfect either,
since one becomes so accustomed to typing 'y', 'y' [ "yeah, yeah,
enough already!" ] that it's easy to delete the wrong thing. Or
that's my experience anyway.

Confirmation dialogs have the same problem. The Recycle Bin is better:
most deletes actually just move files there and record where they
originally were to make putting them back more automatic than it might
otherwise have been. If you find you miss the file, and haven't
emptied the bin too recently, it should still be there to recover.
When the bin gets too full (configurable) it starts dropping (i.e.
really deleting) the least-recently-deleted items to keep the total
megabytage in it below a threshold. On a modern system you can afford
to give it a full gig and avoid manually emptying it so almost nothing
is truly deleted until a year later.

.

Relevant Pages

  • Re: Big uh-oh
    ... RD bypasses ... the Recycle Bin. ... If you used that command from a command prompt ...
    (microsoft.public.windowsxp.general)
  • Re: Preventing users from overwriting existing data
    ... There, you can Lock the control if its value is not NULL, and unlock ... > assume that I would add a command button and enter the code for the On ... >> Simplest would be to set the Allow Updates property of the Form to No; ... >> Edits property to Yes; set it back to No in the form's Current event. ...
    (microsoft.public.access.forms)
  • RE: Forms Add, Edit or View
    ... Eric the Rookie ... I want to use the same form for all Data Entry, Allow Edits, Allow Deletions. ... The command buttons will be Add, ...
    (microsoft.public.access.modulesdaovba)
  • Re: Bookmark bonanza
    ... >even make a couple keystrokes; just open me up to the last sentence I was ... press Shift+F5 (the GoBack command). ... Pressing it twice more will go back to the previous two edits, ...
    (microsoft.public.word.docmanagement)
  • Re: word 2007 and combining edits from different users...
    ... On the Reviewing tab, under Compare, click the Combine command. ... you do is combine the first set of edits, ... Microsoft Office MVP ... seems to be able to combine the edits of 2 persons, ...
    (microsoft.public.word.docmanagement)