Re: Great SWT Program

On Oct 14, 2:47 pm, blm...@xxxxxxxxxxxxx <blm...@xxxxxxxxxxxxx> wrote:
Wow. And you really are just now finding out where it comes from?
after what you've said is many years of Usenet reading/posting?
Amazing. Not unimaginable, I guess, but amazing!

Not really. It's used a lot on usenet, and lots of people don't know
beans about unix, so ...

Serious response: \^ (backslash being something of a universal
"escape character" -- a convention followed in some aspects of
Java as well, no?)

String literals. Programmers have to deal with such things. End users
having to is a sign of a UI design problem.

I'd say it's because you only know the conventions of one platform,
which by one means or another dominates most people's experience of
computers, and anything that doesn't fit that "standard" strikes you
as weird and confusing.

But then, I'm biased, and I know that.

Basic terminology like this should be standardized on. And for all
practical purposes it is -- the Windoze terminology is the de facto
standard.

Any delimiters you use at all -- blank lines or whatever else -- might
happen to occur in the pasted-in text, though, confusing matters.

But can't you easily distinguish your text from the inserted text by
inspection .... Yeah, whatever.

It depends. If it's a 40,000 word novel, you're not likely to have the
whole damn thing memorized word-for-word. Anyway, a simple case is
where you paste at the end of the document to see what's in the
clipboard. If it happens to be a chunk from the end of the document,
it may actually seem as if it was empty when it wasn't. Later you
might notice that a big chunk of text repeats at the end of the
document. Hopefully it's *not* when page 203 pops out of the laserjet
and contains something unexpected...

It's not only not obvious, but apparently in conflict with one of the
launch external command commands that you mentioned earlier. You had
mentioned a :rls something to run ls and view stuff. Wouldn't :reg try
to launch an executable named "eg" then?

I mentioned ":r!<command>" to launch an external command and insert
its output into the text being edited. Notice the "!" there.
(Reading from a file is accomplished with ":r filename". Notice the
" " there.)

So :r reads from an external source, and whatever's after the r
specifies the particular source. What sort of source is "eg" then?
Space is a file, ! is a shell command's output ... and eg is? :P

Or is there such an
executable and it's what displays the mini-clipboards?

Now you're getting into the spirit of the thing. :-)

That was said while wearing an "are you crazy? I hope not"
expression ... splitting obviously-internal functionality like that
out into something else would create all kinds of potential
complications for no benefit. (Unlike the windoze clipboard, which is
managed externally -- but is also system-wide rather than for one
particular application, so you get cross-application C&P out of it as
a benefit.)

Maybe so, but there was definitely no mention of pastes, and I'm all
too familiar with software (usually unix-developed and ported to
Windoze, rather than native) that defines "undo" weirdly to "undo the
last performed of some random, but predefined, proper subset of the
possible operations", so if you do A, B, and C, and then undo twice,
it may undo C and A rather than C and B.

Huh. I don't know that I've observed behavior like that with vim
or emacs.

Perhaps not, but I have observed behavior like that elsewhere.

How many times do you have to be told that a text-mode tool
running in an terminal emulator window can use all the screen
real estate available, with fonts as small as the sharpest-eyed
youngster could want?

How many times do you have to be told that when someone has the
hardware capability to display like that, they may as well use a
proper GUI editor instead?

being chopped up into even
smaller slices of an already-small pie, plus the lack of any way to
move the focus intuitively. No mouse support

How do you know vim has no mouse support? All I said was that
I didn't know whether it does. Turns out it does .... Off by
default, true. No need to rant about how awful that is; I can
almost construct your arguments myself.

It has mouse support? How the hell? It's a console app!

[snip stylistic criticism]

WTF?

I guess you missed the parts in previous posts where I said that
for me the keystrokes needed to operate vim long since became
automatic; I no more think "I need hjkl to move the cursor"
when I'm editing text with fim than I think "I need to press the
leftmost pedal to stop the car" when I'm driving. I'm sure this
is true in your world as well; you don't consciously think "oh,
I need the arrow keys to move the cursor", do you?

No, but it's easy to tell which one does what. I reach automatically
for the arrows and push the one pointing in the direction I want to
go. You reach automatically for hjkl and then puzzle for a bit trying
to remember which does what. Time gets wasted. You can find the key
group as fast as I can, but it seems doubtful once there you can pick
out the correct individual key as fast. Especially as they're not even
arranged in a cross on most (all?) keyboards.

