ZX81 :)
Keith Peters wrote:
Woohoo! Nothing like a good editor war to end off the year!
Mac vs. PC anyone?
;)
-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
Behalf Of Austin Haas
Sent: Saturday, December 30, 2006 2:01 PM
To: Open Source Flash Mailing List
Subject: Re: [osflash] [OT] one editor for everything (emacs)
Do you have any data on the installed user base of Emacs, Eclipse, and
Visual Studio?
-austin
On Sat Dec 30 12:15 , hank williams wrote:
On 12/30/06, Austin Haas <[EMAIL PROTECTED]> wrote:
Hank, no offense, but you obviously aren't familiar with Emacs, so I
don't think you should be telling people about how it works. You are
completely wrong on almost every point.
As far as I can tell, based on your own comments, the only thing I am
wrong about is syntax highlighting. My bad. But that notwithstanding,
one thing that comes with being somewhat experienced is being able to
understand the features and comparative benefits of tools without
needing to be an expert in them. Emacs has been around long enough
(certainly the early 80's when I was in school) for those features and
benefits and disadvantages to be clear to anyone who has been in the
field.
And though you may not like my opinions, I think they are very much in
the mainstream based on the installed base of Emacs users vs Eclipse
and Visual Studio and all the other tools that do not derive anything
from Emacs. You might do better explaining why, despite the incredibly
small user base (relative to other tools) that there are circumstances
where Emacs rocks.
I totally agree with the Pragmatic Programmers. Emacs rules and it is
great
for any type of editing. Emacs has what are called "Major Modes"
which are specific to whatever type of file you are editing. These
modes customize every aspect of the editor to suit the language. I
can edit html, css, xml, ActionScript, Python, and Lisp all in the
same editor at the same time and have each buffer specific to the
language, but at the same time many familiar keybindings will work across
any language.
One of the reasons that Emacs is so great and powerful is that it has
been
in widespread use for over 30 years and contains it's own internal
scripting language for customization. The result is that thousands
and thousands of programmers have been refining and perfecting Emacs
over that time.
It is true that Emacs has been around long before graphical editors
and it does not contain a lot of the graphical features that you
might expect from IDE's such as Visual Studio, but most Emacs users
consider that a good thing. If you can learn to stop using the mouse,
you will find that you can navigate through your code and make edits
much faster. Emacs has ways of jumping all over your code with just a
few keystrokes that are hard to imagine if you've only been using the
arrow keys.
I thoroughly caveatted my comments with not being an Emacs user. But I
understand the "ethos" of Emacs as this has been an argument since the
early 80's when command lines gave way to graphical interfaces. The
argument will probably continue well after I am dead. There is a
(thankfully) small group of people that want the most geeky,
non-graphical, complicated, command line driven tools based on the
argument that they are "more powerful". That's all this is. For this
small minority, GUI's are bad. We really needn't argue beyond this point.
Specifically, I want to address Hank's claims:
1. Emacs is not clunky in the least. It's more like a surgical tool
for programming.
Based on everything you described, it sounds horribly clunky to me.
But this gets back to the GUI/non-GUI argument. Emacs people believe
the GUI is clunky and commands are smooth. I (and most others) believe
the GUI is smooth and command only systems are clunky. The Emacs view
is not mainstream, though I would thoroughly agree that there is a
small minority of people for which it is the most comfortable way to work.
2. Emacs is not a programming language, but it does utilize a dialect
of
Lisp as it's scripting language.
I know I studied computer science a long time ago, but way back in the
'84 when I took my first LISP class, it was indeed considered a
programming language. As I understand it, the core of Emacs is LISP
and most of the features of Emacs are built in lisp. These features
are modifiable by the users. I am not sure what you are disagreeing with
here.
3. Emacs has incredible syntax highlighting support.
point taken.
4. Emacs can do code completion, but I don't think that it works in
the same
way as some other editors. This is something that I wish it could do
better.
I am sure Emacs could fry an egg too, but you basically admit whatever
it does in this regard is not up to snuff. And I seriously doubt it
compares in any way to something like java in eclipse. One of the
things that people tend to do in these arguments is make some argument
that if you stand on your head with one hand in your pocket and one
arm extended at exactly a 45 degree angle, you can achieve the desired
result. This relates to point 1.
which is that to achieve the desired result in Emacs would be
*clunky*. This is why *no one* (well very few people) code java in Emacs
for example.
Some other benefits of Emacs:
1. I can edit files remotely via ssh, side by side with my local files.
2. I can easily add new editing functions, such as inserting a trace
method for the current function signature.
3. I can collapse functions to just their signatures.
4. Very powerful regular expression searching and replacing.
5. I can collect the trace output from my swfs directly into an emacs
buffer, and use all of the power of the editor there. For example, in
multiplayer games, I can capture the output from two players into the
same buffer and use emacs regexp-highlighting functions to highlight
all messages from one player as blue and the other as red.
6. I've also built a runtime swf profiler into Emacs.
7. Every aspect of Emacs can be customized. If there is anything that
you
wish could be different, you can change it. I think this is why the
Pragmatic Programmers recommend it.
I don't want to design an editor. There is nothing that I could do as
well in my spare time that could not be done far better by a dedicated
team totally focused on the given task. I want an editor that is
designed for what I am doing so I don't have to customize anything.
Honestly I don't think I am doing anything much differently than
anyone else so I shouldn't need much customization. This is borne out
by the fact that the Eclipse Java editor fit me like a glove right out of
the box. No customization needed.
8. Whenever Emacs opens a brand new file that ends in .as, I have set
it up
to automatically insert a bunch of boilerplate code, such as the
package line, class line, constructor skeleton, and a toString method.
9. I can compile my actionscript from Emacs, using either mtasc or
mxmlc,
with one button. If there are any errors, Emacs will find the error
in the correct file, highlight it in red, and put my cursor on it.
...but, Emacs has literally millions of features and add-on packages
that I'm still discovering every day.
Millions of features is *not* a benefit in most products. I think that
includes editors. As I said in my initial post, the fact that Emacs
is/contains a programming language means that it can definitely do
things that eclipse editors can't do. This is always what badly
designed tools fall back on. Emacs is an accretion of features, not a
designed product.
Thousands of people adding pieces a bit at a time just *can't* yield a
seamless productivity tool for all but the most dedicated.
I want something that works really well, not something where I have to
spend a year learning a language and customizing to work well. And of
course as you admitted it doesn't do code completion very well. And,
based on your description, it doesn't do error detection as well as
the Eclipse Java editpr either, which detects errors *as I type* and
shows them to me with markers on the side or the window without even
compiling. When I move my cursor over the error marker it suggests the
fix for the problem. This may not be important to you, but for me (and
I think most) seamless error detection, once you have experienced it,
is something you will never give up,
But the bottom line may just be this: Emacs may just be for the smart
people, and I alluded to this in my earlier email. I may not be smart
enough to use it effectively. I'll cop to that.
But coming back to the initial question, this argument is not about
which editor is "better", but about which one is better for a given
task, and whether it is best for the average programmer to only use
one editor, which would therefore mean not accessing what I consider
to be far more advanced language specific features like in eclipse or
even visual studio. I would definitely argue that a text based editor
such as Emacs or vi is definitely something that should be in your
arsenal. As you correctly indicate, there are things text based
editors can do - like work in a terminal window etc, that GUI's cant.
And if you need to write code (in LISP) to do custom things, then you
should definitely consider it for certain tasks. But give up the GUI
for the command line for my primary editing? Nah. I don't code much in
assembler these days either. The stone age just wasn't that much fun.
Regards
Hank
_______________________________________________
osflash mailing list
[email protected]
http://osflash.org/mailman/listinfo/osflash_osflash.org
--
Austin Haas
Pet Tomato, Inc.
http://pettomato.com
_______________________________________________
osflash mailing list
[email protected]
http://osflash.org/mailman/listinfo/osflash_osflash.org
_______________________________________________
osflash mailing list
[email protected]
http://osflash.org/mailman/listinfo/osflash_osflash.org
_______________________________________________
osflash mailing list
[email protected]
http://osflash.org/mailman/listinfo/osflash_osflash.org
