Re: Great SWT Program

In article <1192714389.056332.239190@xxxxxxxxxxxxxxxxxxxxxxxxxxx>,
<nebulous99@xxxxxxxxx> wrote:
On Oct 16, 6:12 am, blm...@xxxxxxxxxxxxx <blm...@xxxxxxxxxxxxx> wrote:

[ snip ]

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!

I'm really not sure what you're talking about here; your use
of "hotkey" seems -- somehow at odds with how I perceive vim's
behavior. In command mode, one is typing commands; "d" starts a
delete operation, "y" a copy ("yank") operation, etc. -- and ":"
starts an "enter 'ex' command" operation ("ex" being a line editor
whose functions were incorporated into vi, as "'ex' commands").
In the right frame of reference I claim it all makes sense and
feels reasonably consistent. Apparently it's difficult for
someone accustomed to Windows-style programs to view things in
this frame of reference.

[ snip ]

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.

What evidence do you have for this, other than your own opinion?

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.

Using systems remotely. Wonderful stuff. Can't afford a Cray
yourself? Maybe someone who can will let you log in remotely
and use theirs. Of course that was back in the days before the
riffraff was let in. :-), sort of.

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.

None of this, of course, is particularly relevant to vim/emacs
as they exist currently. Mouse support for vim running locally
in a text-only console -- very possibly it works in much the same
way you describe for MS-DOS text-mode applications. Logging into
a remote system from such a console -- yeah, in that mode mouse
support appears not to exist. However, logging into a remote
system from a terminal-emulator window under X -- yes, in that
setup mouse support seems to work.

It *sounds* here as if you're saying that because you can't imagine
how something would work, or how it could have worked at a time
when it probably didn't, it must not work now, despite my saying
that I've tried it and it does. Am I lying? Deluded? or just
misunderstanding what you're saying?

[snip stylistic criticism]

WTF?

[snip repetition of stylistic criticism]

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

It's along the same lines as some people in this group commenting
on textspeak, or top-posting, or stuff like that. <shrug>

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?

Magic? I'm lying?

[ snip ]

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.

Huh. Your mileage varies indeed. Q? Well, whatever.

I orient on the "home keys", aided by the little bumps
(some?) keyboards have on the 'f' and 'j' keys. So hjkl are
easily findable. Possibly if I hadn't been trained, way back in
high school, in touch-typing, and retained some of that skill ....

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

Irrelevant for everyone else.

And? They don't teach touch-typing any more? seems like it
would be at least as useful now as it was way back when ....

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

Well, then, what the hell ARE you doing?

Typing k, which is "right there", to move up a line. (I had to
pause a minute to think about whether it's j or k that moves up
a line. Normally I think "up a line" and the correct key gets
pressed without conscious thought. Yes, really.)

Now, editing text using selection-with-shift-and-arrow-keys,
control-C for copy, etc. -- for *that* I have to think about
what keys I'm supposed to press. They're not hard to remember,
true, but I do have to think about them. Probably with practice
it would become more automatic. I'm told that with even more
practice one can become the equivalent of bilingual -- able to
switch back and forth easily among different sets of keybindings.

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?

Um, when I'm editing it? cut/copy-and-paste, search-and-replace,
like that?

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.

Apparently I'm still not communicating. vim is not guessing
about when "tab" should initiate autocompletion. It's like ....

Okay. With Firefox under Linux, alt-F brings up the "File" menu.
At that point, pressing "Q" exits the browser. But just pressing
"Q" by itself -- seems to do nothing. Same key, different
contexts, different operation? Not weird, right?

So in vim, if I'm inserting text, pressing tab inserts a tab
character [*], while in other contexts it does something else.

[*] Unless I have the "convert tabs to spaces" option set, as
I normally do when editing code.

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!

No. vim really doesn't seem to me to be guessing at what I want;
it's utterly predictable, if a bit inscrutable.

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.

??