Also, even when not looking at the keyboard I can pick my arrow
quickly, because the up arrow is flanked by empty space on both sides.
Finding the corner formed by the up, left, and down arrows is easy by
touch, and then it's easy to nail the intended key from there. While
hjkl are buried in the middle of an amorphous mass of QWERTY, at least
on standard keyboards. Even so, I tend to accurately find the specific
letter I want to type without looking when typing actual text, but if
I am reaching for "the up key" rather than "the letter L" or whatever,
I'm going to be glancing down, more than likely. The letter L key is
clearly labeled as such. My up arrow key also is. Yours isn't. Oops!

And even if it somehow magically is just as fast once learned, it's no
faster, and it is surely much, much harder to learn. That's not a good
cost/benefit ratio.

Another issue, this time with your car comparison, is that a car has
only a few important controls. Things like vi and emacs seem to have
thousands, with a couple of dozen in frequent use, instead of dozens,
with a handful in frequent use. You only have to choose among two
pedals; the wheel's behavior is obvious; mostly the annoying thing is
finding the right switch for the mirrors, wipers, hazard lights, or
other relatively infrequently used function. And those are the things
where you see a lack of standardization.

With your editor there will be dozens of frequently used controls
instead of a handful; the wheel's behavior is unobvious (and the wheel
is a straight line instead of a circle!); and there's NO
standardization. In fact your editor is like some wacky custom-built
car that has a couple of separate knobs to steer with that resemble
the knobs in a shower stall and the pedals are reversed, while the
dashboard is covered in blinking lights and pushbuttons, all labeled
in German or something. Anyone used to driving a car with a normal
wheel, pedals in the usual places, and so forth, i.e. your bog-
standard Ford or Chrysler, is going to crash this oddball vehicle and
die in the attempt long before they can master its use. :)

It might, if it tried to autocomplete without being asked. It
doesn't. What did you think that "if I press tab" meant? (It's
how one requests filename completion.)

Seems to pose a problem with aligning text. For that you normally want
the tab key to do something else.

The fact that Eclipse "helpfully" tried to autocomplete things
without being asked is one of the things that irritates me about
it. Yes, I've heard that this feature can be turned off.

AFAIR it pops down a menu with options you can choose none of and just
keep typing. The one area where it gets in my way is if I want to move
down or up for some reason and that menu's there at the time.

This may be a factor in the terrible documentation and awful help
systems on your side of the divide -- assumptions that "everyone
knows" some stuff that nobody much knows.

It's very difficult not to make *some* assumptions.

It's awfully easy to make really bad ones it seems.

I wonder whether something else will replace the Windows-style GUI
in your lifetime, and if so how you will cope.

Most likely, that GUI will evolve, rather than change wholesale. After
all, the full-screen text interface is sort of buried in a GUI
everywhere there's a text box or a Notepad or something. The line-mode
text interfaces of even older days of yore is embedded in the full-
screen one when you happen not to be moving up or down, or making
multi-line selections, and even in the GUI this way and also in single-
line input fields. Whatever follows will probably subsume rather than
completely replace the GUI, likely by adding more use of sound
(including voice recognition) as an I/O channel and adding more
possible abstractions and visualizations of data objects and
structures and functionality groupings.

I don't doubt that it works;

Huh. I wonder how I got the impression that you were skeptical.
I suppose I'm apt to interpret "I can't imagine how that could
work" as "I bet it doesn't!" Maybe I should check the calibration
of *my* threat-detection system. Such as it is.

It was probably elliptical. As in "work easily" or "work well" or
"work with a normal human being, not just someone with memorization
capabilities somewhere north of savant-level". :)

Some things I probably discovered by stumbling across them in
the help, in the process of looking for something else. Others I
may have read about in comp.editors, which is more than a little
vi-and-clones-centric. It's hard to remember. How do you find out
about useful Java library classes? Seems like the same kind of
problem.

A Google search can sometimes come in handy, but ordinarily the
functionality I need is in the API I already know, or is in an obvious
place in the hierarchy presented by the Javadocs.

One reason I chose vi over emacs was that it was "the same" on any
Unix machine. That has changed, but there's a good bet that any
Unix system will have some version of vi, and since I still remember
how to use straight/real/plain vi ....

Now for a little perspective: it's "the same" on one in 10,000 or so
computers. The other 99+% have Notepad or something very like it.
Actually, even most of the ones with vi do nowadays.

