Re: Great SWT Program
In article <1193635594.039211.81730@57g2000hsv.googlegroups.com>,
<nebulous99@gmail.com> wrote:
On Oct 28, 5:40 am, blm...@myrealbox.com <blm...@myrealbox.com> wrote:
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).
If I set the taskbar to auto-hide, maximize Notepad, and use the
classic rather than XP theme and a sensible font size, the Notepad
titlebar, menu bar, and top and bottom borders take up IN TOTAL maybe
as much space as half of one line on your text terminal display.
And if I also choose a "sensible" font size .... Well, whatever. My
idea of sensible font sizes is different from yours. <shrug>
Nice would be a feature to set an "auto-hide menus" option in which
menu bars collapse when not in use (mouse in the area or alt hit). And
if taskbar auto-hide and this proposed menu auto-hide didn't cause
some problems with windows jumping about and reflowing themselves; the
taskbar in auto-hide mode should cover rather than push aside the
bottoms of windows IMO.
But those are problems of implementation, and a GUI can be devised
that lacks them.
A text interface will *always* be consuming a couple of lines for
status/prompt/help information OR forcing you to do shit blind.
I can't imagine why. If we're comparing hypothetical software,
what's impossible about modifying vim or emacs so it only uses
a line of the display for showing a search command in progress
(or similar) when that's actually needed?
[ snip ]
The 4% is, I presume, based on your continuing belief that these
applications are confined to the 80x24 windows of long ago.
It's assuming that you use them under conditions (e.g. hardware
limitations) that don't let you use modern alternatives, yes.
But why make this assumption?
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?
Being limited to 256 distinct characters displayed at one time kind of
cramps your style if you prefer to write in Chinese, yes.
I'm not willing to believe, without supporting evidence better
than your guesses, that text-mode applications running in suitable
environments can't display Chinese characters. A quick Google
search turns up some references to Chinese and vim that makes me
think vim can do it, but perhaps only in its gvim incarnation.
<shrug>
[ snip ]
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.
We weren't discussing the menus; we were discussing the basic input
commands and their combinations. Such as you'd use to navigate the
menus, or a document, or whatever. The key bindings, in effect, though
including the mouse too.
My mistake; I thought you were. If you're talking about key
bindings -- the ones whose purpose might be "intuitive" from what's
on the keycaps work about the same in your tools and mine, and
while control-C doesn't mean the same thing in my tools, well,
I'd argue that that's a matter of convention.
[ snip ]
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.
Eh...that doesn't happen to me.
Huh. So you think about where particular keys on the keyboard are,
every time you use them? I would guess not, based on other things
you've said, and that's the kind of thing I'm thinking about.
But it's not awkward.
I've had a couple of run-ins with each of vi and emacs, and I can say
with authority that nothing in them ISN'T awkward.
You can say with authority that they're awkward *FOR YOU*.
You can even speculate that they'd be awkward for most people.
When you claim that I'm mistaken about something I'm doing not
being awkward *FOR ME* -- yeah, whatever, I think we've done this.
[ snip ]
Not that I can remember, no, and that seems like the kind of
mistake I *would* remember.
It's the kind of mistake most people avoid by making sure it can't
happen, rather than by being (apparently) perfect.
As I do (make sure it can't happen). See below.
[ snip ]
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.
Eh? "How you start the editor"? You mean even that varies and involves
arcane parameters, instead of just "theeditor" or "theeditor
myfiletoedit" or even just "click-click"?
"vim" versus "pvim" (the latter being an alias I defined to start
vim with a different set of configuration parameters, the ones
I prefer when editing source code).
Sometimes I do type the wrong one. When the window comes up
with syntax highlighting for non-code, or no syntax highlighting
for code, I realize my mistake, exit, and reissue the command
(up arrow to retrieve previous command, modify, reissue). vim
being much quicker to start up than something like Eclipse, this
doesn't feel like a huge inconvenience.
[ snip ]
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".
And then you're falling back on the old fashioned method of "type the
whole thing and pray", since anything long enough makes the likelihood
of a typo get fairly high.
If the name is that long, it seems highly likely to me that
substantial parts of it will be unique, and those parts can be
filled in by tab completion.
I guess it could be a problem for people who don't organize their
files hierarchically, but instead have huge folders/directories
containing hundreds of files. But I'd think it wouldn't be
especially easy to browse such folders/directories with a GUI
file selection either. <shrug>
[ snip ]
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>
I bet it doesn't save as much typing as double-clicking on the file
you want ... ;)
No, but it saves on not having to locate the mouse and operate it.
(Sometimes my keyboard isn't on a desk, and the mouse isn't right
beside it.)
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.
Wonderful: so instead of changing
for (i = 1; i < 10; ++i) {
System.out.println(i);
}
into
for (i = 1; i < 10; ++i) {
System.out.println(i);
}
it will change it into
for (i = 1; i < 10; ++i) {
System.out.println(i);
}
Eeeuw. Yuck. Bleah.
Oh dear.
Well, this is embarrassing, and all I can say is that it probably
serves me right for thinking yesterday it was a good idea to post
when too sleep-deprived to be thinking straight. Or there may be
a variant of Skitt's law [*] at work here.
[*] Just for you: http://en.wikipedia.org/wiki/Skitt%27s_law
"dw" would not be an appropriate way to remove one level of
indentation, for exactly the reason you state. I can't imagine
now what I was thinking in mentioning it.
"4x" (to delete four spaces) would work better. I think. I don't
usually reindent code this way, and I'm not interested in doing
more experimentation.
Some years ago I decided that I preferred indenting with spaces;
it seemed -- less fragile and ambiguous, I guess. <shrug>
So much for preserving the logical structure of the document though.
Could be. I think I made this decision based on something someone
said in some newsgroup. I do rather think it's a religious-war
topic. Perhaps at some point I'll change my mind again.
No more dangerous than any other deletion. (And vim does have an
"undo".)
Everything has an "undo". It's relying on it to undo more than n
levels, undo a batch replace as one undo instead of sixty, and never
say "last deletion was too big to undo" that isn't safe for a computer
user.
None of this sounds remotely like my experience with vim.
[ snip ]
Contrasting with, for me:
Position cursor at start of line. "dw", up, ".", up, ".", ....
Except mine doesn't flatten the indentation completely; it just
removes one level.
Also, mine actually works. If "." is a synonym for "dw" you would have
used "." in place of "dw" at the start, and if instead "." is
something like "repeat last command" the "."s will act as up-arrows,
since that's what each is immediately preceded by.
I misspoke: "." is not "repeat last command" but "repeat last
change".
[ snip ]
or for that matter a real IDE with autoindent
functionality.
Which vim has, as does emacs.
A real IDE?
Not what I meant. I meant "autoindent functionality".
[ snip ]
If I'm going to be manager, I want to issue broad commands (e.g.
autoindent) and have the peons (computer software) do the scut-work.
If I'm going to be essentially doing all the work myself, I want to
just actually do the work directly. None of this micromanagement stuff
of having to give indirect instructions that get interpreted, like a
manager, and yet do as much detail work as if I were doing the work
directly...:P
Well, I rather like being able to let the computer do it, when
"it" is something I think the computer will do to my satisfaction,
while reserving the right to do my own scut-work [*] when that
seems the only way to get the results I want.
[*] With the caveat, of course, that it's quite possible I'll be
able to think of a way to automate the scutwork.
[ snip ]
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> )
I don't know, but it doesn't sound like it would do what you want
anyway -- the "." will repeat the last command, with the last command
having been "repeat search". So you'll be repeat-searching repeatedly
but not replacing anything.
See above. "Repeat last change". My bad.
[ snip ]
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.
Eh. Well you implied that control-I doesn't do nothing, and both keys
turn into ASCII 0x09 in the keyboard buffer...
No. What I said was that vim has something analogous to what
happens in Eclipse when you select some code and press control-I.
It didn't occur to me that you would interpret this as meaning
that the vim feature was also invoked by pressing control-I.
[ snip ]
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.
Ah ... the first significant concession ...
Yeah, right. Two key combinations (both chorded) as opposed to
four key combinations (one chorded, the others not), for something
one probably doesn't do that often .... If you want to claim
that as a significant victory, go ahead.
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?
Yes ... I hold space down until I'm near the right spot (a fraction of
a second) and then hit it a few times or hit bksp a few times. Later
if I edit the one line I go down and hit space or bksp or something.
It's simple, it works, and it's not particularly slow or anything.
Eww. (That's a biased reaction, though, as I'm quite sure there
are things I regularly do that are just as ugly.)
[ snip ]
The tricky thing being trying to convince me of things that seem
either implausible, or based on misunderstandings of the capabilities
of *my* tools...and in at least once case, misunderstanding of the
capabilities of my *hands* (that they would necessarily be slow and
fumbling to use the arrow keys relative to hjkl or the like)...
I don't think I'm the one who made that claim; I think that might
have been the emacs fan (Bent). "Whatever".
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.
People like you on large development teams end up getting shot. Er,
fired.
Should I interpret this as a threat? (I have a feeling you would,
if it were directed at you. Of course I could be wrong.)
Or at least, people wish they were. At least if the team tries
to have all the code in the repository in one style, even if displayed
to and edited by each separate team member in their preferred
style. :P Forcing your code to look "your way" to everyone ... gak. If
everyone else did that too, it would be complete and utter chaos! :)
When I have worked on code as part of a team, I've adopted
the team's conventions on matters of programming style without
complaint. We're talking here about code I write for myself ....
(You really have *no* idea.
I don't like the sound of that. Is that intended as an insult?
Anything nasty that it implies about me being false, of course...
Only in the sense that I think you shouldn't be so quick to
speculate on why I haven't "fixed" the "problem" of tabs normally
showing as eight spaces.
I'm amused by your guess because, as it happens, I *like* tweaking
configuration files and probably spend more time with that sort of
thing than most people seem inclined to. Micromanagement? Maybe.
The latter -- well, for suitable definitions of "terrible",
I guess.
Then you'll be glad to know of the invention of a clever little device
that mounts artificial lenses in a framework that rests upon the nose
and ears, so as to place a lens before each eye and thereby alter the
focusing of light so as to correct a wide variety of vision problems.
It's perhaps a recent enough invention, particularly relative to your
text editor of choice, that you might not have heard of it, but a
google search for "spectacles" or "eye-glasses" should turn up some
useful leads on how you might acquire a pair of your own ... ;)
What will they think of next?! (Attempted humor. I've been
wearing one of these devices for many activities for, hm,
over 40 years now. It's possible an updated prescription would
allow me to make out a 200-characters-per-line font without being
closer to the monitor than I find comfortable, but I'm skeptical.)
[ snip ]
As someone else pointed out, vim (like emacs) is quite capable of
using different rules for autoindenting for different file types.
More scope for surprise and peculiar behavior,
Huh? If you were using Eclipse to edit both Java and something
with different conventions for indentation, you'd be startled if
Eclipse took those different conventions into account?
and even for having to
rename a file sometimes to edit it the way you want to if the editor
has other plans. More examples of "jack of all trades, master of
none". Or perhaps that should be "hack of all trades"...
Don't confuse vim with typical Windows applications -- "editor has
other plans" applies a lot better to the latter than the former.
I can't quite think why I'd want to edit Java code with the C
indenting rules, but if I did, I'm fairly sure I could accomplish
it in some way that didn't involve a file rename, and if I wanted
to do it often, it wouldn't be difficult to set up a way to do it
that didn't involve a lot of tedious option-setting every time.
--
B. L. Massingill
ObDisclaimer: I don't speak for my employers; they return the favor.