Re: Great SWT Program

In article <1193257579.096475.237600@xxxxxxxxxxxxxxxxxxxxxxxxxxx>,
<bbound@xxxxxxxxx> wrote:
On Oct 21, 11:47 am, blm...@xxxxxxxxxxxxx <blm...@xxxxxxxxxxxxx>
wrote:
This is a point. In practice it doesn't feel like a bother to me,
because most of the key sequences that don't show anything are so
short and so automatic ....

Eh?

What about that sentence wasn't clear? the word "automatic"?

Most of the key sequences I use regularly that fall into your
category of "type a character, application goes into some other
state without any visual indicator of its altered state" --
they're very short, unlikely to be interrupted in the middle,
and typed without a lot of conscious thought. Hence the lack
of visual indicator doesn't feel to me like a big deal.

The ones that involve more typing and might be interrupted --
I can't think of any that don't show you what you're doing as
you're doing it.

Most of the longer commands (those beginning ":", or searches)
bring up a one-line "window" displaying the command so far and
allowing one to move around in it and edit.

Strange behavior for a hotkey-driven interface. But it would seem to
mostly solve the blind-typing problem that I definitely recall emacs
has.

"Hotkey-driven interface" .... I guess I've been using vi(m)
for so long that its modal nature feels normal to me -- i.e.,
the idea that one can be in a mode in which *all* keys are what
I think you're calling "hotkeys" seems reasonable.

Except of course that you need to know some arcane command language
instead of it being self-evident what a give command will do, whereas
(if properly designed) a GUI's command buttons and menu items state
their effects in plain English (or whatever language, modulo
localization -- ah, localizability, another advantage of GUIs!)...

I can't quite imagine why being able to display application-produced
text in the user's language of choice is a feature of GUIs and not
text-mode applications. Remember that discussion of how the old
text-mode applications managed to work with a variety of terminals,
without themselves including the specifics of what particular
terminals needed in the way of escape sequences? Something
similar could be done with whatever text the application needed
to display, no?

[ snip ]

I don't know how you can
refute this, given that as best I can tell you don't know any such
people, other than the ones in this newsgroup, and you don't seem
to believe us.

It's that whole extraordinary claims, extraordinary evidence thing.
You're claiming, in essence, that you could be more productive working
with hand saws, sandpaper, and a hammer in pitch darkness with a
flashlight held in your teeth trying to build a house than I could be
with power tools in broad daylight doing the same job, while each is
proficient with his or her respective tools. That's dubious on its
face.

I guess we're all deluded, then. Uh-oh. Isn't that a mortal
insult, to which I must respond in full force or risk .... Oh,
never mind.

Yes. So very likely the original vi didn't have anything
resembling mouse support. What does this have to do with vim,
or other vi clones, or modern emacs?

What it means is that mouse support is useless on software designed
for a text terminal environment.

Uh-huh. So, the fact that someone new to vim can use the mouse to
select and paste text in a way that will seem fairly familiar --
useless? "Whatever", I guess.

Whereas emulation of text terminal
limitations is useless on software designed for a modern workstation.
If this software you champion is designed for the one environment then
there is something wrong/silly with it. If it is designed for the
other then there is something else wrong/silly with it. It's an
inescapable trap, I'm afraid; I've got you.

"Got me" how? What do you want here? Do you want me to agree that
the tools I like are out of date, and I'm an idiot for sticking with
them? or do you just want me to shut up and allow your [ insult
deleted ] claims to stand ....

[ snip ]

point-and-click for things you don't do often, and all the power
of the old-style editor for things where you're willing to master
a more obscure interface.

People keep rabbiting on about this mythical power that lurks in the
keyboard and is only accessible by mastering the magical meta key
somehow, and is somehow impossible to implement in a modern UI.

One more time: No one is telling you that "modern" UIs *can't*
provide good support for people who prefer to use the keyboard.
What more than one person has said is that the ones we know about
*don't*.

I have
yet to see any evidence that it exists, or hear of any feature of
either vi or emacs that I would a) actually find helpful and b)
couldn't achieve just about as easily with my preferred tools, albeit
perhaps without setting any speed records with some of the ones I
wouldn't be using on a more often than hourly basis or thereabouts
anyway; plus my preferred tools don't have huge complication, but a
small number of orthogonalized features (or even orthogonal separate
apps that interoperate with copy-paste) that can be used in a large
number of combinations without the associated learning curve suffering
a combinatorial explosion (unlike, especially, with emacs).

Strangely enough, that "small number of orthogonalized features
that can be used in a large number of combinations" -- that's
more or less what I like about *my* tools. You will probably
disagree, but since you don't seem to know very much about these
tools, how can you be sure?

So maybe you can help me understand better .... When you say
"how is that possible?" in response to some claim I make, what
*are* you saying? if you're not implying that I'm mistaken,
or deliberately lying?

That you're describing something highly implausible, and if it
actually does work as advertised, it probably does so only for people
with memorization and related skills bordering on savantism.

