Re: Great SWT Program

In article <6de9eaae-91db-4263-8dd5-4f2044a559e3@xxxxxxxxxxxxxxxxxxxxxxxxxxx>,
<bbound@xxxxxxxxx> wrote:
On Dec 3, 8:02 am, b...@xxxxxxxxxxx (Bent C Dalager) wrote:
We /know/ that you hate it when you're proven wrong

How can you *possibly* know in advance how I'd react to something that
hasn't even happened?

I suppose I could, somehow, but in this case the empirical evidence is
overwhelming.

Certainly not. If it's in a file, you just source the file from the
shell.

What are you babbling about? Regardless, even if you made the shell
treat the file as input (manually invoking the command interpreter
with redirected input? How hackish, and with the input source having
to be blind-specified, crufty too)

I suppose it /would/ be crufty if you were the one who designed it.

it would treat the ENTIRE file as
input rather than the one specific line of interest. If you're going
to do something like that you may as well just make a proper shell
script, copy the line into that within the editor, exit, and invoke
the shell script.

You can certainly do that if you prefer. It still seems a bit
over-elaborate and bothersome but I suppose it would get the job done.q

It isn't, because there's a system-wide clipboard. It's YOUR tools
that each have their own separate clipboard (if they have one at all)
so you can't copy-paste between them, remember?

Well, /I/ certainly can copy-paste between them but it has become
clear that /you/ most likely could not.

I can't name it offhand, but it does exist, ***.

Profanity implies insecurity

No, it implies FRUSTRATION, because you are such a COMPLETE IDIOT and
I have to say everything SIXTY THOUSAND FUCKING TIMES and you STILL
DON'T GET IT! Grrr!

While you are obviously working on it, I don't think you've yet said
/anything/ as much as sixty thousand times. Except, perhaps, if
"fucking" is some sort of Twisted-SI unit on the order of 0.0001 or
somesuch.

this surprises me, because if such a
tool existed, one would think it would be easy for you to find and
point to.

I'm sure it is, but I'm not about to waste my time finding one when I
don't currently need one for anything. If you want to find one so
badly, go fucking Google it yourself. I'm not your personal servant.

And, of course, in the mean time, I have that tool at my fingertips
should I ever want it.

Why are you so uncertain about the capabilities of your
chosen tool set?

I'm not. Stop putting words in my mouth. It makes you a liar. You
didn't seem to like it the last time I called you a liar, so you
should really stop with the deceptive behavior. Frankly, you're
getting to be almost as bad as emacs for that.

It really is cruel to remind you of your own rules, but you appear to
have lost an argument again.

So you have several dozen pages of man pages laying around, and you -
the user - have to browse to find the correct one of several dozen
fiddly little switches to type to do a particular conversion, memorize
it, exit the man page viewer, and then type a command line in
containing the switches you need, instead of accomplishing your goal
in a fraction of a second?

No. There are no command line switches involved in a straight-forward
conversion.

This is ludicrous. You have a converter with no immediately obvious
indication of how to use it at all, or perhaps even that it exists. A
Windows user has a converter with several associated icons for various
conversion destination types.

Not only is the Windows converter also not immediately obvious - you
don't even know if a suitable piece of software exists at all!

That's a lie.

The rules, remember, the rules!

And what good are the icons going to do anyway?

They a) display the functionality clearly and cleanly

And how, pray tell, would an icon "clearly and cleanly" symbolize a
conversion from GIF to PDF as opposed to a conversion from TIFF to
JPG?

and b) actually
provide direct access to the functionality on the spot, in much the
way the long and disorganized man pages on your side of the fence
don't.

man pages aren't used to access Unix utilities in the first place. It
is becoming clear why you never could cut it in a CLI.

convert blah.gif blah.pdf

is a suitable command line. I challenge you to spot the -foo option.

It's missing, which means it will do who knows what default
conversion. Unless the default destination type happens to be pdf,
you'll likely end up with a file named "blah.pdf" but actually in jpeg
format or something like that. Unless, of course, you just get an
error message.

In the real world, of course, the above will convert from GIF to PDF.

Of course, even leaving aside that, I mentioned earlier how your
preferred interfaces tend to replace a mouse click or two with 25 or
more keypresses. Interestingly, the command line you gave above,
missing information as it is, is exactly 25 characters long. And
that's with four-character file names (plus three-character
extensions) in the current directory. Imagine how much worse it would
be if they were in two different directories and had longer names!

I have tried to explain this to you before, so the following is
probably futile. Nevertheless, the number of key presses in the above
command could be as little as 10-14 depending on your system. One
typical example would be
conv<tab><tab><tab><backspace><backspace><backspace>pdf<enter>

To a touch typist, this is hardly noticable.

They don't, but they also don't necessitate it by making the user go
fishing through long text files in a no-frills (hell, almost-no-user-
interface!) pager to find one little bit of crucial information in the
form of a cryptic string to memorize and then type exactly as part of
a longer command line at the prompt they return to by exiting said
pager.

You appear to be imagining how it would be to use your own mental
design of a text editor again. The world thanks you if you never
implement it!

Amazingly, shells /do/ know how to auto-complete file names. [hyperbole
snipped]

But they also only know that the first thing on the command line is a
file name.

No.

Everything after that is just a random jumble of characters
that it's up to the invoked binary to interpret.

No.

That binary can't
offer autocompletion because by the time it even runs it's too late;
the user already finished typing everything and hit enter. Not can the
shell, because it has insufficient information to know what sort of
input the binary is expecting.

It will auto-complete file and path names.

No, I didn't. I basically only do so to orient myself at the start of
typing something.

This isn't necessary if you use touch, of course.

Balderdash! Unless maybe you have Braille key-caps on your keyboard or
something.

For you to understand this requires you to first understand the
concept of the home row. Get back to us when you have climbed that
mountain.

It remains a problem when you keep using the mouse and therefore
repeatedly need to find your way back to the keyboard.

Not when each use of the mouse saves you 25+ keystrokes it doesn't.

Even if 25 keystrokes were necessary, a touch typist takes a
negligible amount of time to type them.

"More capability is better" is the path to creeping featurism. That's
how you end up bloating apps up with useless features such as a tool
for calculating in a certain Mesoamerican timekeeping system. :P

You may also want to get someone to look at that calendar-phobia you
are developing.

Cheers,
Bent D
--
Bent Dalager - bcd@xxxxxxx - http://www.pvv.org/~bcd
powered by emacs
.