Jacob Meuser <[EMAIL PROTECTED]> writes:
% On Sun, Jan 23, 2005 at 03:41:41PM -0800, Allen Brown wrote:
% > > I don't like emacs because it tries to format my code for me. I
% > > condsider that unsupportive, and actually kinda rude.
% > Like all things, it is configurable. You can either set the
% > configuration so that it formats to your style, or you can
% > turn off formatting.
% or I can not use programs that I dislike ...
% seriously, with the wide choice of editors out there, why would I
% spend time trying to figure out how to do that?
Editors are tools. You can use the simple easy tools. Or you
can use the tools that your father used. Or you can use the one that you
first learned.....
or you can learn the tool that lets you get the job done best
in the long term.
I have often watched people hold fast to a tool because they like
it, and yet not spend the time to learn another tool that would
give them advantage in the long run.
The reason you would choose to learn emacs is that
if it fits how you approach problems, then you can
make an environment that makes you more effective.
A macro here, a mode there and pretty soon you can do things
in half the time, or a tenth of the time that others
do the same thing.
Where you are doing similar things over and over, having a
way to automate it is important for the long run:
System Admin rule:
Do it once to learn it.
Do it the second time to document it.
Do it the third time to automate it.
And then stop doing it....
---
So.. you would choose to learn an editor that was complex because
it had the ability to give you leverage. Both VI and Emacs
support automation at one level or another.
Nano/pico/whatever don't.
% > > UNIX _is_ a programming environment, made up of many simple tools,
% > > doing one thing and doing it well. that's why there is indent,
% > > ctags, lint, sed, etc, etc. knowing how to use those tools
% > > individually is far more useful than knowing how a particular
% > > program reimplements them.
% > I agree. But one of the things emacs can do is to run make
% > and parse the editor error messages, putting me onto the
% > correct line number in the appropriate file to fix each bug.
% > None of the tools you mention do this.
This is an example of the automation that I was talking about.
% true, but I don't find it troublesome to read the make output and go
% to the line in the file.
Then fine. Don't use the tool that gets you leverage.
When professional programmers are evaluated for productivity,
there is a range of productivity of 50:1. IE, the top programmers
are 50 times more productive that the worst professional
programmers. I know of no other profession that has this kind
of range.
Much of that range is a function of tools and attitudes. If
you want to manage your productivity, then you learn to
adapt your tools to be more effective.
I have watched people type in and edit lists of names over
again to make them in the right formate, when if they had
used emacs/vi and regular expressions, they would have
been done in 5 minutes.
So the reason that you look at tools outside of your current
tool is to find the places that people are effective and
to gain some of that efficiency for yourself.
If you can't want to gain it, fine... But don't be upset when
others start being more effective...
-----
John Sechrest . Helping people use
. computers and the Internet
. more effectively
.
. Internet: [EMAIL PROTECTED]
.
. http://www.peak.org/~sechrest
_______________________________________________
EUGLUG mailing list
euglug@euglug.org
http://www.euglug.org/mailman/listinfo/euglug