Whether something is possible and/or true seems to me to be a
separate issue from whether "normal" people (whatever that means)
can use it easily.

Uh-huh. And quietly setting an example with your own posts
of mentioning no-cost tools and sources of information, rather
than jumping on any mention of anything commercial, unless it's
clearly identified as such and accompanied by a list of no-cost
alternatives .... Well, I'm sure that's different.

Strange. I don't recall any such matter arising in and therefore being
relevant to this particular thread.

So, we're not allowed to mention content from one thread in another?
Okay. New rule to me!

[ snip]

Sure. I still find that the ability to type without thinking about
where all the keys are is useful. You don't?

I do too. Why, did you think I had to think about where all the keys
were for some reason?

Why not? You seem to think that's what I do.

[ snip ]

I guess I didn't make my point clear: My brain says "move up
a line", and a 'k' is typed. I'm not thinking about it being
a 'k'; I'm thinking about moving up a line. I only have to
think about what key is involved if I want to tell someone else.

That does not make sense. There's clearly an extra translation step
involved, and that has to have a cost in cycles and memory use. You
just may not be consciously aware of it except when you're discussing
the subject itself at the meta-level as we are here and therefore are
consciously paying attention to it in a way that you normally don't.

I'm not sure how we could design an experiment that would settle
this one way or another. What you seem to be saying here is that
you know better than I do what's going on in my head. I guess
that's possible, but -- wouldn't you reject a claim that I know
better than you do what's going on in your head?

[ snip ]

Ah, is *that* where the confusion comes in .... No, if you're typing
in text meant to be interpreted as a filename, you're almost certainly
in the "enter an 'ex' command" mode.

OK, OK, time out.

Just how many fucking modes does this monstrosity have, anyway? :P

None, as far as I know. There's an insert mode, and command mode,
and .... none for the activity you mention. But the application
surely has features I don't (yet?) know about. (Attempt at humor.)

[ snip ]

I guess. When I'm editing code, I have things set up so that tab
inserts an appropriate number of spaces instead; I don't like having
literal tab characters in code. <shrug>

Must be a pain when it comes time to de-indent a section then. Eight
times as many del/bksp keypresses per line. Ouch!

That would indeed be a pain. I'm glad I don't have to do it.
Didn't I explain that later in the post to which you're replying ....
But I think you said that you respond to posts point by point
and rarely go back and edit previously-written text. "Whatever."

Worse, of course, is "Missing separator. Stop." I'm guessing make
drives you batty when you need to use it and you forgot to turn tab
behavior back to normal when editing the makefile way back when and,
as a result, it got b0rked?

Well, no, because I don't edit makefiles with the "turn tab
characters into spaces" feature on. Easily accomplished by making
separate configuration files (one for code, one for everything
else) .... This is all much easier than you seem to be imagining,
but I'm getting tired of providing long explanations that don't
seem to have any result except more confusion and argument.

[ snip]

"r" to say I want to copy something into the file being edited.

" " to indicate that I want to copy from a file.

"myL" followed by <tab> to give the filename.

<enter> to end the command.

Of course, if you have myLongFileName001.jpg through
myLongFileName999.jpg it won't know which of these you mean ... saving
the ".jpg" by reducing it from four keystrokes to one isn't a big gain
percentage-wise in this instance. :)

Again, the feature doesn't work the way you seem to be imagining.
Admittedly I didn't spell out all the details. In the scenario
you describe, pressing tab would fill in as much of the filename
as possible, turning "myL" into "myLongFileName" and leaving
one in a state in which one could then type the rest of the name,
and/or press tab again to get a list of choices.

[ snip ]

So much for easily deleting away full indent levels at a time then. :P
Having to hit backspace 8 times in a row to move stuff left one indent
must get pretty tiresome pretty fast.

So I'm glad I don't have to do that.

Except that you do. You have eight spaces to delete instead of one tab
character. A child can do this math correctly!

A child who doesn't realize that one can delete more than one
character at a time. There are several ways in vim, and emacs
if I remember right, to delete multiple characters with fewer
keypresses than there are characters. vim also allows repeating
the previous command with one keypress (where the previous command
could be "delete eight characters starting at the current cursor
position").

(I think there actually are several faster ways to do this
in vim, but apparently I can't be bothered to learn the proper
incantations. I don't seem to need this feature much these
days, since vim will do automatic reindentation of code.)

The closest thing I can think of in Windows editors is the ability
to select text to delete using the mouse, or using keys such as
Home and End to help select text. I don't know how much this
helps you in making a lot of similar changes (meaning "I don't
know", not "I think it's not possible").

(1) Use search-and-replace to remove a selected number of spaces
from the start of each line, applied to a selected range of lines.

That's not possible.

Right. Something I do routinely isn't possible. I'm lying? Deluded?

Search and replace for spaces either a) won't
work or b) will mangle the hell out of everything. If you have e.g. 24
spaces and do a replace of nine spaces with one it will match the
first nine and reduce the 24 to 16, then match the first nine of those
and reduce them to 8, then match some block of nine spaces in a string
literal somewhere...

