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
