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 13 years ago.
Am planning on learning how to use this editor since i was told that this was the "hacker's editor".
So what is so nice about emacs?
It can be customized using the language of the 'gods', and can do everything except wash your socks and make coffee - wait? coffee? Mmmm.
The ability to record and playback edits, macros, is my favorite feature. I haven't seen another editor that supports this as well, so I find myself switching back to emacs regularly even when I'm working in Eclipse, etc.
The coolness comes from the fact that every keyboard shortcut, every menu item, every ad-hoc expression/function evaluation is recorded. Throw in navigation at the syntax level (e.g. "forward one expression"), and recorded macros wind up being able to deal with a wide variety of variation of input data.
Then you can save the recorded macro to your config file with a name so that you'll always have it.
Honorable mention to (a) registers for having a copy/paste buffer for each key, and (b) much easier to extend than other editors once you grok some elisp.
The fact that once you've been using it for a while, you can do pretty well anything you'd like to do with just a few keystrokes.
The fact that it's probably the most configurable bit of software on the planet.
The fact that it's been around for ~30 years, so there are an awful lot of useful tools built for it (major modes, handy little functions etc).
Emacs takes GDB to the next level.. No other software integrates as well with GDB....
It's super configurable (for example, when I press F5 my emacs parses my Makefile, figures out what executable it creates, splits the window and runs gdb against it)...
I've been casual Emacs (GNU) user for many years. Never become super proficient but it is definitely my choice for Notepad-like app. Works flawlessly on all platforms (*nix, Win, Mac), works in a console and as UI.
Learning curve is a little steep but it totally worth it. Eclipse (which is IDE I'm most frequently using) supports Emacs-like editing mode. Search-replace is mad and very convenient.
Now - if you are a hacker - Emacs is just heavenly. There's always a plugin for practically anything and there are many-many people who don't use anything else.
And then there's LISP.
So - I say do it! It's no doubt very valuable skill to have
Related
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.
Sorry if this is a strange question. But I've been using Indigo for a long time, and after upgrading to Juno I find that the UI is less responsive, has bizarre new colors (thankfully they included a Classic theme) and not a single new feature that I can see, anyway. They changed the default redo shortcut from ctrl-y to ctrl-shift-z, even though ctrl-y is a de-facto standard for that type of shortcut. Seems like a lot of changes for change's sake.
Frankly I am somewhat underwhelmed by this release. I'm not deliberately trying to be negative here, I guess I just haven't seen the light yet :-)
Does anyone have a success story where Juno was just the thing they needed to solve some specific problem or shortcoming of Indigo?
Not really a success story here...
I downgraded to 3.7 again because the performance of 4.2 is really bad.
I didnt't tweak anything in eclipse.ini in either version, but 3.7 runs A LOT smoother with the same (quite big) workspace.
I was looking forward to "Code Recommenders" plugin, but deinstalled it after a few hours. It was kinda annoying, perhaps you have to use it a longer time to get used to it.
Xtext 2.3 is important for me, but I can have that in Indigo too.
The new layout is ugly, but thats just my opinion. Other people seem to like it... But apart from the looks, it was really slow and laggy for me when resizing or moving views.
There were some other minor bugs, perhaps my fault, no idea, but in the end I'm happy again with 3.7 :-)
Eclipse Juno is worse than Indigo. The interface is less responsive and more annoying. For instance the files are always opened in the right window and and not in he cursor one. They have to be dragged and dropped to the location but!!!... placing them in a separate/desired window requires more effort because Juno seems to place it in the most unwanted one; also, tabs can be placed harder. More annoying things come with debugging. Sorry for the developers but is crap - many times it does not to find the file in which the breakpoints are located.
I do not recommend the upgrade.
(I can't comment on existing posts)
Regarding UI styling:
See [1] for a short discussion on how the style can be changed. There will bis a set of new styles available soon.
Regarding Code Recommenders:
moeTi, I'd be glad to learn what you found annoying about code recommenders. The general idea or the way it's implemented? Feedback is welcome [2].
Thanks,
Marcel
[1] http://www.vogella.com/blog/2012/07/11/eclipse-4-is-beautiful-create-your-own-eclipse-4-theme/
[2] http//www.eclipse.org/forums/eclipse.recommenders
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 am looking for a good editor for a Symfony2 project and other projects. I really don't need the fancyness or thousands of scripts loading, etc. I personally prefer easy and clean structured IDE - that's why I actually always tend to close Eclipse.
I am running Mamp on a Macbook with OS X Lion.
Currently I always go back to Komodo. So my question is: What are the advantages of having Symfony support in Eclipse and Netbeans (I actually tried both)?
I don't mind editing and going back and forth between the editor and the browser. I never really understood why there needs to be a huge application for that. I just can't see any advantages other than the code intelligence, and integrated subversion tools in the editors. Can anybody agree on that?
I use NetBeans too which works well even with Symfony 2. You don't need to set anything, just create a new PHP project from existing Symfony folder. You'll get autocomplete for classes and validation check for YAML (if you use it, of course).
For Twig you can install this plugin which gives you syntax highlight and nothing more. This is enough for me. The only problem I found is that Twig templates are hard to read if you use some dark (and cool) NetBeans theme: you should use default black on white one.
I don't recommend Eclipse even with Symfony2 plugin: works really bad and it takes minutes to install. The only good feature (I can't get in NetBeans) is custom commands for generating entities, install assets and so on.
I use NetBeans for all my PHP projects, including symfony 1.x stuff. I used to use Eclipse but found that auto-complete would hang from time to time - though they may have fixed that. Both are memory hungry and seem to hang onto RAM increasingly over time, hence both need restarts periodically if you are in the habit of sleeping your machine rather than turning it off.
The autocompletion is pretty good in NetBeans, anyway, so I've stuck with it. I agree on your assessment of framework support in IDEs generally - it may be nice to have, but I'm happy with the CLI.
#Mike i've been working on a symfony plugin for eclipse, it's available here: http://symfony.dubture.com/
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.
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.
There's a great project called the Ruby Koans, it's a series of tasks to exercise yourself in the Ruby language, stepping you through the standard library using the Ruby Unit Testing suite as a learning tool. It's a great project.
I'd love to see something similar for Emacs.
Can anyone recommend any Lisp exercises to be done inside of Emacs to both exercise Lisp and Emacs usage? Perhaps also while completing the Ruby Koans?
There used to be lesson in .el format (emacs lisp) at http://www.gnuvola.org/software/elisp-tutorial/.
You can find a copy of the tutorial here now.
I learned a lot from them. You read them in emacs in lisp interactive mode, and practice within the text.
The book, "Writing GNU Emacs Extensions", comes pretty close to what you're asking for.
But, if you don't want a book, there are three similar questions already in stackoverflow: What's the best way to learn lisp,
How to quickly get started at using and learning emacs, and Tips for learning elisp.
I don't know a "walk through" series that exists, but have found that the best way is to start thinking about little things you wish it did, and then trying to make it work (asking here helps). Even if Emacs already provides such functionality, you might find it more interesting to solve problems you want solved, rather than a bunch of throw-away lessons that hold little interest to you.
The The Little Schemer is a book of Lisp exercises. You need to be aware that some of them are impossible in Emacs Lisp, as it doesn't support closures.
It is also focused on teaching recursion to non-programmers, meaning that you won't cover the full range of Lisp statements (most exercises just use (cond ...) recursively.)
I really enjoyed it though.
A very old Oreilly book, Writing GNU Emacs Extensions, has some, if I remember correctly. You might also want to look at the "Emacs Lisp Intro" found in the info pages (you access them using M-x info.
Honestly, the best way to learn Emacs is to change the way you look at it. Don't look at is a text editor to be learned, but as an environment for writing text editors to be explored. Think to yourself: What did I always want in a text editor but never found in the editors that I have used? Set yourself about making it. You'll learn far more, more quickly, trying to make your "own" editor piece-by-piece than by trying to remember lessons learned from some loosely (if at all) linked exercises that have no context in a problem to be solved.
How is this one:
Write a simple program to open a particular file ("~/ekoans.txt") and select a random line from that text file, that is displayed to the user in a new temporary buffer. Call the function ekoan-random, and make it callable by the user.
The first few lines of ekoans.txt are:
Make ekoan-random open up a new file for you instead of a temporary buffer, and insert apropos header text in the new buffer.
Write an ekoan-sequential function that behaves like ekoan-random, except it works in sequential order
Make ekoan-sequential persist through a customization variable
Make the name of the koan file changeable by a customization variable
I call this Koan-strapping!
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.
As an old fart who has settled into using emacs whenever I can, I hear about Eclipse every so often.
Is there any real reason to use Eclipse and give up all the knowledge of emacs and packages, plus the macros I wrote for it?
emacs and vi don't intrinsically support building, debugging, "project"-based collections of files, etc -- Eclipse and other IDEs do, so that's the IDE's plus... better integration, wrt the "motley collection of plugins" for powerful-but-not-IDE editors such as vim and emacs.
That being said -- I'm a vim lifer (30+ years since I started w/vi, before viM was built;-) and I stand in awe of my emacs'er colleagues (have to ack that, no matter how incredibly powerful vim is, emacs is a notch above). But I think I also see how the smooth, seamless integration of IDE's such as Eclipse can help my younger colleagues who're addicted to THOSE!-)
The most important feature for me is refactoring: Renaming of methods, classes and interfaces on all locations they are used.
With that you can change the complete structure of your project easily.
I also tend to use Emacs whenever possible, but for Java I will still occasionally fire up Eclipse to use its refactoring tools.
Examples of refactorings in Eclipse
If you are doing Java, yes. Support for browsing the code, for code completion and refactoring is worth it, IMHO.
If you are doing C/C++, maybe. Support for the language is not as good, but I still like the overall view it gives me on the project, searching the whole hierarchy and the SVN support, especially the synchronize view.
Eclipse can be switched to key bindings which mimic the basic Emacs setup.
It is still easy to switch to Emacs temporarily for doing something more sophisticated, e.g. with keyboard macros.
I don't know if you'd count this as a real reason, but I certainly enjoy having Eclipse's excellent code completion and customizable templates.
Probably not. After a brief (decade) stint with Visual Studio, I'm squarely back in the Vim camp now and like it here. I thought I'd try Eclipse a while ago but it only took a couple of hours to realise that I simply wouldn't be comfortable in that environment.
Stick with the tools you know, and know them well.
It for me totally depends on the language/environment I'm working in. For something like Java Eclipse is a life-saver but for other languages having code-completion and auto-imports might not be all that important.
In the end it mostly comes down to where you yourself feel more productive.
Refactoring and java completion are big reasons to use Eclipse. Unfortunately, the emacs keybindings in eclipse are incomplete, it doesn't understand ^x2 or any other of the buffer manipulation macros, it doesn't understand keyboard macros, and it's missing a whole bunch of other features as well.
The problem is that emacs support can't be done with clever keybindings that sit on top of conventional WYSIWYG editor: it needs a fundamentally different approach to accessing the edit buffer. This could be added to eclipse, but so far nobody has bothered.
Perhaps you will?