Re: Great SWT Program

On Oct 16, 6:12 am, blm...@xxxxxxxxxxxxx <blm...@xxxxxxxxxxxxx> wrote:
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.

Sure I was, but if I tried to follow up on every Usenettism that I was
curious about, I'd spend my days doing nothing else.

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.

We're talking about a text editor's search and replace functionality.
If we were discussing an IDE it would be another matter, but this is
supposedly "just" a "general-purpose" text editor.

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.

It makes sense for a full-blown command interpreter but not for a
hotkey system. Having what one hotkey does depend on what hotkeys were
hit just beforehand creates an even larger amount of state that the
user has to track in his head; in essence the editor develops a bunch
of additional modes if this is done. "Hit the wrong key and it beeps
or does something strange" is bad enough *without* it depending on
what keys you've already hit. It also implies that some keys that are
actually bound to something will silently change this mode without
producing a visible effect until another few keypresses finish the
command. While this saves chording, it seems likely to cause more
problems than it solves. Windows has this problem in exactly one place
in all of its UI -- hitting alt silently activates the menus and
changes how the next keypress is interpreted. Sometimes this is part
of a useful keyboard shortcut for a menu item. Occasionally it's a
source of annoyance when the system decides for some reason that an
alt key was tapped. Although there's generally a visual indication of
the change in mode, it's subtle and likely located in the top left
corner of the window while your attention is, in a lot of cases,
somewhere near the bottom line of the display (if typing in text
somewhere). The next letter you type, instead of echoing, beeps, pulls
down a menu, or does something strange. But there is only the one key
that can provoke this effect. It sounds like vi, put into its command
mode where hotkeys do things instead of letters being inserted that
are typed, will have this behavior for a whole bunch of keys. And I
thought it seemed bad enough when ":" was the only one that I knew
would do this!

FWIW, emacs has a similar behavior when some key is hit; I think it
may have been ESC. Given how often ESC is needed to back out of some
prompt or as part of a meta combination (analogous to the alt,
something, somethings on Windows), this gets to be a problem, but
again it's only one key in an obscure corner of the keyboard like Alt
and :. But apparently in vi the R key and others can also do this ...

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?

Can't think of any offhand.

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.

The latter is also a matter of fact. Using a text-mode application
when you have hardware like that is like tying one hand behind your
back. (Using one when your hardware can support nothing more
sophisticated is like having a broken wrist instead.)

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.

Eh. I knew some MS-DOS text-mode apps could use the mouse, but ...
nah, can't be. MS-DOS text-mode apps were written for the specific
environment of a PC, with serial ports and the like easily accessible.
These unix tools were written for use with terminals like the VT220
originally, and even if the machine they were running on had a mouse,
that mouse was probably 300 miles from the guy sitting at the keyboard
at his VT220 on the other side of the state telecommuting or whatever
it was that they did. It does not, therefore, make sense that they
would use that mouse as input even if it existed -- I could easily see
some nasty pranks by the sysop, or even anyone with physical access to
the machine room, that way. Wouldn't moving the machine's mouse affect
everyone's sessions that was logged in, for that matter? There just
isn't any way to make sense of mouse input in combination with
keyboard input where the latter might be coming from the local console
or from a thousand miles away and usually it was the latter.


[snip stylistic criticism]

WTF?

[snip repetition of stylistic criticism]

The total change of topic is rather ... odd.

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.

How, when the keys are so unnatural, can this be possible?

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

Yep, that's exactly what it is. It's called "superior usability", and
also "superior automation".

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?

Motor memory doesn't work so well for keys buried in the middle of a
larger mass of keys. If I want to type text, I orient from the Q,
which is easy to find. If I want to move, the up arrow key is easy to
find because it has empty space to each side. If I were to use hjkl
for that I'd have to specifically look for the h, because the keys
aren't separately grouped, and yet I'm not using the whole qwerty part
so I couldn't just navigate based on where the Q was as I do when
typing text.

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

Irrelevant for everyone else.

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

Well, then, what the hell ARE you doing?

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.

It's a text editor. Moreover, it's a text-mode application. When
AREN'T you entering text, given these observations?

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.

