Re: SetCheck
"Joseph M. Newcomer" <newcomer@flounder.com> wrote in message
news:95qt83tg04v77u8j6o7lvve5jaqtg632t6@4ax.com...
Is that thing that comes with the IDE actually a "text editor"? Could
have fooled me.
A real editor is extensible, and you can write your own extensions and
bind them to any
key. You can also override any built-in behavior you don't like. All of
this is fairly
straightforward. Out of the box, real text editors allow high-speed
typists to do
everything they need to do without removing their hands from the normal
typing position:
no function keys, no arrow keys, no insert, delete, page up or page down
keys, and no
mouse, are required for effective high-speed editing. A real editor
allows you to have
thousands of files open, across multiple projects, and navigate them
trivially without the
use of a mouse. A real editor is not part of an IDE, but a tool which is
useful across
many problem domains, and therefore does not need to have a running IDE to
be useful in
the limited context of working on a single language or a small set of
languages. Real
editors do not get in the way of the task, they augment the typist.
The only thing I don't have in my real editor that might be nice is
Intellisense, but
since Intellisence in its current form isn't terribly useful I have little
reason to use
the editor just to get it (i have to look the call up anyway because I
need to know what
all the flags are in that UINT or DWORD),
EMACS-class editors are real editors. There are even some people out
there that think
'vi' is an editor, although EMACS users know this is not true. But
EMACS-class editors
(and vi) still exceed anything Microsoft has delivered. Editors are not
technology, they
are religion. This is Microsoft's greatest failure in the IDE, to have
not recognized
this on day one and provided for plug-in editor capability at the outset.
This EMACS vs. vi war was going on when I started my career 19 years ago. I
think it was more relevant back then, then now. There still is a certain
class of programming, like console apps that contain only your code, that
the extra ounce of power you can get with EMACS style macros buys you better
productivity. There, things like object browsers, resource editors,
Property editors, Intellisense autocomplete, and integrated Help don't
matter as much as when your main task is gluing prewritten components
together, and the main job is figuring out what methods and properties
should be used. Actually typing code becomes a minor part of the
development process.
Besides, the IDE editor isn't as bad as you claim, if you take the time to
investigate and use real IDE plug-ins like Whole Tomato Visual Assist X
instead of believing the only way to extend it is through VB Script macros!
If that isn't enough, some vendors offer entire replacement editors that
snap into the IDE. Codewright did this years ago.
In the early 1990's I was fed up with the IDE editor too, but developed a
way to quickly spawn Brief from the IDE and position it to the same file and
line number that I was in the IDE, so it was fairly rapid to bounce back and
forth. But even the editor in VC4 became powerful enough for the GUI
programs I was developing that I eventually stopped using Brief and
Codewright and stuck in the IDE.
The other major improvement was that mice have drastically improved over the
last 20 years. Back then they were boasting 150 dpi, now the dpi of laser
mice are in the thousands of dpi. A mouse is now an integral part of my
editing, and I type faster than 70 wpm. The need for pure typing efficiency
simply isn't what it used to be.
-- David