[osflash] [OT] one editor for everything (emacs)
hank777 at gmail.com
Sat Dec 30 15:00:56 EST 2006
Nah, I use both, but how bout coke vs pepsi!
On 12/30/06, Keith Peters <kp at bit-101.com> wrote:
> Woohoo! Nothing like a good editor war to end off the year!
> Mac vs. PC anyone?
> -----Original Message-----
> From: osflash-bounces at osflash.org [mailto:osflash-bounces at osflash.org] 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?
> On Sat Dec 30 12:15 , hank williams wrote:
> > On 12/30/06, Austin Haas <austin at pettomato.com> 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
> > 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
> 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
> > 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
> > 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
> > 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
> 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
> > osflash at osflash.org
> > http://osflash.org/mailman/listinfo/osflash_osflash.org
> Austin Haas
> Pet Tomato, Inc.
> osflash mailing list
> osflash at osflash.org
> osflash mailing list
> osflash at osflash.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the osflash