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