I'll be forced to suspect you're a vampire or something else like that
that likes to creep around in the dark and hates fresh air and
sunshine. ;)

Ah, you've guessed my secret.

Damn, and me without my cloves of garlic. Quick, google, where's the
nearest Sarah Michelle Gellar fan site?

Good for you. See why I say I think it would be a bit presumptuous
to call myself a developer in this group?

Hrm.

Given some of the stories I hear, perhaps one should put some scare
quotes around that "productivity". Partly an attempt at humor, but
it's kind of like when people talk about "upgrading" their o/s --
sometimes the new one really is better, sometimes it's not so obvious
that it is ....

That's why nobody smart uses Windoze Pista instead of XP/2K3.

Whereas if you put a little time and thought into learning about unix,
exactly one thing seems easy and obvious: that's not just pain, that's
Motrin pain. :P

My mileage varies.

Really. They should really rename a bunch of stuff. How about "eh" in
place of "emacs"? Short for "Excedrin headache." That would be a nice
start.

The latter especially is interesting. There is a "how to learn on your
own" that can actually be self-perpetuating? Despite the total lack of
standardization between apps?

I keep telling you that there is. I guess you don't believe me.

I keep telling you that I've *seen with my own eyes* that there isn't.
You enter something at the command prompt, are in an interactive app,
and ... it has nothing in common with that other one you fiddled
around with yesterday. And neither with the one from Tuesday. Etc.

We might be getting close to "agree to disagree" here. Things I
regard as mild annoyances seem like showstoppers to you, while
things I regard as major irritations strike you as unimportant.

Probably because things that are merely difficult for some kind of
weird savant are flat-out impossible for a normal human being? Or even
a "normal" techie? :)

1) why does anyone add capabilities that depend on modern hardware,
when modern hardware makes the whole text-terminal mode of UI design
obsolete anyway? Still not explained to my satisfaction.

Maybe it has to do with some notion of frugality, or not discarding
something that still works very well within its limitations and
doesn't require the latest and most expensive hardware.

Come off it. That 386 that's gathering dust in somebody's closet until
they sell it to you on eBay for a whopping $50 is quite capable of
presenting a reasonable GUI.

And vi "works very well within its limitations" in rather the manner
of an oxygen-deprived muscle. It still moves, but it aches and gets
stiff and doesn't do an especially great job of it, and will stop
working out of sheer exhaustion soon.

So will anyone wrestling with vi in order to get something done
instead of using a normal editor to do the job. They might be able to
do it on an ancient IBM XT, over a 300 baud telnet session, and even
through hell and high water, but if they're sitting in a normal office
cubicle in decent weather in peacetime with a fat Centrino Duo and 20"
LCD monitor there before them, they may as well use something less ...
tiring, no?

Why did I buy a low-end system? out of some sense that for what
I wanted a computer to do, it would be enough.)

Yeah. Being able to do something is cheap. Being able to see what the
*** you're doing while you're doing it seems to cost a touch more;
but it's still cheap.

[insult deleted]

I don't insist on having the original full text-mode experience
when something else would -- *in my opinion* -- serve me better.
When I think the "full text-mode experience" would suit me,
though ....

I'm starting to suspect it goes quite nicely with a standard-issue
white straitjacket and little round white pills of Thorazine. Color-
coordinated even. ;)

Also, if you can do that, you might as well just fire up
KWrite or whatever and forget about vi or emacs. :)

And why would I want to invest time in learning another text
editor, when I have one that suits me ....

You wouldn't HAVE to. You just sit down at those modern ones and start
typing. There's really nothing to learn that you don't already know if
you can type at all -- that's the beauty of it! (Well, you need at
least basic menu/mouse skills, to get by until you remember routinely
the keyboard shortcuts for things like copy, paste, and save...but who
doesn't have those these days too?)

No, those were examples of things that crashed in ways that brought
down the OS, rather than things that didn't install right.

My point stands: "GUIs not perfect, sometimes worse than simpler
tools."

I don't think the fact that they had GUIs somehow made them more
likely to crash, or to bring other things down with them.

What was wrong with them wasn't that the programmers had another
meaning for "mouse" in their vocabulary besides one with twitching
whiskers, but that their code contained bugs.

Yes. In context, it's more significant that he's (as I understand
it) one of the original developers of Unix.

So, the messy syntax for pointers (especially function pointers) and
for just about everything on Unix has a common source. It figures.


.

Quantcast