Control-C used to mean "interrupt". Many applications used the
emacs keybindings to edit lines of text. Like that.

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!

That this is what most people use? Of course. When have I ever
said otherwise? What I *am* arguing against is the position that
everyone should comply with a de facto standard apparently invented
by people ignorant of previous standards and uninterested in ....
I'll skip the rest of the biased rant.

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.

Well, except that emacs could be emacs or xemacs, and vi could be
"real" vi or one of the clones (vim, elvis, .... ).

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.

There's not a lot of overlap between old-style [*] vi keybindings
and old-style emacs keybindings, that's true. In my experience,
most other old-style text-mode programs were apt to adopt either
vi-style keybindings or emacs-style keybindings.

[*] Current versions of emacs and vi clones seem to both use arrow
keys, page up/down, etc., for purposes most people would find, um,
"intuitive".

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.

Yeah. Novice-friendly but limited in functionality, versus
novice-unfriendly but with features useful to experts ....
All points that have been made before, and you're unconvinced.

Probably once or twice a year I do spend, oh, maybe an hour or
two, learning something new about one of my old favorite tools,
or learning a new one. Usually I think this pays off in future
time savings, but maybe it's just a pleasant occasional distraction
from what I'm supposed to be doing. <shrug>

[ snip ]

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?

Partly I'm sure I'm being influenced the fact that, in my
experience, there's a strong correlation between "big complex
program" and "program with a GUI", and a similarly strong
correlation between "small simple program" and "text-mode
application". In principle there's no reason it has to be
that way; in practice it seems that it *is* that way.

Then again: A Java program with a CLI only won't need AWT or
Swing classes, nor an event dispatch thread, etc., while a Java
program with a GUI will. Seems to me that the latter is inherently
more complicated. I guess I could be wrong.

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.

Sure. Then again, if I had to choose between something potentially
efficient but buggy, and something less efficient but reliable ....

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

Usually true. In a situation in which "save" will take a while,
I'll have another window open in which I can do something else
while I'm waiting. Or I might try putting the application in
the background (where it can continue waiting for I/O completion)
and doing something else in the foreground.

Then again, if you're doing something with a GUI that involves
file saves, is there really much useful you can be doing while
waiting for the save to complete?

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

Very nice, but -- this helps in understanding basic concepts of
multithreading? I'm skeptical.

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

You've apparently used this feature and found it helpful, and I
haven't, so there's only so far I should go in arguing with you.
I guess I'm skeptical, though, about the ability of any tool to help
with one of the key problems of multithreading, namely that results
may depend on details of thread interaction that can vary from
execution to execution. It's not clear to me that the behavior you
observe running under a debugger (and stopping/starting threads at
will) is necessarily the same as the behavior you observe without it.
But -- <shrug>.

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

Relevant Pages

  • Re: Great SWT Program
    ... came to emacs from something more Windows-mainstream. ... a good command line is both a user interface (when running ... the two keys least likely to work properly at prompts in a Unix ...
    (comp.lang.java.programmer)
  • Re: Great SWT Program
    ... "control-Z to undo" is as natural as breathing. ... obtuse and difficult to learn when the arrow keys are ... characters and then type in the resulting number before hitting my ...
    (comp.lang.java.programmer)
  • Re: Great SWT Program
    ... I can't easily say how other applications behaved in 2001. ... function keys, etc.). ... lisp interpreter and all of the actual text editor functionality as ...
    (comp.lang.java.programmer)
  • Re: Great SWT Program
    ... the keyboard, even when intermittently using the numpad, arrow keys, ... memory for where the keys are, and having the keyboard in my bottom ...
    (comp.lang.java.programmer)
  • Re: National Security Backdoor in telnetd - all versions.
    ... If an officer asks nicely, I will ask what he is looking for, then let ... > And since both dual keys were to to be held in undetermined government ... I doubt you would even have a clue at to some techology.. ...
    (comp.os.linux.security)