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