Didn't I previously mention being able to insert text at the
beginning of each of a selected range of lines, using a regular
expression that matches "start of line"? Well, perhaps it's not
obvious from that discussion that it would also be easy to delete
eight spaces at the start of each of a selected range of lines.

Of course, if it were possible to enter a newline into a search query
field you could limit it to the start of line and not mangle the
string literal. Most searches I've seen wisely don't attempt to match
pure-whitespace queries. And of course most treat enter as "do the
search" rather than inserting it literally into the query (and if it
did the latter, then how would you launch the freaking search??)

Perhaps it would help clarify things [*] to mention that I'm
not talking here about a combined search / search-and-replace
feature like what you get when you press control-F in a typical
Windows application. Search and search-and-replace are distinct
things in vim (and emacs).

[*] Or not. I don't seem to be having much success here at
communicating a sense of how this application actually works,
as opposed to how you seem to think it works.

(2) Use the .... Probably the simplest way to say this is "the
equivalent of control-I in Eclipse". (Yes, vim has something like
that. So does emacs.)

Use the what? Control-I is 0x09, the tab character. Are you saying you
have it set up to convert tab keypresses into spaces, then do an end-
run around this to insert literal tabs anyway? This seems to be even
more seriously broken behavior, and this time it's not software
behavior that violates least surprise I'm talking about, either, but
behavior of the component that goes between the keyboard and the
chair...

*NO* -- I'm saying that vim and emacs have a feature comparable
to what happens in Eclipse when you select some text and then
press control-I. I didn't mean to suggest that this functionality
was literally invoked by pressing control-I. (It's not.)

[ snip ]

Yeah .... Well, I don't like eight-character indents -- four
seems more reasonable -- so if I used literal tab characters,
I'd have to set all the tools I use for dealing with source code
to use something other than the default expansion, and anyone
else who looked at the code would also have to .... <shrug>
Another religious-war topic, I think.

No-one else who looked at the code would have to do anything of the
sort -- everyone could use their own preferred indent-per-tab when
viewing and editing, which is another argument strongly in favor of
real tabs.

Well, except that in my experience that doesn't always work very
well, for example if people use tabs to position inline comments
at the right of a line of code. <shrug>

So the explanation is that you don't like configuring things.

You have *no* idea .... I like it far more than I probably should.

As best I know, there's not a global setting that means "show all
tabs in text files as four spaces". I'm not sure how useful it
would be. <shrug>

It looks like I've nailed you on three more counts here.

Are you *trying* to make this more confrontational? Why? Or
am I meant to interpret this as humor, or -- well, I hear that
men are able to have heated discussions about technical topics
without taking it personally, and maybe that's what this is
meant to be. <shrug>

a) All that hand-hacking of configuration files does take extra effort
and translates into a reduced willingness to use non-default settings,
even when they'd only have to be set once per app.

Not for me.

b) Also, you're missing having a nice fat 200+-character-wide GUI text
box to edit in even if you claim you aren't.

I could perfectly well have a nice wide 200-character-wide text
box to edit in, if I wanted one. I don't, though, mostly because
I don't have a wide enough monitor to display 200 characters in
a font I'd find readable.

And I seem to remember reading somewhere that humans actually
find shorter line lengths more readable -- isn't there a reason
newspapers, magazines, etc., are printed in columns?

c) Finally, there's the little matter of there not apparently being a
single global "tab width" setting that everything uses. Isn't that the
sort of thing you claimed your preferred OS was good at, and isn't
this the sort of problem that you associate with evil Windoze and
dumbed-down MacOS? ;)

Oh, maybe. I'm not sure what I said that might have led you to
make this claim. I guess I could say that if the designers of
Unix had felt that such a feature would be useful, they'd have
included it, and who am I to question their wisdom? But that
would be sillier than I'm prepared to be ....

Yes, that *is* nice. Fortunately, vim and emacs provide similar
functionality.

Feep! Feep! More IDE-specific features in a supposedly general-purpose
text editor! Feep! Feep!

Nice for writing HTML too. And LaTeX source. And other things where
some notion of indenting things makes sense.

[ snip ]

No, I do not. What I do say is that I don't know of any tools that
are novice-friendly and also provide the set of expert-friendly
features I'm accustomed to and like.

"The set ... you're accustomed to and like". Perhaps they provide a
set, but it's as alien to you as the ONLY set of features provided by
your tools are to me?

Perhaps they do. Perhaps overall I would like your preferred
platform better, once I got past the learning curve. I've learned,
in this thread, about a few things I didn't realize were possible.
(That would seem to counter your claims about your platform
being more intuitive, but perhaps you didn't actually claim that
*everything* about it would be obvious to the beginner.)

Then again, based on this discussion it seems to me that you're as
unfamiliar with my preferred platform as I am with yours. So it's
hard to compare their features. Maybe we're about done here ....

[ snip ]

But I digress...)

Indeed you do. Sort of a :-).

[ snip ]

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