Re: Great SWT Program

In article <1192489988.921267.108520@xxxxxxxxxxxxxxxxxxxxxxxxxxxx>,
<nebulous99@xxxxxxxxx> wrote:
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 ...

And you weren't ever curious about where it came from? Huh.

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.

But if the "end user" *is* a programmer .... Whatever.

[ snip ]

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

Part of the command rather than its arguments. Commands are
separated from their arguments by a space or punctuation.
Maybe that's weird too, though it strikes me as sensible, and
even in line with the conventions of natural language.

[ snip ]

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.

Huh. Care to mention examples?

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?

Because I believe the latter to be a matter of opinion, while
the former is a matter of fact. There may be many reasons to
prefer something with a "proper" GUI to a text-mode application,
but "text-mode applications can't display more than 24 lines and
80 columns" isn't one of them -- well, if we're talking about
text-mode applications as they exist in 2007.

[ snip ]

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!

Magic, I guess. I just tried it in a text-only console (not
a terminal emulator under a desktop environment, but one of
the Linux "virtual consoles"), and it works there too.

[snip stylistic criticism]

WTF?

I find your long paragraphs difficult to follow. If you're
interested in communicating with your readers, that might be
useful information. Or not, since you might easily conclude that
this is one more way in which this blmblm person is just weird.

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.

No. There's no conscious thought involved, any more than there's
conscious thought involved in figuring out which of the car's
pedals to push. Well, unless I've recently had the misfortune
to have had to edit text with some other tool. It's a bit like
trying to switch back and forth between a car with an automatic
transmission and one with a clutch -- when I was more accustomed to
the latter, sometimes I got a big surprise pressing the leftmost
pedal in, um, a "normal" car. (Go ahead -- tell me that just
proves again how much better an automatic is, since it's what
"everyone" drives.)

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.

I've been using something vi-like for almost twenty years, as
best I can remember. Is it really unimaginable that in all those
hours the knowledge of which key does what would become a matter
of -- what did you call it not too long ago? motor memory? --
rather than conscious thought?

Apparently to you it is. <shrug>

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.

Right on/near the "home key" positions that touch typists can easily
find.

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!

But I'm not "reaching for the up key".

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.

Could be. I don't know how many people who started with vim
actually use the hjkl keys for navigation. vim supports using the
arrow keys as well, and my guess is that many people who start out
with it rather than "real" vi just use what they're more used to
(arrow keys).

[ snip ]

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.

Context matters. It's unsurprising to me that pressing tab in the
middle of something intended to be interpreted by something like a
shell would do something different from pressing tab while entering
text. I guess you find this startling and weird, and yet -- what
happens when you press tab in your browser of choice? in Firefox
it seems to move to the next link, which seems a little different
from what it would mean if you were entering text in -- whatever
you use to compose text.

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.

Just that it pops up -- I find that distracting. Maybe you get used
to it.

[ snip ]

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

A primitive version of the line-mode text interface. That's kind
of the point I've been making. A lot of the key bindings that
were useful with the old interfaces now have other meanings.

One can argue, though, that the user base for the old key bindings
was a lot smaller than the user base accustomed to what Windows has
made the de facto standard. So maybe you'll be in luck, and those
key bindings you're used to will be the standard for the rest of
your life -- or the whole idea of key bindings will go away, to be
replaced by something you find easy to adapt to.

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.

[ snip ]

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.

Your mileage differs from mine. I'm perfectly willing to believe
that for one reason another *you* can't, or don't want to,
get past the "need a local expert" phase with the old-Unix UI.
There could be many explanations for that -- other things you'd
rather be doing, lack of a local expert, belief that the UI you
have is superior, some other reason. I might even agree that your
explanation makes sense *for you*, and perhaps for many or even
most people.

You seem to be saying, though, that because *you* can't or won't do
it, no one can, and dismissing my claims that I'm a counterexample.
Am I not understanding you?

[ snip ]

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.

I do. To me programs with GUIs seem inherently more complex
than the old text-mode stuff, hence more likely to have bugs.
If nothing else, aren't they more likely to be multi-threaded?
which seems to me to be a known source of potential trouble ....
(Not that it would be in a perfect world, in which all developers
understood how to write multi-threaded code. But.)

[ snip ]

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

Relevant Pages

  • TeX and friends (was Re: Sarahs very sad...)
    ... the formatting codes interpreted and applied using other tools appropriate ... which does of course mean that it's easy to write a nice integrated GUI ... documentation, and each document is at least 90% useless to me. ...
    (uk.people.support.depression)
  • Re: Great SWT Program
    ... and anything that doesn't fit that "standard" strikes you ... even when not looking at the keyboard I can pick my arrow ... Another issue, this time with your car comparison, is that a car has ... Most likely, that GUI will evolve, rather than change wholesale. ...
    (comp.lang.java.programmer)
  • Re: Great SWT Program
    ... that amounts to my saying "the GUI paradigm sucks"? ... wise, than with things like vi, although it may have things in common ... if "dial-up speed connection" is broadened ...
    (comp.lang.java.programmer)
  • Re: [kde-linux] how to link database MYSQL in QT Designer
    ... I aims to make a GUI,this GUI contains a tree/list,and I want to show ... Ask Designer to write a main.cpp file...save all. ... Finally from a shell, I cd into that dir, and type the commands: ...
    (KDE)
  • Re: Great SWT Program
    ... you could not correct a mistyped login ... because backspace and left-arrow both fail to behave as expected. ... Left arrow doesn't ...
    (comp.lang.java.programmer)