Re: Great SWT Program
- From: blmblm@xxxxxxxxxxxxx <blmblm@xxxxxxxxxxxxx>
- Date: 28 Oct 2007 09:40:41 GMT
In article <1193452732.071978.145320@xxxxxxxxxxxxxxxxxxxxxxxxxxx>,
<nebulous99@xxxxxxxxx> wrote:
On Oct 26, 9:04 am, blm...@xxxxxxxxxxxxx <blm...@xxxxxxxxxxxxx> wrote:
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.
That's better than I expected of it, but it must gobble precious
screen real-estate.
vim does seem to reserve two lines of the display for things other
than the text being edited. The second of those two lines seems
to be somewhat multipurpose, and it's the one in which search or
"ex" commands in progress are displayed. I'm not sure I get
how this is more of a sacrifice of screen real-estate than the
typical GUI's title bar, menu bar and toolbar(s).
Devoting one line to some sort of command line
means losing about 4% of the total screen area from being available
for document editing.
The 4% is, I presume, based on your continuing belief that these
applications are confined to the 80x24 windows of long ago.
[ snip ]
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?
Perhaps, but that would be like putting life vests with parachutes
into the seatbacks on an Edsel. Since it won't be making
transcontinental flights at 38,000 feet, they'd be somewhat
superfluous there, I think you'll agree.
Huh? Text-mode applications aren't used by people whose primary
language is other than English?
[ snip ]
I don't know, actually. But those tools seem to be ... not so much out
of date, as half-out-of-date and half not. Someone didn't merely keep
their 1960s-era wide-body Ford with the tail fins. They didn't even
merely keep it and lovingly restore it to factory-new condition. They
didn't even merely do all this and *actually drive it as their main
vehicle for getting around in*. They embarked on a program to try to
convert it for spaceflight and have the curious notion that it might
actually fly them to the moon!
I wonder why that is. Could it be that the people doing this actually
find these tools you poke fun at useful? Nah, that can't be it ....
[ snip ]
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?
Well, there's three approaches to user interface design and command
orthogonalization, it seems. Compare them to street layouts:
[ snip your take on emacs ]
Modern GUI -- A nice, simple grid. Even a newcomer can quickly figure
out how to get to places like 1st and E street. Clear signage anyway.
My mileage varies. Often I'm unable to guess where the feature I
want might be hiding in the hierarchy of menus and submenus and,
um, stuff. Sometimes the online help is useful. Sometimes it's
not. "In my opinion", maybe.
Vi -- A grid, but it's nighttime and the streetlights don't work.
Neither does your car (mouse), so you have to walk (hjkl) or ride the
bus (jump around using search).
Vim -- car is fixed, except for the headlights. Also, street signs
have been posted. Now if you could just read in the dark...
Huh? Pretty much everything I need to know is on the screen.
If I want to access the online help and still be able to view
the text I'm editing -- I can do that by splitting the window.
[ snip ]
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.
It's a guess, but given that you had to think for a bit to find the
key to press when actually discussing it, I'm guessing you have to
whenever, and the fact that you were actually discussing it merely
made you consciously aware of the fact where you otherwise weren't.
Since it makes more sense than the alternative, which is that hitting
your "up" key requires more thinking when you're discussing "up" keys
than simply when you're editing text and moving up in it. Why would it
be context sensitive how much thought is required in translating the
imperative to "hit the up key" into a motor action?
I don't know, but I believe that it is, in much the same way
that I sometimes find it easier to key in a frequently-dialed
phone number than to tell someone what the number is. The first
relies on -- what did you call it a while back? motor memory? --
while the second doesn't, and requires conscious thought.
[ snip ]
Didn't I explain that this whole thing is "you don't like tabs"
followed by assorted awkward kludgy workarounds for using spaces when
the logical structure of what you're editing would use tabs? Bandaging
your foot because you shot it and then limping everywhere and blaming
the limp on having a hole in your foot without acknowledging that it
was self-inflicted seems a bit ... odd. OTOH, I'm not sure that what's
going on isn't more analogous to not even admitting that the limp
exists, perhaps even to yourself ... hmm ...
But it's not awkward. Generally I reindent code with vim's
autoindent anyway, and if I don't -- deleting four spaces at the
beginning of each of a range of lines is simply not the tedious
operation you seem to think it is.
Well, no, because I don't edit makefiles with the "turn tab
characters into spaces" feature on.
And you never forget to toggle it?
Never, ever?
Not even just once?
Not that I can remember, no, and that seems like the kind of
mistake I *would* remember.
It probably helps that I'm not toggling it every time I start
the editor; depending on how I start the editor I get different
sets of configuration parameters, and the ones I use for code
are different from the ones I use for makefiles.
[ snip ]
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.
So it has a special case for every file in the directory having the
same long prefix. Not much use when many of them do, and many don't,
e.g. there's also a myLisaBoylePictureArchive.zip in there. :)
A special case? I'm not sure what you mean. We don't seem to be
communicating very well here, so probably I should just give up,
but let me try once more:
Pressing tab fills in as much of the filename as possible.
In some situations, such as the one you describe, "as much as
possible" will be "none at all". In that case, the user will have
to type one or more additional characters and press tab again.
In your scenario, typing an "o" and pressing tab again might be
enough to get "myLongFileName". Or it might not (for example if
there was also a file named "myLookAtMe". In practice I find
that this feature saves a fair amount of typing. I'm sure one
can construct examples in which it doesn't. <shrug>
If I remember right, recent versions of Windows's command shell
(? -- command.exe, or whatever it's called) do something similar
to what I'm trying to describe. I can't quite be bothered to
boot Windows to try it out. Perhaps if someone else who knows
both systems is reading this, he/she would be willing to chime
in with a quick compare-and-contrast.
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.
So you can bind some key to "delete eight characters at a time" or
something? What a crufty workaround.
There are several options in vim for deleting more than one character
at a time. The one I'd probably use here is "dw" ("delete word"),
which in context would delete the leading whitespace.
What do you have against tabs, anyway?
Some years ago I decided that I preferred indenting with spaces;
it seemed -- less fragile and ambiguous, I guess. <shrug>
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").
Sounds dangerous, especially when applied to anything with the word
"delete" in its description.
No more dangerous than any other deletion. (And vim does have an
"undo".)
(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.)
Feep! Feep! IDE feature detected in "no-frills" text editor! Feep!
Feep!
I wouldn't describe vim as a "no-frills" text editor -- to me that
would be something with just enough functionality to perform simple
edits. If that's all vim was, I'm not sure I'd be trying so hard
to defend it here.
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").
Well, manually unindenting a few lines is as simple for me as up, del,
up, del...
Contrasting with, for me:
Position cursor at start of line. "dw", up, ".", up, ".", ....
Manually unindenting them with spaces instead of tabs would be
nastier. Unindenting one is as simple as getting to the eighth
character and hitting shift-home delete, but the repositioning to the
eighth character on the next line is the spoiler. Just another reason
to use real tabs,
Yes, I can understand how that would be a problem for you.
It's not for me. See above description of how I would do this
if I wanted to make the change line by line. (Moving up one line
after deleting leading white space leaves the cursor at the start
of the line. I gather this is not the case with your editor.)
or for that matter a real IDE with autoindent
functionality.
Which vim has, as does emacs.
(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?
You expect me to just believe everything you say, even when it's the
equivalent of "I've invented a perpetual motion machine!" or "I spent
the week at Alpha Centauri -- took two whole days to get there and two
to get back so I was gone for 11 days total"?
Well, it seems to me that either you believe me, or you think I'm
lying, or you think I'm deluded. Which is it?
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.
"Easy"? It can't possibly be, because that isn't a query you can
possibly simply type in literally. You'd have to specify it as some
sort of code, which basically means writing a short, novel program.
That program will contain a bug in its first draft. And then you turn
it loose deleting things ...
Well, if by "easy" you mean "easy for a complete novice" -- no, it's
not. "Easy for someone moderately familiar with vim and regular
expressions" -- yes.
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).
How crufty.
Similar syntax is used in both. I don't quite get how this is
crufty, unless you insist that anything that doesn't behave exactly
like the Windows applications you're familiar with is crufty.
In practice I often do search-and-replace by finding the first
occurrence of the thing to replace, using something like "cw"
("change word") to replace it, and then a combination of "n"
(repeat search) and "." (repeat command) to continue searching
and replacing. (Why am I telling you this .... <shrug> )
[ snip ]
*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.)
Oh. Of course it's not. Anything that inserts a literal tab in one of
these unix tools will be bound to some key other than control-I,
because making it so that control-I (and thus the tab key) did it
would be making things too easy, wouldn't it? :) So tab (and control-
I, both produce ASCII 0x09 after all) produces eight spaces and
something else produces tabs, of course; perfectly logical. :)
What *ARE* you on about here. In insert mode, tab either inserts
a literal tab character, or however many spaces are needed to advance
to the next tab position, depending on settings. In command mode,
tab does nothing.
Reformatting selected text using the autoindent rules currently
in effect -- what Eclipse does when one selects text and then
presses control-I (which is different from simply inserting a tab) --
is also easily accomplished in vim, but .... I'm not going to
describe it, but reformatting the whole file takes four keystrokes.
Admittedly one can do it in Eclipse in two. <shrug>
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>
I never do that. If I had two tabs and 31 characters of code, a space,
\\, and a comment, I'd continue it on the next line with two tabs, 32
spaces, \\, and the continuation.
Hm. I guess there's some nice way to generate those 32 spaces? and
adjust them if the 31 characters of code becomes 30, or 32?
[ snip ]
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>
Well, I am getting tired of your only rarely and grudgingly admitting
that I might be right about GUI tools being (with appropriate, not too
hard to acquire proficiency) better to work with ... :)
And I'm getting tired of what feels like explaining the same things
repeatedly, to someone who seems determined to think the worst of
a tool he obviously knows little about. I keep saying "are we done
here?" and then letting myself get sucked into one more round of
attempted explanation.
And (this may offend) sometimes it seems to me that women are unable
to have discussions about anything without getting emotionally
invested. :P :)
There's some truth to this particular gender stereotype (as there is
to many of them).
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.
Your own lack of desire to configure all your stuff to four-character
tabs seems to belie that claim.
If I wanted to do that, I'd figure out how to do it. But I don't.
A lot of my preference for using spaces rather than tabs has to do
with wanting my code to look the same to others as it does to me.
Tweaking my own configuration files wouldn't accomplish that.
(You really have *no* idea. I suppose if one finds the prospect
of configuring something by editing text files off-putting, one
might not do much of it. I don't feel that way, and probably go
further than I should in customizing my environment.)
[ snip ]
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.
Hrm ... unusually narrow monitor or terrible eyesight?
The latter -- well, for suitable definitions of "terrible",
I guess.
[ snip ]
Regardless, I find lines of code to be far more readable when they
DON'T wrap. I'd take a single 150-character long line over
Huh. I guess your code doesn't have to be readable to anyone who
has trouble with fonts small enough to put all that on the screen
without scrolling then. <shrug>
(My mileage varies here too -- I prefer shorter lines.)
[ snip ]
And there's no one-size-fits-all for those anyway. HTML, LaTeX, and
Algol-derived languages are indented using three different cues;
indenting based on {} nesting will only be appropriate for the third,
for instance. So no matter what the editor uses to decide, it will get
it wrong for at least two of those three. Specialized IDEs for each of
the three will, however, be able to apply one that's sensible for
their particular input, because it's known at programming-time what
that input will be (e.g. Java source when programming a Java IDE).
As someone else pointed out, vim (like emacs) is quite capable of
using different rules for autoindenting for different file types.
[ snip ]
--
B. L. Massingill
ObDisclaimer: I don't speak for my employers; they return the favor.
.
- Follow-Ups:
- Re: Great SWT Program
- From: nebulous99
- Re: Great SWT Program
- From: Lew
- Re: Great SWT Program
- References:
- Re: Great SWT Program
- From: bbound
- Re: Great SWT Program
- From: blmblm
- Re: Great SWT Program
- From: nebulous99
- Re: Great SWT Program
- Prev by Date: Re: No coercion in for-each loop?
- Next by Date: Re: No coercion in for-each loop?
- Previous by thread: Re: Great SWT Program
- Next by thread: Re: Great SWT Program
- Index(es):
Relevant Pages
|
