Re: Great SWT Program
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.
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.
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.
It's assuming that you use them under conditions (e.g. hardware
limitations) that don't let you use modern alternatives, yes.
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. In much the
manner that being limited to 100 or so KPH and all four tyres firmly
in contact with the ground at all times kind of cramps your style if
you plan to drive the vehicle all the way from New York to Paris. Or
Hong Kong for that matter.
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 ....
I suspect it's because they find the tools fun to poke around inside.
There are those who spend hours twiddling with string or a Rubik's
cube. Millions of dollars are spent on things like baseball and rugby.
Entertainment is a funny thing that way. It also doesn't (usually) get
the bills paid and put food on the table.
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.
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.
It's navigating in them that poses the problem, once you have more
than one, and given that alt-tab doesn't do the natural thing.
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.
Eh...that doesn't happen to me.
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. What could be done
with a mouse click instead involves a ton of typing, often of fiddly
and exactingly-interpreted chains of punctuation characters. This sort
of interface is going to be flatly unusable to anyone that isn't a
fully-fledged computer programmer, and seems like unnecessary work for
anyone that is. They have enough LOC to write as their actual primary
task, without having to write as many more just to make the text
editor do its thing, all because they lack a decent graphical
workstation and a decent IDE. :)
And of course, those extra LOC have to be written without benefit of
compile, test, debug cycles or development environment tools. They
have to be typed at a line prompt and submitted with a prayer. And if
there's a bug ...
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. Your tools seem
unsuited to those of us without green blood and pointed ears. :P
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"?
Lovely.
Just freakin' lovely.
And ... it figures.
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".
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. And of course if you get it wrong it's back
to square one. A GUI, you miss by a pixel with a click, you nudge the
mouse and click again. None of this fiddly typing! Typing is for data
entry and occasionally for shortcut keys, not for typing every damn
command you could just click. :P Making the interface based on typing
in commands by name instead of selecting them in a menu type of way
with common ones having a ctrl-something type shortcut means a
Hobson's choice: long, meaningful names that still are hard to
remember because they have synonyms and are also tedious to retype and
easy to mistype, or short, cryptic ones that are easy and quick to
type, but you'll be spending much more time flipping through the help
or consulting a cheat-sheet. Shee-yit. My all-time favorite synonym
pair has to be "quit" vs. "exit" and never knowing which one it is
(and occasionally finding something where it's neither, and then what
the fuck is it???) ...
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 ... ;)
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.
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.
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.
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.
It sounds like it has features too narrowly specific for even a "yes-
frills" text editor, however. Such would focus on frills that help
with email, news, and other instances of English prose. Code editing
features are IDE features, and you might as well use a real IDE with
integrated debugging and the works if you're editing code.
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, ".", ....
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.
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.
Still, an awkward workaround for something I wouldn't need it for.
(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.)
It is, if I hit up and then del one or more times, then up, etc.
or for that matter a real IDE with autoindent
functionality.
Which vim has, as does emacs.
A real IDE? Emacs, probably. Vim? I didn't think it did. And even if
so ... jack of all trades implies master of none. If it has e.g.
newsreader features and other such stuff you can bet your asteroids it
is no great shakes as an IDE, compared to something designed from the
ground up to be an IDE, like, say, Eclipse.
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?
I guess it would have to be the latter. Some of the illusions you
experience are ones I've already explained, and "time flies" should be
familiar to everyone. The others I lack the specific technical
knowledge to explain.
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.
In other words "Easy for an experienced computer programmer who
doesn't mind being forced to use those skills merely in the service of
editing text".
Micromanagement. Ick.
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 Similar reason I prefer Java to C++ ... no need to
micromanage memory allocation and freeing, that's the single biggest
plus after near-automatic portability of the software even if it uses
graphics, the mouse, threads, etc. that the C and C++ standard
libraries don't accommodate but Java's does.
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.
Anything that forces the user to think in terms of the implementation
instead of the basic semantics of their task is crufty. Search is
search is search and replace is something you optionally do as part of
search. They can be implemented as different routines under the hood
(but the search should be refactored into a single search routine
anyway) but exposing this to the user is sucky.
http://www.useit.com/alertbox/generic-commands.html was just posted in
the last 48 hours and has many pearls of wisdom relevant to this
thread, including discussions of cut, copy, and paste. (Typical
windows apps these days also implement the delete and move operations
discussed there -- delete or backspace will delete the current
selection without touching the clipboard contents, and dragging a
selection with the mouse will move it without clobbering the
clipboard, though not conveniently unless the destination is within
one screen height of the source.)
It specifically discusses not exposing implementation details
needlessly to the user, as well.
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.
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.
Eh. Well you implied that control-I doesn't do nothing, and both keys
turn into ASCII 0x09 in the keyboard buffer...
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)
In a GUI app, yes, because GUI apps have low-level access to the
hardware, keyboard and mouse both. But we're discussing a terminal
mode app. These see a keyboard buffer with ASCII codes sitting in it.
Tab and Ctrl-I both become 0x09 in this buffer. (This also makes
putting non-ASCII text into the editor a wee bit problematic, of
course.) A terminal emulator running in X might intercept one of them
and translate it into something else, but that wouldn't be a feature
of the text editor you might or might not be running in that terminal
session...
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 ...
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.
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.
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)...
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. 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! :)
(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...
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 ... ;)
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.)
Well, yes, it's usually method declarations that need refactoring to
package parameters into fewer, larger objects or to divide the method
into more than one with more tightly focused responsibilities. But
until then ... and, of course, sometimes it's just long descriptive
identifiers, especially a throws clause full of things resembling
SomeLongAndDescriptiveNameException :)
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, 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"...