[Informer] Request for user comment
Shlaer
If you use Informer, an Inform specific editor for Windows, please send me your
comments. I am thinking of revising it and need your help and suggestions.
E-mail your thoughts to shl...@aol.com as well as (if you wish) posting them.
If you want to test the new version in a few months, be sure to let me know;
your efforts will be appreciated. If you don't use it but are curious, get
InEdit10.zip from the editor section of the archive at ftp.gmd.de.
First, is there any reason to do a revision? Several visual IDE's are available
or in development and these may make Informer unnecessary.
Second, should v2.0 of Rich Edit be used? It has a built in undo system which
would almost guarantee that undo can be made to work right. (The undo now used
has bad bugs.) On the other hand, it is very slow in loading and streaming
long files (about five times slower than v1.0, 22 sec to load a 400k file on a
200MHz machine). Slow speed is a big problem if an outline feature is added
that lets you have some sections showing and some hidden. Is v2.0 on your
machine? (Search for riched20.dll.)
Third, should there be some sort of provision for languages other than Inform?
It wouldn't be too hard to read in a language definition file with key words
and some additional menu items that paste in blocks of text and format them. It
would be much harder to take care of the very specialized parts of the
language. Inform abounds in these, and if it is to be captured in a definition
file, something will be lost. Inform could be the only language or could be
treated specially. In that case you might wind up with, for example, a crippled
TADS editor with some useless Inform remnants on the menus.
Fourth, how important is it to accommodate the style of Inform where -> is use
for the object tree and where Bird Kestrel is used instead of Object
Kestrel...Class Bird? At present you can write such code, but the chart of the
object tree will not be correct.
Tell me the bugs you have found. Tell me about other problems. Tell me your
suggestions. A list of planned changes follows.
Changes to be made:
fix major bugs in undo (if I can)
add outline feature (may be hard not to lose formatting)
allow entry form to be closed or escaped avoiding changes to file
fix bugs in convert or allow class names and arrows
mention add on spell checker in help file (problematic)
syntax highlight one line or word at a time (how to do quoted text?)
allow sort of object tree and routines
Changes made or being worked on:
map bugs fixed
allow room addition while viewing map
exit menu item now saves
prevent endless multiple error boxes after failed compile
can view all files in open dialog
line numbers added
write space indented text files
finds a routine that starts a file and excludes [ in comments
word wrap can be turned off
more elaborate syntax highlighting
routines inside comments not listed
Bill Shlaer
Larry Smith
Shlaer <shl...@aol.com> wrote in message
news:20000221184513...@ng-fx1.aol.com...
I haven't looked at any of the specialized Inform editors out there, so I
don't know how off-the-mark the following question is.
You talk about loading a 400K file into a Rich Edit control. Why in the
world would you want to do this? Just show a single Object / Routine / Class
at a time, and load in just the relevant text. Don't bother the programmer
with irrelevant details (i.e. other Routine definitions).
If s/he really does need to see multiple routines et al, because they
interact, that's what separate windows are for.
Consider something like the Smalltalk editor model, where you have a listing
of all the classes (including, in this case, a pseudo class called, say,
"(Global)" for utility routines, one called "(Verbs)", etc. Within that you
can view the properties and attributes of the object, and edit the
corresponding text.
But nowhere do you need the entire source in the edit control at once.
Marnie Parker
>From: "Larry Smith" lrsFive(repl_Five_by_5)@mindspring.com
>Date: 2/22/00 8:54 AM Pacific Standard Time
>But nowhere do you need the entire source in the edit control at once.
Unless you're like me, and skip around quickly, especially from top to bottom.
Doe (scratching head trying to envision not being able to load a complete
source file)
doea...@aol.com ------------------------------------------------------
Inform Tips - http://members.aol.com/doepage/infotips.htm
IF Art Gallery - http://members.aol.com/iffyart/
IF Review Conspiracy - http://www.textfire.com/conspiracy/
Gunther Schmidl
> >But nowhere do you need the entire source in the edit control at once.
>
> Unless you're like me, and skip around quickly, especially from top to
bottom.
Seconded. Not being able to have the whole source in front of me would be
terrible, especially since stuff is totally interconnected. That's also why I
like to keep my source (except libraries) in a single file.
Sorry to all the IF GUI authors out there, but object oriented editing doesn't
do it for me. Give me a nice UltraEdit clone with Graham's syntax coloring
algorithm and I'm happy as can be.
<PLUG INTENSITY=SHAMELESS> Of course, my own wordfile for UltraEdit ain't all
that bad, either :-) </PLUG>
--
+-----------------+---------------+------------------------------+
| Gunther Schmidl | ICQ: 22447430 | IF: http://gschmidl.cjb.net/ |
|-----------------+----------+----+------------------------------|
| gschmidl (at) gmx (dot) at | please remove the "xxx." to reply |
+----------------------------+-----------------------------------+
Larry Smith
Marnie Parker <doea...@aol.com> wrote in message
news:20000223030540...@ng-fy1.aol.com...
> >Subject: Re: [Informer] Request for user comment
> >From: "Larry Smith" lrsFive(repl_Five_by_5)@mindspring.com
> >Date: 2/22/00 8:54 AM Pacific Standard Time
>
>
> Unless you're like me, and skip around quickly, especially from top to
bottom.
Sorry guys, but I think you're missing the point.
If you're skipping around all that much, you either a) don't have your code
well organized (and thus are paying a price (time) for finding all this
stuff), or b) don't have an editor that helps you with this, or c) both.
For example, suppose you're working with routine <foo>, and you've got a
reference to subroutine <goo>. Suppose you could double-click "goo" and
*poof*, you're now editing <goo>? And a <Back> button takes you back to
<foo>. Who needs to do all that scrolling? You're just doing this because
most editors are fairly primitive in certain respects.
The fine details of the user interface are interesting, but not fundamental.
Double-clicking usually selects a word (say, to subsequently copy it to the
clipboard), rather than to jump to another routine. But since you usually
jump rather than copy, maybe this could be the default processing (under
user profile control, of course). If you really wanted to copy it, you might
have to drag the mouse across it to select it. Or select it in either way,
but the right-mouse button pops up a menu of Jump, Copy, Open in new window,
etc.
I don't want the following comment to be considered a flame. It's not. But
you're treating a source program as a long paper listing and/or deck of
punched cards. And yeah, that works. Proof? People have been using this
model for over 50 years. And maybe that's a hint that there's a better way
to approach the matter...
Larry Smith
Larry Smith <lrsFive(repl_Five_by_5)@mindspring.com> wrote in message
news:8917fn$6tb$1...@nntp3.atl.mindspring.net...
> I don't want the following comment to be considered a flame. It's not. But
> you're treating a source program as a long paper listing and/or deck of
> punched cards. And yeah, that works. Proof? People have been using this
> model for over 50 years. And maybe that's a hint that there's a better way
> to approach the matter...
Just had another quick thought. Consider the following spin on Kennedy's
famous line...
"Ask not what you can do for your program. Ask what your editor can do for
you."
This is meant to be a bit humorous, but mostly it's meant to get people
thinking of an editor as more than a glorified keypunch. Think about what
you do in an editor, and what things are difficult (e.g. finding a given
subroutine in a 400K file). Then think about how you could program an editor
to help you with these things. Get the computer doing most of the grunt
work, so you don't have to.
The sky's the limit, folks!
Andrew Plotkin
> "Ask not what you can do for your program. Ask what your editor can do for
> you."
The lines between my gruntwork, my habits, and the mental organization I
use to get work done are not so clear-etched as you believe.
What my editor can do for me is behave like an editor.
--Z
"And Aholibamah bare Jeush, and Jaalam, and Korah: these were the
borogoves..."
okbl...@my-deja.com
doea...@aol.com (Marnie Parker) wrote:
>
> Unless you're like me, and skip around quickly, especially from top to
bottom.
>
complete
> source file)
That's actually not an uncommon reaction of seasoned programmers to
Smalltalk environments, which have that as a feature.
The only real drawback is that sometimes (organized or not) you want to
look at more than one routine at a time. This is made possible by
popping up multiple windows which is fine, but not as convenient as
having one big text window you can bookmark and pop back and forth
through without resorting to mouse clicks.
It could be done well, though. An editor could "stack" methods in its
window and provide special keys through paging back and forth through
recently worked on methods.
--
[ok]
Sent via Deja.com http://www.deja.com/
Before you buy.
Marnie Parker
>Date: 2/23/00 10:56 AM Pacific Standard Time
>That's actually not an uncommon reaction of seasoned programmers to
>Smalltalk environments, which have that as a feature.
>
>The only real drawback is that sometimes (organized or not) you want to
>look at more than one routine at a time. This is made possible by
>popping up multiple windows which is fine, but not as convenient as
>having one big text window you can bookmark and pop back and forth
>through without resorting to mouse clicks.
>
>It could be done well, though. An editor could "stack" methods in its
>window and provide special keys through paging back and forth through
>recently worked on methods.
Okay. Maybe.
Doe
Marnie Parker
>Date: 2/23/00 10:26 AM Pacific Standard Time
Seconded.
From: "Larry Smith"
>Sorry guys, but I think you're missing the point.
You may not be getting the point, either. I don't need an editor to do my
mental organization for me. I'd also probably resent it if it tried to.
Doe :-) But "different strokes for different folks."
Kathleen M. Fischer
okbl...@my-deja.com wrote:
> In article <20000223030540...@ng-fy1.aol.com>,
> doea...@aol.com (Marnie Parker) wrote:
> >
> > Unless you're like me, and skip around quickly, especially from top
to
> bottom.
> >
> > Doe (scratching head trying to envision not being able to load a
> complete
> > source file)
>
> Smalltalk environments, which have that as a feature.
>
> The only real drawback is that sometimes (organized or not) you want
to
> look at more than one routine at a time. This is made possible by
> popping up multiple windows which is fine, but not as convenient as
> having one big text window you can bookmark and pop back and forth
> through without resorting to mouse clicks.
>
> It could be done well, though. An editor could "stack" methods in its
> window and provide special keys through paging back and forth through
> recently worked on methods.
Ugh... I worked in environments that sound similiar to that many years
back (Motif WYSIWYG GUI builders) and I hated them. Heaven forbid you
decide to rename a global variable, you could be clicking through
windows for hours trying to find all the places you used it. And what if
you remember that you "did something like that" in some object but you
don't recall which one? At least with 400K of text you can scroll
through it from top to bottom fairly quickly. But to click open all
those objects to find the snippet? The code might as well have never
been written. And you can forget skimming through other people's code to
get a "feel for it", or to try to glean helpful code tidbits from it.
Kathleen
--
-- Excuse me while I dance a little jig of despair.
Larry Smith
Andrew Plotkin <erky...@eblong.com> wrote in message
news:8918pb$dhr$3...@nntp2.atl.mindspring.net...
> Larry Smith <lrsFive(repl_Five_by_5)@mindspring.com> wrote:
> > "Ask not what you can do for your program. Ask what your editor can do
for
> > you."
>
> The lines between my gruntwork, my habits, and the mental organization I
> use to get work done are not so clear-etched as you believe.
>
> What my editor can do for me is behave like an editor.
But what started this thread was enhancements to an editor. What's the
definition of "behave like an editor"?
Yeah, I once thought that an editor was (to continue my deliberately archaic
simile) like a glorified keypunch.
But you know what? I'm *much* more productive in an editor where it can, for
example, do the following.
a) Show me all the source files (including headers) that comprise my
program, and let me call up the source module with a click. It's a single
(hobbyist) program that's currently over 6,000 lines and has around two
dozen source modules.
b) Since it's in C++, I can have a tree widget with all my classes. Clicking
on the name of the class brings it up in the editor (it knows what source
module it's in). Expanding a node (class) shows me the members, both methods
and variables. The editor is smart enough to know that if I click on a
variable name it brings me to the line in the class definition. But if I
click on a method name, it takes me to the actual definition.
c) A built-in multi-file search (grep) command that lets me find, for
example, all comments that start with "TODO", arranges them in a window, and
then a click into that window brings the source module up positioned at the
correct line.
d) Invoke macros which can modify the source. For example, have you ever
taken the effort to produce a pretty boxed comment before a section of code
with, say in C/C++/Java/etc, a box at the top like "/*********/", ditto at
the bottom, and each line of the text in between framed between /* comment
... */, with the */ right-justified? And then you have to go back and change
one of the comments, and poof, your careful formatting has been blown, and
you have to reflow the text. Which explains why most people try this once or
twice, and then never again. But with a macro to do the work (which I've
written for myself), I type Alt-Shift-C, and the macro finds the boxed
comment, unboxes it, reflows the text, and re-boxes it.
And I'd like to see a keypunch to that! :-)
etc, etc, etc
So bringing this back a bit closer to Inform...
Let's remember that we're talking Inform editors here, not general purpose
ones. Yeah, in some languages, such as straight C, there really isn't
anything in the source code that ties the pieces together. Yeah, *you* know
that subroutines <foo_a> and <foo_b> are logically related, but other than
putting them into the same source module, there's no other way to specify
their inter-relationship. (And just putting them into the same source module
doesn't really prove anything, although this does have a meaning in Java.)
But in Inform there's a natural structure. Even if you don't use <Class>es,
you've still got a a connection among the various parts of an Object, such
as Properties, Actions, etc. An editor can help exploit this by grouping
them. And this way your job is simplified. You don't have to keep track of
things as much.
And if you say that you still have a lot of service routines that you have
to keep track of, and find, etc, there are several possible approaches to
this. In addition to the double-clicking I mentioned in a previous message,
the editor, in principle, could do a bit of background parsing. Reminiscent
a bit of the <tags> program used by several editors (but more integrated in
this vision), you could have the editor look for all the subroutines used by
an Object, and group those into a sort of second-tier set of associated
routines. (This in turn could go 3-deep, etc. There are obvious details to
be worked out here, such as calls to library routines, etc.)
Another idea is to keep track of each subroutine modified and to be able to
present you with a list of the subroutines modified in reverse order. Much
of the time you're working with a relatively small number of routines. Maybe
presenting the routines in this fashion could help.
And so on, and so on, and so on. (Hey, you're the "begatting" guy. You above
all should relate to this! :-))
The idea is to decide what the ideal tool looks like. As I said, what can
the editor do for you? And even if, as you say, "the lines between my
gruntwork, my habits, and the mental organization I use to get work done are
not so clear-etched as you believe", this doesn't mean that you can't
consider how improved tools could make your programming life easier. And
maybe that means you'd have to modify some of your organizational approaches
too. I know myself that on more occasions than I'd like to remember, I
resisted something at first later to fully embrace it. (One example that
comes to mind was meeting languages that forced you to declare all
variables.)
And hey, there's nothing in the rulebooks that says we can't use multiple
editors. Suppose you find that an editor that organizes Inform programs by
Objects, etc works for you only, say, 70% of the time, but that it's really
nice when it does meet your needs. But the other 30% of the time, you need a
big sprawling show-me-everything-at-once editor, fine. As long as you can
shift between the two on an as-needed basis, you're probably ahead of the
game.
Andrew Plotkin
>
> Andrew Plotkin <erky...@eblong.com> wrote in message
> news:8918pb$dhr$3...@nntp2.atl.mindspring.net...
>> Larry Smith <lrsFive(repl_Five_by_5)@mindspring.com> wrote:
>> > "Ask not what you can do for your program. Ask what your editor can do
> for
>> > you."
>>
>> The lines between my gruntwork, my habits, and the mental organization I
>> use to get work done are not so clear-etched as you believe.
>>
>> What my editor can do for me is behave like an editor.
>
> But what started this thread was enhancements to an editor. What's the
> definition of "behave like an editor"?
BBEdit Lite 4.6, at the moment. In that sentence, which contains the
phrase "for me".
I could go through your post and pick out all the examples of the
differences between the way you work and the way I work. But it boils down
to, you want a tool that works the way you work. Guess what I want?
Larry Smith
Kathleen M. Fischer <green_g...@my-deja.com> wrote in message
news:891jc6$er9$1...@nnrp1.deja.com...
I get your point and sympathize. But what it sounds like to me is that your
"editor" (or, as you more properly term it, "environment") lacked an
adequate "search" command, one that spanned multiple modules / classes /
whatever. And your editor/compiler didn't have a cross-reference feature to
let you find those globals. Or perhaps a multi-module "replace" command,
that was syntax-aware enough to not replace "food=1" with "good=1" when you
were trying to rename global "foo" to "goo".
It seems to me like you're condemning the whole thing because you were
missing a few crucial tools.
Let me ask you this. If we can put aside the (valid) complaints above, how
was it otherwise? When you weren't trying to rename a global, etc, did this
type of editor make your programming life easier? If so, why? If not, why
not? Or were you just so frustrated with the above shortcomings (and
possibly others) that the whole thing just left a bad taste in your mouth?
> At least with 400K of text you can scroll
> through it from top to bottom fairly quickly. But to click open all
> those objects to find the snippet? The code might as well have never
> been written.
Yeah, I've had to resort to skimming on occasion, but that was when I was
looking for something a bit vaguer than a Search command could detect. But
in that case, I don't think I'd describe "fairly quickly" as the amount of
time it took to find something in a 400K source file! :-)
> And you can forget skimming through other people's code to
> get a "feel for it", or to try to glean helpful code tidbits from it.
Agreed. Sort of. As I've said in another post in this thread, there's
nothing (in principle) that stops us from using multiple editors when one of
them stops being the right tool for the job. But an editor that, say, lets
me see the class structure of a program, perhaps graphically, and then lets
me browse the classes one or two at a time, can be a *very* time-effective
way of getting a handle on somebody else's code.
okbl...@my-deja.com
Kathleen M. Fischer <green_g...@my-deja.com> wrote:
>
> Ugh... I worked in environments that sound similiar to that many years
> back (Motif WYSIWYG GUI builders) and I hated them.
Yeah, I think that's a similar vein. But then, didn't/doesn't VB also
use the same approach?
> Heaven forbid you
> decide to rename a global variable, you could be clicking through
> windows for hours trying to find all the places you used it.
That's your punishment for using global variables. :-) And, no, it
doesn't matter that the project absolutely *required* their use.
> And what if
> you remember that you "did something like that" in some object but you
> don't recall which one? At least with 400K of text you can scroll
> through it from top to bottom fairly quickly. But to click open all
> those objects to find the snippet? The code might as well have never
> been written. And you can forget skimming through other people's code
to
> get a "feel for it", or to try to glean helpful code tidbits from it.
I should perhaps point out to both you and Doe that while I believe it
*could* be done well, I've never *experienced* it done well. A FOM is a
software reviewer and he let me experiment with all the Smalltalk tools
he was reviewing. I loved the language, hated the environments. He could
tear code out pretty fast though on 'em, though.
I think it could be done well, possibly, if instead of opening new
windows, there was a single editor with multiple logical panes that you
could pull up entire classes (or more than one class) within. Some of
the other problems you mention could be resolved simply with better
global search & replace code. But, again, I've yet to see such a thing.
--
[ok]
Larry Smith
> Larry Smith <lrsFive(repl_Five_by_5)@mindspring.com> wrote:
> I could go through your post and pick out all the examples of the
> differences between the way you work and the way I work. But it boils down
> to, you want a tool that works the way you work. Guess what I want?
I absolutely don't want to get into a shouting match here.
But it's not true that I want a tool that works the way I work. I want a
tool that makes me more productive. And over the years I've adapted my
approach on many occasions as better tools (not just editors) came out.
J Walrus
> decide to rename a global variable, you could be clicking through
if
> you remember that you "did something like that" in some object but you
> don't recall which one? At least with 400K of text you can scroll
> through it from top to bottom fairly quickly. But to click open all
> those objects to find the snippet? The code might as well have never
> been written. And you can forget skimming through other people's code
to
> get a "feel for it", or to try to glean helpful code tidbits from it.
Yeah. The first time I downloaded the source to any big program, I just
thought, what? Where the hell do I start looking if I want to just find
out how this thing works? And when all your code is in one place, you're
constantly reminded of its presence, you see it all the time while
scrolling up and down between other stuff, whereas if you put it in
another file, you go back to it and it's like reading stuff you wrote
three years ago that's been gathering dust in a drawer. It's easier to
keep your bearings when it's all in one place as well, you don't get the
feeling that there's just all this code spreading all over the place,
because you can see how much there is.
Jw
still using EDIT.COM, and why shouldn't I be?
Kathleen M. Fischer
"Larry Smith" <lrsFive(repl_Five_by_5)@mindspring.com> wrote:
>
> Kathleen M. Fischer <green_g...@my-deja.com> wrote in message
> news:891jc6$er9$1...@nnrp1.deja.com...
years
> > back (Motif WYSIWYG GUI builders) and I hated them. Heaven forbid
you
> > decide to rename a global variable, you could be clicking through
> > windows for hours trying to find all the places you used it. And
what if
> > you remember that you "did something like that" in some object but
you
> > don't recall which one?
>
your
> "editor" (or, as you more properly term it, "environment") lacked an
> adequate "search" command, one that spanned multiple modules / classes
/
> whatever. And your editor/compiler didn't have a cross-reference
feature to
> let you find those globals. Or perhaps a multi-module "replace"
command,
> that was syntax-aware enough to not replace "food=1" with "good=1"
when you
> were trying to rename global "foo" to "goo".
>
> It seems to me like you're condemning the whole thing because you were
> missing a few crucial tools.
Not at all, I'm always open to try new things, I was merely pointing out
things about similiar environments that I didn't like.
> Let me ask you this. If we can put aside the (valid) complaints above,
how
> was it otherwise? When you weren't trying to rename a global, etc, did
this
> type of editor make your programming life easier? If so, why? If not,
why
> not? Or were you just so frustrated with the above shortcomings (and
> possibly others) that the whole thing just left a bad taste in your
mouth?
They didn't make my life easier because their basic premise (and I've
played around with quite a few over the past 10 years) was at odds with
the way I liked to work. They were trying to be helpful by showing me
only the parts I wanted to see. I wanted to see everything. They tried
to be helpful by reformatted everything into a consistant style. I
wanted it to be my style. (No, my style wasn't any better, it was just
mine, and it matched up with all the billions of other lines of code I
was writting outside the tool.) They wanted to be helpful by having me
select valid values in a handy option menu. I knew the values by heart
and its much faster to just type the things in. Click on this spot to
edit this part, click on that spot to edit another. Windows coming and
going. All this is much more laborious and time consuming than just
editing it in the file. And before you decide I'm living in the dark
ages :) or have something against GUI's, I should probably add that I
make my living making GUI's (java ones these days). But at the same time
I've seen from experience (my own and others) that an experienced user
with an editor is often much faster at accomplishing something than an
equally experienced user in a GUI. Many times the difference in speed is
simply the length of time it takes for the windows in a GUI to come and
go. GUI's do have their strengths - validation is one of them...
protecting the user from themselves. But that usually comes at a cost of
speed or flexibility. (sorry, I rambled on longer than I planned on
rambling here)
> Yeah, I've had to resort to skimming on occasion, but that was when I
was
> looking for something a bit vaguer than a Search command could detect.
But
> in that case, I don't think I'd describe "fairly quickly" as the
amount of
> time it took to find something in a 400K source file! :-)
It still faster than clicking open a thousand objects! (Even in my WIP
that has ~120 files <blush>)
> Agreed. Sort of. As I've said in another post in this thread, there's
> nothing (in principle) that stops us from using multiple editors when
one of
> them stops being the right tool for the job. But an editor that, say,
lets
> me see the class structure of a program, perhaps graphically, and then
lets
> me browse the classes one or two at a time, can be a *very*
time-effective
> way of getting a handle on somebody else's code.
For you :) Code is, to me, more than just disjointed parts. Seeing
like parts bundled together into a single file gives me the warm
fuzzies, and I like being able to swallow them all in one glance. Seeing
small parts is fine if I know I want to change the color of the door
from blue to green, but not if I want to know how often I use
objectloop, or the relationship between ten items in a room. Different
strokes, ya know. :)
Kathleen
--
-- Excuse me while I dance a little jig of despair.
MFischer5
>> decide to rename a global variable, you could be clicking through
>> windows for hours trying to find all the places you used it.
>
>doesn't matter that the project absolutely *required* their use.
Actually, IIRC (and it's been quite a while), the *language* required their
use. :)
>I should perhaps point out to both you and Doe that while I believe it
>*could* be done well, I've never *experienced* it done well.
I've seen it well done well once, but the language that it was creating (Motif
UIL) was a significant reason why it worked. It's just long lists of objects
and their descriptions (no "code"), though two other GUI builders I tried even
managed to screw something that simple up.
Kathleen
tufty...@my-deja.com
$f5h$1...@nntp8.atl.mindspring.net>,
"Larry Smith" <lrsFive(repl_Five_by_5)
@mindspring.com> wrote:
> Agreed. Sort of. As I've said in another post
in this thread, there's
> nothing (in principle) that stops us from using
multiple editors when one of
> them stops being the right tool for the job.
But an editor that, say, lets
> me see the class structure of a program,
perhaps graphically, and then lets
> me browse the classes one or two at a time, can
be a *very* time-effective
> way of getting a handle on somebody else's code.
Erm - emacs.
Simon "Duck & cover, here come the
flamethrowers!" Stapleton
Adam J. Thornton
Larry Smith <lrsFive(repl_Five_by_5)@mindspring.com> wrote:
[a whole bunch of stuff that his editor can do]
Uh, Emacs can do that for me. When I want it to.
Adam
--
ad...@princeton.edu
"My eyes say their prayers to her / Sailors ring her bell / Like a moth
mistakes a light bulb / For the moon and goes to hell." -- Tom Waits
Ben Allen
>still using EDIT.COM, and why shouldn't I be?
Used to think the same myself, before I tripped across vim. It's got all the
flavo and at least twice the phat, once you pay the price of admission (in
this case, the effort required to learn vim's almost deliberately arcane key
sequences). Of course, once you past the learning curve there is absolutely no
way you can go back to using lesser editors.
--
Ben Allen, hi...@uswest.ReMoVe.ThIs.BiT.net
"Rainy days make you feel gloomy
And sunny days make you feel happy
But you can still have fun on a rainy day!"
HOORAY!!!!!!
GUN!