Re: Great SWT Program

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?

[implied insult deleted]

611.

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

at minimum, if not just refer back and forth and type them out
longhand due to the editor having a completely cloistered clipboard or
none at all and the shell simply having none at all.

I can only imagine that this is a common problem with your chosen
tools.

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?

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!

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.

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.

No, it's simple and elegant.

So you have several dozen converter files laying around, and you - the
user - have to manually find the correct one to drop files onto?

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?

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.

And what good are the icons going to do anyway?

They a) display the functionality clearly and cleanly 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.

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.

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!

The Windows user needs to spot the one labeled "convert to
gif" and drop a file on it. By the time you've hit page down 53 times
the Windows user has converted a whole load of files and is already
well into their *next* task.

If the user /wants/ to hit page down (for whatever reason) 53 times,
Unix doesn't actually stop him from doing so. Do your tools? If so,
that is a serious bug that needs to be rectified.

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.

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. Everything after that is just a random jumble of characters
that it's up to the invoked binary to interpret. 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. Unless of course it guesses, and then
it will often guess wrong and Bad Things will happen.

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.

You surely need to look at your keyboard when initially starting to
use it too;

No.

Poppy***! Again, unless you have Braille key-caps.

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. It
also doesn't if you use keyboard shortcuts instead of the mouse when
that's more convenient.

I do not. My arguments are directed against current GUI apps

More history-rewriting. Even then, only some current GUI apps are
atrocious. Notepad's interface is nearly flawless (though Notepad
hasn't many features). Other, more powerful editors exist with equally
good UI and more features. Word's interface is mediocre, with numerous
flaws. And of course the graphical emacs variant you seem to prefer
has an atrocious UI, no matter how many features (many of them
useless) it sports after years of feature-creep.

Well, you failed to state that plainly; it was an obvious word to use
as a placeholder for a variable utility-name that would depend on
exactly what you were converting.

[insult deleted]

612, and none of the nasty things that you have said or implied about
me are at all true.

Of course it is. It's just too bad there /are/ no implementations that
actually conform to it because it's a really useless "standard".

Balloonjuice!

You need to do something about [insult deleted]. Repeat
after me: more capability is better.

Bull***!

613.
None of the nasty things that you have said or implied about me are at
all true.
"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
.

Quantcast