True enough. If I press tab in my browser it does one thing; in
Notepad it does another. If it behaved strangely in notepad depending
on whether the line I was editing "looked like a filename" or
whatever, I'd be annoyed whenever it guessed wrong about what I
actually wanted. That's the same sort of thing that annoyed you about
Eclipse's autocomplete and other similar behaviors in GUI apps and
annoyed absolutely everyone about that damned animated paperclip. It's
funny how it's annoying to you when it's in one type of app and not
when it's in the other!

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, you have accepted the truth!

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.

Impossible. Vi is vi is vi, and emacs is emacs is emacs. If they are
completely different in their interaction design, then they are
completely different in their interaction design for me, and they also
are for you. If their key bindings are completely unalike for me, they
are likewise for you. Same goes for other such pairs. This is the
inevitable result of lack of standardization and everyone making their
own interface and keybindings up from scratch as if in a vacuum. We
have much better processes now than we did back then though.

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.

No local expert means can't get past that phase, obviously. Also,
there's the niggling little matter that such a phase simply should not
exist, not for things like text editing that should not be rocket
science anyway.

There could be many explanations for that -- other things you'd
rather be doing...

That certainly plays a role as well. I want to actually get something
useful done. I don't sit in front of a text editor to spend hours
puzzling out how to make it do particular things as some sort of
intellectual exercise; I sit in front of it because I have some ASCII
file that needs writing and the sooner the UI gets the hell out of my
way and becomes transparent to me the better. This happens immediately
with any text editor I've ever used on Windows (or a Mac) that wasn't
something weird ported from something that rhymes with "eunuchs". It
doesn't happen in anything like a reasonable amount of time with any
of the unix text-mode stuff. Significantly, it does with MS-DOS's old
editor, which shows that it IS possible to make a text-mode UI easy to
use if you only make the effort when developing the darn thing...

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?

It's not that no one *can*. It's that no one *will*, not anymore, save
perhaps a small set of insane persons or people with loads of time on
their hands. (I wonder how many live in places whose names begin with
"Cell Block"? Frankly the insane ones would worry me less...)

I do. To me programs with GUIs seem inherently more complex
than the old text-mode stuff, hence more likely to have bugs.

Why? Simply because they use graphics?

If nothing else, aren't they more likely to be multi-threaded?
which seems to me to be a known source of potential trouble ....

And potentially vastly improved efficiency, especially on multi-core
machines or when dealing heavily with I/O. Your text-mode apps
probably actually hang for ages if there's I/O contention! The bad old
days of hitting "save" and then going to make coffee and hoping it's
ready for input again by the time you get back were supposed to be
gone by now. :P

(Not that it would be in a perfect world, in which all developers
understood how to write multi-threaded code. But.)

They should use Eclipse. It's often helpful in debugging multi-
threaded code. At least if it's Java code. You can actually just reach
into the running app and pause a specific thread, and see where
exactly it is in the source code. Put a breakpoint there and resume it
so it immediately trips over the breakpoint, and you now have it
suspended again in a state where you can now better inspect the local
variables and other state. If you suspect a deadlock, pause threads
and see where they are in the source; if one of them is constantly
sitting on a line that says synchronized (foo) or synchronized void
method() then you have found a likely deadlock. Better yet you have a
fairly good idea about the identity of one of the monitors involved.
Pausing other threads should reveal one that holds the foo monitor and
is waiting on another one, perhaps one the first thread holds, in
which case you've already found the entire cycle and you're well on
your way to actually fixing the bug...

.

Relevant Pages

  • Re: [9fans] Plan9 - the next 20 years
    ... I think an editor is not a good example, ... It does not matter what we think. ... And some apps have multiple processes accessing one file. ...
    (comp.os.plan9)
  • Re: [9fans] Plan9 - the next 20 years
    ... I think an editor is not a good example, ... It does not matter what we think. ... And some apps have multiple processes accessing one file. ...
    (comp.os.plan9)
  • Re: [9fans] Plan9 - the next 20 years
    ... I think an editor is not a good example, ... It does not matter what we think. ... And some apps have multiple processes accessing one file. ...
    (comp.os.plan9)
  • Re: The OS doesnt matter... then what?
    ... both the Mac OS and Linux. ... I can't see web apps _in general_ as ever being a serious threat to desktop ... no matter what the OS. ... lowest common featureset and can't make use of underlying OS features. ...
    (uk.comp.sys.mac)
  • Re: Jumping into middle of instruction
    ... You can't direct write to CodeSeg in protected mode. ... matter... ... it is easy to create apps with combined code+data ...
    (comp.lang.asm.x86)