I am relatively new in a software development. I have noticed that in some cases a text editor with extended text processing capabilities (I use Notepad++) gives me a better productivity than an IDE (I use the Eclipse and the Netbeans). In the era of IDEs, does it makes sense to learn emacs (or some other tool that you suggest?)
Yes, and no.
Yes for the exact same reason why a doctor should be able to get an approximate diagnose from your symptoms by using his experience, and not putting the list of symptoms in a google query and find the answer.
Yes for the exact same reason why airliner pilots are taught to fly without fly-by-wire even if all airplanes are today fly-by-wire, so almost everybody is able to keep them flying.
No, because if you need specific tools to make your life easier, such as GUI designers, Intellisense, access to documentation, then clearly Emacs is not enough.
Still, I remember that many developers at Microsoft organized a fund raising for uganda vim children.
Summing up, you need to use what makes you more productive. In many cases, emacs (or vim) is more productive than a huge IDE that makes coffee.
Even if you were using an IDE, it's still useful to know Emacs/VIM. You don't have your IDE around all the time, and while doing something via SSH, you don't really have any other option (yeah you can use nano, but thats not very effective).
When you do software development, you often deal with a lot of text besides code. I may use an IDE for most of my coding, but often I'll use Vim for plain ol' text viewing and manipulation.
Sometimes I need to view code, SQL scripts, XML, CSV, or TXT files. Other times I may want to perform bulk replacements on those files, or extract out certain chunks of text from it.
IDEs are good for writing and refactoring code, but aren't meant to be used for generic text viewing and manipulation. For that, I'd recommend having the full power of something like Emacs or Vim. Notepad++ can be good too.
In short, use the right tool for the job.
Everyone here seems to think that Emacs/Vim are light-weight compared to IDE's. This couldn't be further from the truth. Even the best IDE's do not have the features that Emacs does. In what IDE's can you program completely without moving your hands from the keyboard, read your email, chat with Jabber, run an integrated debugger, view your calendar, program your own functions, and send dbus commands? That's only the surface of what Emacs allows; I'm sure Vim has similar capabilities.
Ignoring productivity completely; remember why you started programming in the first place. You like to create stuff, you like to know how stuff works, you like creating clever solutions to obscure problems, you like tinkering, you like learning new things, you like creating tools that help you do things.
With this in mind the answer is yes, learn it if you think it will add to the delight to your days. Maybe you will also get some work done along the way. Fiddling with eamcs will not make you melt. You might even make a life-long friend of it. Happy Hacking.
Emacs is an IDE. In fact, you could argue it's a whole operating system.
vi, on the other hand, is an editor.
Yes, it makes sense to learn vi, since it's about the only editor you can use on anything vaguely posix, even if the GUI isn't running or the network is incredibly slow (vi is usable at 300 baud). Basically, it's the unix administrator's safety net of an editor. I've used it to rescue myself from broken device drivers on an OS X server that would only come up so far as single user, so even the must GUIfied Unix out there can still be saved by humble vi.
It makes some sense to learn emacs too, but perhaps not quite so much these days.
I would say it helps to learn emacs (or say vim).
Personally I'm comfortable using IDE (eclipse) for Java developement, when I code in perl or python I prefer to use emacs. Also if you are in a resource constriant environment (say) starting an IDE like Eclipse (which would crawl if there is anything less than 1GB RAM) to write a perl script might not be feasible. In such cases a vim would be neat tool of choice.
Related
I have come accross vi-style keybindings for Emacs, but my past experience in mixing Lisp based config in .emacs file for enabling various modes etc., hasn't been very pleasant so far.
Read several articles on Emacs + Erlang, but is there something that might be slightly easier for folks familiar mostly with vi (and who are unfamiliar with Lisp)?
The entire set of possibilities (keybindings) is quite overwhelming. Is there a condensed key-map/shortcuts reference specially relevant for Erlang development?
Just use vi and a command line. There are numerous people doing that and it seems to work just fine for them. Even though I use Emacs, it is not the Emacs-erlang interaction I use. Rather I usually just have a separate Erlang shell and then I load modules in that shell with the l() command for interaction.
Answering your questions one by one:
Debugging in Erlang is funny. Firstly, if your program is kept functional you will find that you need much less debugging to figure out what the program does incorrectly because you can simply write small tests for each of the numerous functions to test its correctness. And you can add those into unit-test frameworks.
As soon as you add multiple processes to the mix you will find that traditional debugging doesn't work anymore anyway. The trick is then to trace and assert, and you will need to learn a way to read programs without running them and see where they go with a debugger.
That said, try to execute debugger:start() in an Erlang shell :) There are also the tracing systems and redbug, a 3rd party tool built on top of them (part of the eper suite).
Profiling can be done with one of the 3-4 profilers: cprof, eprof and fprof are all slightly different in scope and in how much impact they have on your program and if they can be run on a production system or not. I tend to use eprof and I have a knob in my program which will spawn an eprof and then attach it at program start.
Try appmon:start() in a shell.
The standard vi-way of browsing large code bases is to create tags-files so you can jump to the definition point of the thing-under-the-cursor. Emacs can do the same. I have a make tags target to create these files so I can easily make jumps around in the source code. When jumping you have a stack of the former jumps so you can return to the point you jumped from later on.
Finally there are tools like xref which can be worked to create call graphs and find odd things in the code. It will require some coding on your part, but it does provide you with the necessary tooling.
Viper mode provides Vi-style keybindings. That's probably the easiest way to start. Enabling a new mode in your .emacs is a pretty fundamental part of using Emacs, so it's a learning hurdle best cleared early!
The Emacs manual contains more detailed information about making individual changes to your keybindings.
You may find Xah's keybinding tutorial helpful, as it provides many examples.
I have never used Emacs before and the first time I tried it I was so repulsed by its interface which seemed not very user friendly . But since then I have heard a lot about it improving productivity and this has rekindled my interest . But is it true for the case of web development as well? for the likes of php,python,javascript/jquery etc . How good are the code completion features?
Please suggest some resources to get me started in the right direction.
I'm a bit of a religious user when it comes to Emacs so please take this with a few bags of salt. I'll try to state my reasons for using Emacs (including for web development).
Emacs' primary strength is it's extensibility and the fact that at it's core, it's a lisp interpreter with a bunch of primitive functions useful for text editing and display. This makes it "programmable". You can customise it almost endlessly.
This has spurred a number of libraries which do (common) things like code completion, source code browsing, test harness integration, refactoring tool integration, version control integration etc. If a developer working on a project is an Emacs user, it's not uncommon to see her adding something to her project just to get it to work well with Emacs. The extensibility has also spurred a number of less that conventional libraries like mail clients, web browsers, IRC clients, music players etc.
Many Emacs users keep most of their work (except for maybe their browsers) inside Emacs. This allows them to use the same keystrokes and high level techniques for everything that they use. I myself use it for my daily coding, for my email, as my PIM and a bunch of other things. I can for example, while working on my code, just write something like "TBD" as a comment somewhere and let the PIM part remember this as a TODO item next time I open the editor. I can also for example while coding simply switch to another "buffer" (the emacs term for windows) with an IRC client and ask questions I might have to other people who are online. This makes me quite productive and quick. Also, the keystrokes are almost the same on a large number of command line UNIX programs (like my shell etc.) which helps me do my work faster.
Another advantage is that Emacs is old. People have tweaked and polished it endlessly and still do. The result is a set of commands for editing that I didn't even know that I needed. Things like "capitalise word" to make the first letter of the word my cursor is on upper case sounds trivial but while you're editing, it's quite useful.
Being extensible, Emacs has "modes". These are environments for specific programming languages. Indentation rules, syntaxes, completion etc. will change depending on the mode you're in. There are modes for almost all modern languages and they provide substantial help while editing. You have things for javascript, php etc. which help you while coding in those languages. There are also web specific tools (e.g. Emacs can talk to MozRepl so that you can refresh you browser and things while editing). People write modes all the time for what they want and it's not too hard. I recently started using jekyll to maintain my blog and wrote a mode to make my life easier). The modes add functionality but at a base level are the same (e.g. same keys to delete a character, move forward by a sentence etc.). I like this because I don't have to learn a whole new set of keys and get used to them just to code in another language.
That being said, Emacs is a tool for a different kind of developer. Most hardcore Emacs users (and there are quite a few famous ones out there) don't use many IDE type features. They usually like just a window (Without toolbars, menu bars and all that) so that the real estate for code is maximum. If you're used to leaning on a feature heavy IDE to do your work, Emacs might not be the right tool for you (I think this is what Trey meant in his comment). If however, you want a programmers editor that stays out of the way and let's you get your job done with minimum hassle, it's something you should definitely try out.
Okay, resources. The first thing to do is to start up Emacs and type Ctrl-h t. This gives you a "hands on" tutorial you can use to learn the editor basics. Once you're done with that, you can read the fine manual at http://www.gnu.org/software/emacs/manual/html_node/emacs/index.html. Once you're happy with that, you can read the Emacs lisp tutorial and start extending and customising Emacs as per your wishes. The EmacsWiki is a great place for tips, tricks and docs as is the Emacs IRC channel.
All the best!
If you don't like the interface, it's not worth it.
The question isn't is it worth learning Emacs, it is do you want to learn the interface?
If you do, then it's worth it. If you don't, then it's not.
More concretely, I'll answer your broad question with a series of links you could have gotten from the Emacs wiki:
http://www.emacswiki.org/emacs/JavaDevelopmentEnvironment
http://www.emacswiki.org/emacs/NxhtmlMode
http://www.emacswiki.org/emacs/HtmlMode
http://www.emacswiki.org/emacs/MuMaMo
http://www.emacswiki.org/emacs/PhpMode
http://www.emacswiki.org/emacs/php-completion.el
http://www.emacswiki.org/emacs/php-mode-improved.el
http://www.emacswiki.org/emacs/JavaScriptMode
http://www.emacswiki.org/emacs/FlymakeJavaScript
http://www.emacswiki.org/emacs/PythonMode
http://www.emacswiki.org/emacs/PythonProgrammingInEmacs
http://www.emacswiki.org/emacs/CategoryProgrammerUtils
Yes, people like using Emacs for web development. The above is just a sampling of modes people have written and use on a daily basis.
Is it for you? I don't know.
Is it better than editor X? or IDE Y? Yes for some things, no for others.
The code completion features are great! (unless they're not) It depends on what you want, what languages you're talking about, etc. etc. etc.
People use vi, people use Emacs, people use Notepad, people use all sorts of text editors.
Note: asking vague questions leads to vague answers.
The ultimate web programming mode is arguably nxhtml mode. You might start by taking a look at it. You might also want to check out some rich preexisting Emacs configurations like the Emacs Starter Kit or the Emacs Dev Kit.
The PHP & Python modes in Emacs are not particularly great, but are fairly decent. The JavaScript mode is certainly great. Packages such as autocomplete mode provide good completion almost everywhere.
I'm certainly biased, but I think that if you do spend some time exploring Emacs you'll find out that it will boost your productivity.
As some other posters have eluded to, it all depends on what you want out of it. If you want to feel as good about the customizations you've been able to get working in emacs as you do about the actual code that you write, then sure.. Emacs is great ;)
(Before anyone jumps down my throat, emacs is by far my favorite editor for 'nix C/C++ editing, but that's not what the OP's looking for here ;))
In my crusade to find the most productive editor for PHP, Python, Javascript etc, my favorite thus far has been Komodo Edit. It features not only code completion, but jump-to-definition (as well as many other features that a full-featured IDE should have) and is really the closest thing to Visual Studio for OS scripting development that I've seen. Oh, and it's free.
Honestly, braces against the rotten fruit/vegetables that will surely be thrown my way I've recently become a fan of the NetBeans IDE for web development. Particularly when It comes to PHP.
But to answer you question: It's only worth it if it's worth it to you. Sorry, vague questions get vague answers. ;)
If you're using an existing IDE that can do web development, than use the IDE. If not Emacs is worthwhile to learn as the text editor to go to for text editing or for programming in language that do not have a good IDE.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
I started coding around 5 years ago. I was introduced through Java and Eclipse which both have substantial stigma attached in the programming community. A number of people at the company I currently intern at prefer emacs or vim. I can't see how a basic text editor is faster or easier than an IDE in general although I appreciate some things like building tend to be faster from the command line.
Is this a case of the 'old-boys' club or can it be more efficient to program a project in this way?
Can you provide some use cases to demonstrate? If I were advocating Eclipse I'd say refactoring and auto-completion were pretty handy tools.
Gav
Vim / Emacs
Very fast/efficient code writing
Low memory footprint
Quick access to command line
Infinite possibilities through scripting/plugins
Never have to leave the keyboard
Eclipse
Full-featured IDE for many languages
Great refactoring support
All of them
Cross-platform
Feature rich
Extensible through plugins
I typically find myself writing volumes of code through vim and performing debugging tasks through my IDE. Familiarity with the code base is certainly a factor, as an IDE is a great tool for jumping around and learning unfamiliar source code.
I got started in IDEs like Eclipse, but switched to Vim about 2 years ago.
Reasons you may want to use a text-mode editor:
It can be used as an IDE for just about any language (you learn it once and use it for everything)
It can do all those fancy things like auto-completion, refactoring and many more complex operations, which you can extend by adding macros or plug-ins
It works just about everywhere (and can be used through an SSH shell)
You don't need a GB of ram to run it
If you really persevere, you will find that working in an editor like this will eventually be faster, and in fact becomes ingrained as a sort of 'muscle memory'. This means you can code without slowing down to think about the process.
The argument "Eclipse for Java" is a different argument than "Eclipse for [something that isn't java]". Eclipse does rock for Java.
I mean, vi is like a screwdriver, or maybe a swiss army knife, and Eclipse is like a big CNC combo mill and asphalt spreader. You don't exactly compare them, you kind of just use both.
Also, are you working inside something giant, which you know little about, but which Eclipse understands? An example would be working on Eclipse itself. Here, Eclipse has perfect visibility, total language support, and you need the toast prompts and the documentation links.
But if you are typing in a 100-line Ruby program to convert an SQL database, Eclipse doesn't add much value, especially considering its baggage.
It's also critical to set up vi right, or you won't grok the appeal. Autoindent, showmatch, tab handling, and various other options should be set. You should have a easy way to generate a tags file. Google can find tag generators, or just write one from scratch, with a few lines of shellcode and sed(1).
I don't consider refactoring to be a criteria. That's not something you do once an hour or even once a day. Sure, fire up the big IDE when you need to refactor. Oh, and don't expect automated refactoring of anything except Java.
Finally, vi can actually do a lot of things that the IDE can't begin to do. The grouped regular expression global substitution is kind of a generalized refactor-anything engine. To appreciate the vi gestalt you need to learn the line (":") mode. Briefly, it's like having sed(1) inside your editor.
It all depends on what you want/expect and what your usage model is.
If you're looking for a Java IDE, Eclipse is difficult to beat. It's written in Java, for Java, by Java folks.
If you're looking for a tool to edit files from the command line quickly, Emacs or vi both fit the bill.
If you're looking for a tool from which you never have to leave because it can do anything you want (send/read mail, manage projects, todo lists, compile, debug, etc. etc. etc.), then Emacs is more "efficient".
If you're looking for reasons to switch editors, figure out what you want. If you want a better Eclipse, vi and Emacs won't give you that, stick to Eclipse.
If you're looking for a small, nimble editor, vi will fit the bill.
If you're looking for the ultimately extensible editor, Emacs is the way.
Whichever tool you decide to go with, immerse yourself. Learn all of the ins and outs, extend it to meet your needs. Use it to its limits and become efficient in its use.
Emacs can be a powerful IDE, but having gone from Emacs to Eclipse, I have to say I would never go back. Eclipse just offers so many features that you can't get within Emacs.
Mylyn and scoped views of the data and files I'm using, the debugging UI, CVS UI, are all built in and easy to get and use. I'll use the mouse a little to get'em.
First things first. VIM is more productive for programming than Eclipse. Your personal productity in VIM may be abysmal, but the potential cap of VIM is much higher. This is a fact.
VIM is a martial art. It feels unnatural when you first use it. And you can't even make it work. It takes years of practice to gradually become productive. You focus on mastering a little detail at first. Slowly all these bits you master add up until text is flowing effortlessly out of your finger tips onto the screen. Complicated edits that would make your co-worker sigh will jump from your hands before he can finish his exhale. There are few people who can use VIM. Fewer who can use it productivley. And you may never meet a master in your life time. But they are rumored to exist.
VIM is designed to keeep your hands on home-row. Moving your hand from the keyboard to the mouse is demoralizing. It's a gross motor movement. Moving your arm has a phsycological effect that hurts your motivation. Using VIM, someone could bolt your wrists onto the keyboard and you could still easily open up files, split windows, open tabs, build the project, search/replace, change fonts, change colors, etc. And all at lightning speed.
VIM is modal. That means you don't have to do complex key combinations where you hold down control+shift+Key. This hurts your hands in the long run. Instead you execute commands. There is no need for key combos to due to the modal nature.
We store data in our memory like computers do. Our memory can only hold a few values at a time. See how many distinct integers you can hold in your head before they start to slip away. We overcome this human limitation by writing stuff down. If data falls out of our memory we can easily look at what we wrote down to get it back. If your time is spent doing gross motor, physical things you are losing time that could have been spent on processing data in your brain. You want your mind to flow onto the screen without any effort at all. It may not sound like much but VIM's ability to effortlessly transfer what is in your mind to the screen is a BIG productivity boost. It's hard to put in words what I'm trying to say.
VIM supports code completion. Both textual and look-up based. It can pull text from mulitple files. Anything you desire can be had in VIM. Either make it yourself or use something someone else cooked up.
VIM supports goign to definitions with ctags. You can also find all references of an item. Again, anything you desire can be had in VIM.
The scripting of VIM is huge. You can download or create thousands of color schemes and change colors in an instant. Try to change fonts or colors in Microsoft Visual Studio and it will hang for 20 seconds while it loads data. It won't let you store color schemes and you must spend 30 minutes tweaking your colors and fonts every time you want a change of scenery. In VIM you can set line spacing to zero to fit more lines of code on the screen. I get over 80 lines. Visual studio uses 2 pixels of spacing for every line and you can't adjust it!!! Less lines = more scrolling = less productivity = forced to use small fonts for more lines = eye strain.
Split windows are opened in an instnat in VIM. It's usefull when you need to look at data in one section of the code that's far from the place you are typing (or in a different file). You don't have to spend time resizing windows, or worry about GUI windows overlapping each other and falling behind each other. Un-related code windows can be opened in tabs as to not take up screen space, but allow quick switching.
VIM as an IDE: http://www.youtube.com/watch?v=MQy2rVOf-z0&feature=fvwrel
VIM the revenge: http://www.youtube.com/watch?v=lQNFfhC4QI8
I've used vi for years to edit code in a variety of languages, and really love it. But I've found IDEs like Eclipse to be even nicer for Java development, and now I tend to work in Eclipse almost entirely. I drop out to use vi from time to time for a few specialized activities like bulk-inserting copyright notices, mainly those dealing with certain kinds of rote edits that aren't well automated in Eclipse. I also have my Windows .java file type mapped to vi for when I just want to look at a source file without waiting for Eclipse to open up.
Some of the attractive features in Eclipse are:
method name completion
error highlighting
pop-up javadoc comments
refactoring
I do find it a lot more efficient than vi in general, so you should try it out and see if it that holds true for you too.
I remember reading somewhere about a study which showed that people perceived keyboard shortcuts as more efficient than mousing, when in fact it wasn't always.
Another psychological effect is that we attach value to things which are expensive, i.e. since Emacs is harder to learn it must be better in some way.
I think those effects could explain a lot of the extreme affection some people have for Emacs/Vi.
However, in the case of Eclipse, I find it can be very slow and even crash occasionally, but that is not a case against IDEs in general.
I use both Eclipse, VS and Emacs regularly. I would use TextMate too, but I don't have a mac anymore. It depends on what I am doing, more specifically, what system best supports my language and tools.
I know people who spend considerably more time programming their editor, than they spend doing something useful. Some of them even admit themselves that they only do it for the challenge. Other people often claim that Emacs/Vi can do much more than IDEs, because they are scriptable. Well, most IDEs (including Eclipse) can also be scripted. In that sense almost all editors are equivalent (though, I admit, some editors are more easily scripted than others).
If you like IDEs, my advice is to keep using one. There is no One True Editor.
EDIT:
This seems to be the article Nick Bastin is referring to. I agree that it is far from a definitive source. However, I still think my point about perceived and real productivity not being the same thing still holds.
It depends on the languages.
For Java or .NET use an IDE (Eclipse,Netbeans,Visual Studio...).
For almost all the other languages(C,C++,ruby,python,haskell,lisp...) vi and emacs are better in my opinion.
The efficiency provided from vim/emacs is mostly afforded by their heavy keyboard use. In these programs you can do most anything directly from the keyboard, rather than having to stop and use the mouse.
I would anytime go for emacs rather than eclipse. I also have to say that bare bone emacs, is not that great, but after some tweaking, you will never want to let it go. In particular I will tell you how helpful emacs was while writing my Master's thesis, that should make clear why Eclipse is inferior, just because it is less versatile.
I my master thesis I wrote in the following programming languages: C++, Python and R. Complementary, I had to write the thesis, for which I used LaTeX. Moreover, I had to write a bunch of shell scripts and cmake scripts. Guess what? Emacs has great support for all of it. Specially, it was a pleasure to work with AuCTeX to produce LaTeX documents. Then, Emacs provides the great ESS mode for working with R. Likewise, it provides facilities for python. Once I had my cmake scripts for building the C++ code, I only had to call compile from withing emacs and I was done. Eclipse cannot do this things altogether, therefore you will need to learn to use many different programs. Note taking? There is org-mode for that, and it is great!
And then, my program needed of a very powerful computer (not like any laptop). So, I could just do everything remotely from within emacs!!!! Using tramp, I found myself doing remote interactive evaluation of R code, remote compiling, executing and debuging C++ code, and everything within the same good local emacs window I had been using. In contrast, my friends who used a separate tool for everything were much slower in developing software that was meant to run in another computer.
Like this I have some other stories, but I think, this will give you a good idea on the things you can do with Emacs. All in all , I think choosing to use emacs (despite the learning curve) has been the most productive decision I have ever made.
Hope it helps.
I'd say the actual vim/emacs editors are far superior to the Eclipse text editor in terms of the shortcuts they offer. However, I completely agree with you about refactoring.
Most people have to write scripts to do the sort of level of refactoring Eclipse is capable of. I think part of it is bragging rights or people just doing it the same way they always have.
We've had this argument at work recently. My take was that one single feature I couldn't do without is Emacs's autocomplete. Eclipse's autocomplete is based on syntactical analysis - the code gets parsed, and as you type code you're offered choice of completion. Emacs' autocomplete is base on simple textual analysis. That means it works in plain text, in comments, in documentation - everywhere. I keep saying the Emacs' autocomplete is what IntelliSense wants to be when it grows up.
Update:
Eclipse does offer Alt-/ which is supposed to be similar to Emacs. Not sure how well it works, though.
The only place I prefer an IDE is for debugging. I set up my vim environment for debugging but is was so painful to use, so clunky, that I now just switch to my IDE (Netbeans) when I need to debug. vim is great for text editing, the IDE is great for more complex stuff (like debugging, and some project management related tasks).
Like some of the posts above, I started out with an IDE (Eclipse). From there I moved to Emacs, and then I moved back to a rich text-editor (TextMate).
For me, the efficiency was the ability to have an editor at the interface level. Allowing me to integrate other service I've built up (or others) into my pseudo-IDE environment.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 1 year ago.
Improve this question
As some of you might know I am the lead developer of Padre, The Perl IDE. In the first year of its development, Padre became an acceptable text editor with some extra features for Perl development.
I'd like to ask the Stack Overflow community for some help in driving the project further to turn it into an exceptional IDE for Perl development. So I'd be glad to read what do you think are the most important features of an IDE that are still missing from Padre?.
Especially I'd be interested in people who currently use Eclipse+EPIC, Komodo, Visual Studio, or any of the text editors for programmers.
The most important feature of an IDE for Perl development (including Padre) is:
an interactive debugger that actually works. E.g. remembering breakpoints, ability to drill down into complicated data structures, and copy (to clipboard) should work on watched variables - including a menu command Copy Special that allows putting it in various formats; say CSV, XML or tab-separated.
The two most invaluable features I find:
line-by-line debugging, watchpoints, breakpoints, and so on, so I can properly debug my code.
code completion so I don't have to go looking up docs (even online).
OK, here's my third answer, although I hate to say it.
The competition is pretty easy to install. Padre isn't. I tried to update to the latest release today and, once again, got failing tests.
I am a heavy Perl EPIC user and my biggest gripe is not being able to jump to a function that is clearly defined in the current context (usually by pressing F3). It is pretty
much hit or miss at this point.
Stability. People turn away quickly if their editor crashes and they lose their work.
I work with Komodo. I also use other editors but I come back to Komodo most of the time. A good IDE shoud have:
A good Debugger. Breakpoints, watch lists, everything you need.
Remote debugging. Threads debugging capability.
Syntax highlighting including weighted fonts as well ( I was pretty disappointed by Oxygen, for example, an XSLT IDE, where I can not use bold fonts to emphasize reserved terms)
Syntax completion.
Project management tools, preferable extendable by plugins.
Good VCS integration. This is something that I absolutely love in Eclipse: You instantly see what files have local changes and which aren't added to the repository yet. And you get to browse the different versions and have a nice diff view just one mouse click away.
A project manager. It's essential for me to be able to define the set of files and folders that comprise a particular codebase. Sessions are useful but not a replacement.
Testing integration.
Perl has great unit testing tools. When I run my test suite and get a failure, I want to see the code for the test that failed.
Having a good way to jump through test results and see the code for the failed test along with the expected and actual results would be a great boon.
The first thing I look for is some kind of overview of the currently active file. I'd like to see methods/functions and, if possible, the used modules and especially any use base statements.
You solved that pretty well in Padre.
Visual-Studio style refactoring for variables and function names and extraction of functions.
Visual studio searches your whole module for all references and allows you to see all changed lines in case you do not want to change one instance (for whatever reason)...
The question seems more debatable than answerable.
Risking myself of being accused copyright abuser, I will post contents that I remember from the book "Interactive programming environments" by David R. Barstow, Howard E. Shrobe, Erik Sandewall.
It will not be exactly the same, as I have read the book many years ago and I've jotted down it in another language.
PRINCIPLES OF A GOOD INTERACTIVE PROGRAMMING ENVIRONMENT
1: Know the user
+ Know the previous knowledge and practice of the user
2: Minimize the memorization
+ Selection and not characters entering
+ Names and not numbers
+ Predictable behavior: the user should have a previous impression of what the system will do
+ Possible access and changing of the parameters of the system
3: Optimization of operations
+ Fast execution of common operations
+ Inertia of visualization: the screen should change the less possible
+ Memorization of system operation in user's memory
+ The meaning of specific operations should have a simple relationship with the state of the system
+ The system must be prepared to accept more than 10 followed commands per second, so that it can operate on the user's muscular memory
+ The system should be prepared to organize the parameters of a command
4: Engineer for the errors
+ Provide good error messages.
+ Engineer it to remove away the common errors.
+ The system should provide reversible actions.
+ Redundancy: the operations should have more than one way of being done.
+ Integrity of data structures.
The ability to configure and run external (command-line) tools. Plug-ins are great but end-users won't necessarily want to author one just to integrate with an external tool. Allowing users to configure their own tools provides a great deal of extensibility with minimal barriers to entry.
My editor of choice is UltraEdit. It's not an IDE, but through its support for user tools, I've been able to integrate IDE features such as lint, version control, debugging, and more.
This can be possibly achieved via use strict; but could be as well a valuable feature even if not use'd explicitly, namely:
the other day we spent about 10-20 minutes debugging the following behavior:
my %hash;
$hash->{'key1'} = value1;
# on reading in a different module
print $hash{'key1'}; # is, of course, empty, but was so easy to overlook in the code above
resume:
proper Perl type safety brought in by the IDE.
It might be already implemented in Padre, though, as it turned out not in Eclipse+EPIC
I use emacs. I would like a system that helps me refactor code, especially when I'm working on ugly 1999 code that uses the begin-at-the-beginning-go-to-the-end philosophy combined with duplicate-and-modify.
I looked at Eclipse, but I can't work with a system that requires me to create a project before I can make a one-character correction to a file.
I looked at Padre, but it's slow and crashes.
I looked at Kod which claims to be configured by CSS, but I can't find a man page that will tell me where to put the CSS.
Integration of a read-eval-print loop. As a heavy Emacs user, I very much appreciate Sepia. Very useful for trying things out before I commit them to code.
Ability to create and debug XS code.
The ability to use my own choice of editor (which it may have, as far as I know). That has a chance of winning over the vim/emacs people.
I don't know if Padre can do this, but the ability to split the screen is very important to me. As a VIM user, I constantly split my screen to look at another file while coding.
Line ending policies for files, by directory, and project-wide.
So, for a given project or directory, I'd like to make all line endings be LF only. While in another directory I may wish to have a mix of CRLF and LF files.
I work a lot on stuff that goes back and forth between Unix and Win32 environments.
The typical solution of automatically converting all files back and forth as one moves from platform to platform hasn't worked well for me.
When a file gets created in the wrong format by accident, it can be a real pain.
Having programmed through emacs and vi for years and years at this point, I have heard that using an IDE is a very good way of becoming more efficient.
To that end, I have decided to try using Eclipse for a lot of coding and seeing how I get on.
Are there any suggestions for easing the transition over to an IDE. Obviously, some will think none of this is worth the bother, but I think with Eclipse allowing emacs-style key bindings and having code completion and in-built debugging, I reckon it is well worth trying to move over to a more feature-rich environment for the bulk of my development worth.
So what suggestions do you have for easing the transition?
Eclipse is the best IDE I've used, even considering its quite large footprint and sluggishness on slow computers (like my work machine... Pentium III!).
Rather than trying to 'ease the transition', I think it's better to jump right in and let yourself be overwhelmed by the bells and whistles and truly useful refactorings etc.
Here are some of the most useful things I would consciously use as soon as possible:
ctrl-shift-t finds and opens a class via incremental search on the name
ctrl-shift-o automatically generates import statements (and deletes redundant ones)
F3 on an identifier to jump to its definition, and alt-left/right like in web browsers to go back/forward in navigation history
The "Quick fix" tool, which has a large amount of context-sensitive refactorings and such. Some examples:
String messageXml = in.read();
Message response = messageParser.parse(messageXml);
return response;
If you put the text cursor on the argument to parse(...) and press ctrl+1, Eclipse will suggest "Inline local variable". If you do that, then repeat with the cursor over the return variable 'response', the end result will be:
return messageParser.parse(in.read());
There are many, many little rules like this which the quick fix tool will suggest and apply to help refactor your code (including the exact opposite, "extract to local variable/field/constant", which can be invaluable).
You can write code that calls a method you haven't written yet - going to the line which now displays an error and using quick fix will offer to create a method matching the parameters inferred from your usage. Similarly so for variables.
All these small refactorings and shortcuts save a lot of time and are much more quickly picked up than you'd expect. Whenever you're about to rearrange code, experiment with quick fix to see if it suggests something useful.
There's also a nice bag of tricks directly available in the menus, like generating getters/setters, extracting interfaces and the like. Jump in and try everything out!
One thing that helped me transition from Emacs to other IDEs was the idea that IDEs are terrible editors. I scoffed at that person but I now see their point.
An editor, like Emacs or Vim, can really focus on being a good editor first and foremost.
An IDE, like Visual Studio or Eclipse, really focuses on being a good project management tool with a built in way to modify files.
I find that keeping the above in mind (and keeping Emacs handy) helps me to not get frustrated when the IDE du jour is not meeting my needs.
If you've been using emacs/vi for years (although you listed both, so it seems like you may not be adapted fully to one of them), using said editor will probably be faster for you than an IDE. The level of mind-meld a competant emacs/vi user can achieve with a customized setup and years of muscle memory is astounding.
Some free ones:
XCode on the Mac
Eclipse
Lazarus (Open Source clone of Delphi)
Visual Studio Express
Editions
Try making a couple of test applications just to get your feet wet. At first, it will probably feel more cumbersome. The benefits of IDEs don't come until you begin having a good understanding of them and their various capabilities. Once you know where everything is and start to understand the key commands, life gets easier, MUCH easier.
I think you'll find IDE's invaluable once you get into them. The code complete and navigation features, integrated running/debugging, and all the other little benefits really add up.
Some suggestions for starting out and easing transition:
- start by going through a tutorial or demonstration included with the IDE documentation to get familar with where things are in the GUI.
- look at different kinds of sample projects (usually included with the IDE or as a separate download) for different types of areas you may be coding (web applications, desktop applications, etc) to see how they are laid out and structured in the IDE.
- once comfortable, create your own project from existing code that you know well, ideally not something overly complex, and get it all compiling/working.
- explore the power! Debug your code, use refactorings, etc. The right click menu is your friend until you learn the keyboard shortcuts just to see all the things you can do. Right click different areas of your code to see what is possible and learn (or re-map) the keyboard shortcuts.
Read the doc...
And see what shortcuts/keybindings equivalents are with your familiar ones. Learn the new ones...
Old question, but let me suggest that in some circumstances, something like Notepad++ might be appropriate for the OP's situation which may be encountered by others. Especially if you are looking for something lightweight, Notepad++ can be part of a developer's arsenal of tools. Eclipse, Visual Studio and others are resource hogs with all their automagic going on and if you are looking to whip out something pretty quick with a whole bunch of keyboard shortcuts and the like or if you are interested in viewing someone else's source, this can be quite useful. Oh yeah, and it is free too.