I've never used emacs- currently using XCode to do C++ development. While I find the demonstrations interesting, what would emacs buy me as a C++ developer?
Emacs is not only an editor, but a "computing environment" that can be readily customized and extended using the Emacs Lisp (elisp) language. In fact, much of Emacs itself is built with elisp. Some developers find that kind of flexibility in their tooling to be highly compelling, others not so much.
I'm not a C++ programmer, but I turned up the following guide with a Google search, which might you might find interesting:
Maybe not much. When working with C++ - at least in my experience - you get more use out of code navigation and code completion (two things that emacs supports rather averagely, even after customization) than you do out of text editing functionality (for which emacs is excellent).
I don't know that I agree with this. I'm rewriting for the fourth time a blog post I wrote on auditing C/C++ code using Emacs. The combination of Helm, cscope/ascope, hi-lock, ectags, Projectile, and incremental recursive grep is pretty hard to beat.
I use unobtrusive dabbrev-style completion --- I don't want popup menus with completion possibilities drawn from documentation, because Dash.app does a better job of that and is shared by all applications.
I think Emacs does an at least adequate job at all the core functions of Xcode, but does some things Xcode can't do at all.
(It's been a few years since I've written more than a couple thousands lines in Xcode, though.)
Don't worry, I'm not saying Xcode isn't awful. I've just found that code navigation saves me more time than having a fancy text editor does. And even after putting some effort in, the results with emacs just aren't as good (particularly compared to effort expended) as what you get from Xcode and Visual Studio.
Which is a shame, because Xcode's text editor is awful (or did I mention that already??), and Visual Studio's is crashingly average. I'd much rather use emacs.
(I use company-mode, with the clang backend, and it's OK. For code navigation, currently nothing, but rtags (https://github.com/Andersbakken/rtags) is on my todo list. The README is worth a skim - it has a cute way of grabbing the list of files you're using.)
Instead of cscope/ctages, have you tried GNU GLOBAL? I've taken my first steps with it and the ggtags mode. So far, I am finding it to be drastically better than ctags.
I didn't even know about it. This looks awesome. Highly recommend: wrap GNU GLOBAL in a web app (scrape its output, stick it in a database). We did that at Matasano (with dumber tools than GLOBAL) and not only was it incredibly useful, but shockingly, shockingly easy.
I didn't know GLOBAL had a web interface, but we generally want search, highlight, bookmarks, and notes, in addition to clickable cross-reference popups. We used ectags and Pygments.
Makes sense, I think. As I said earlier, I am new to GLOBAL entirely. Something I found as I was building up my new emacs setup at work. So far, I've been impressed. Not sure I'll ever care for the web interface, but the ggtags mode has been a dream. And I've really only used find-references and find-definition.
Not really. With Emacs, it makes navigating a project like Linux kernel seems a small project. You can see the demos in my other answer here: https://news.ycombinator.com/item?id=8616737
Emacs allows you to jump to anything instantly, even with source tree like Clang or Linux.
Possibly not much. I've never used XCode for C++ development but I imagine it
has pretty nifty Clang integration, given Apple's investment in Clang. Anyone
who suggests using ctags, GNU Global, gtags, CEDET's own parser (implemented in
elisp!), etc. for C++ navigation is basically saying "use a C parser to parse
C++ code", which works well enough if you're writing 1990s style C++, I
suppose. There are projects out there to integrate with Clang (such as rtags
mentioned by another poster) but it will require hours/days of setup &
frustration, and the result won't be as good as a dedicated C++ ide.
Where emacs shines (for me, at least) is when you spend a lot of time in
different languages. Maybe you spend 50% of the time in C++, but the other 50%
in shell, makefiles, python, etc. -- and the benefit of better C++ code
navigation begins to seem like a micro-optimisation that isn't worth the
tradeoff compared to Emacs's support for navigation, version control,
compilation, linting, grepping, etc etc, all of which are consistent across all
languages. Not to mention Emacs's great support for text manipulation in
general.
Also Emacs seems to me the best bet for the "one true editor" you'll still be
using in 20 years (by which time hopefully few of us will still be using C++).
I'll also point out that on OS X, Emacs has a lower learning curve than any
other OS, at least as far as the basic keystrokes: OS X's Command key still
works for the usual shortcuts (cut, copy, paste, save, open, quit, undo) while
the quirky emacs bindings are on the Control and Option keys. This doesn't make
it any easier to set up a C++ navigation solution, of course.
I agree with everything you said about other aspects of Emacs.
You are right that supports for C++ is not as rich, since it is such a complicated language. But for small C++ projects and large C projects, it is pretty much usable, especially just for code navigation. At least it's better than using Grep and better than nothing at all. The currently available tools are perfectly usable for those who only write C.
For code completion, there's no pretty solution, but at least simple solution like company-clang which uses clang to get completion candidates from system include paths is pretty usable.
On the good side, once you are used to the keys, the text editing part is pretty efficient.
Also, you have access to a lot of the other modes once you want to step out of the C++ tasks, to look at other files (makefiles, log files), keeping notes with org-mode, opening ftp windows, pretty-printing,....
Plus there's less behind the scene magic than in IDEs and you have access to everything to see where something breaks. It's not a black box the same way an IDE is.
On the bad side, you'll have to spend time tweaking packages and so on to get IDE-similar goodies like autocomplete. I can't remember if there's a similar thing as a background compilation that highlight errors as you type. But the thing with emacs is that if you wonder about a plugin, there'a good chance it exists already.
XCode is amazing for C/C++ development, but Emacs is just better as a text editor. The rtags project [1] is under active development right now to have more IDE-like features in Emacs for C/C++ developers. There are some other projects, for example clang-complete-async [2]
- Switch between other files with same names but different extensions: http://tuhdo.github.io/static/helm-projectile/helm-projectil.... Work not only for C/C++ but other languages, and is customizable. You don't have to configure anything, like adding include paths for the command to search. Everything is automatic. Just use it as it is.
Note that in the demos you may see me type in the commands. You can think of it like the start menu in Windows, but actually those commands can be executed quickly with a shortcut. I type in the commands for demonstration purpose to Emacs users.
- code compilation: you can click on the error and it gets you to where you want; work with any build system, while other IDE only supports a specific build system, i.e. for Makefile project, you only get plain text error message. DEMO: http://tuhdo.github.io/static/c-ide/compilation-mode.gif.
- Switch between other files with same names but different extensions: http://tuhdo.github.io/static/helm-projectile/helm-projectil.... Work not only for C/C++ but other languages, and is customizable. You don't have to configure anything, like adding include paths. Everything is automatically done for you.
Emacs will tell you the exact location where you missed instantly when the files are loaded. No worry! Anyway, to try out Emacs these days everything is already done for you:
Warning (initialization): An error occurred while loading `c:/Users/swah/.emacs':
Wrong type argument: listp, 769
To ensure normal operation, you should investigate and remove the
cause of the error in your initialization file. Start Emacs with
the `--debug-init' option to view a complete error backtrace.
15 packages are updated. I close Emacs and open again, and it still seems to break on the same place - something related to Magit. Fault of my customizations? Maybe. I don't know. Consider going back to Sublime? Yep.
So... no, tracking the source of errors ain't that trivial. What options do I have now? Throw away my customizations and start over?
It gives you hints like "buffer position 28726". You can press "M-g c" and enter that number to jump to that location, which is a character location of the error.
I wrote a guide on how to use package.el to install your package and how to customize and extend your Emacs here: http://tuhdo.github.io/emacs-tutor3.html, if you want control of your configuration from scratch.
Probably if you do not have proper Elisp learning, you should use Prelude: https://github.com/bbatsov/prelude. Everything is configured for you and packages are downloaded automatically. This is the easy way. Put your personal configuration code in ~/.emacs.d/personal/. You can also enable additional modules based on your need in ~/.emacs.d/sample/prelude-modules.el by toggling off comments: https://github.com/bbatsov/prelude/blob/master/sample/prelud....
I haven't tried loading from a different location, but you should try in your ~/.emacs.d first. Are you sure your packages are installed in Dropbox folder? I think it is installed in ~/.emacs.d. You should use a VCS like Git to store your configuration in the same .emacs.d directory.
Finally, to make sure it is because Magit, you should uninstall it to see if your Emacs loads properly. In my Windows machine, it loads perfectly fine with more than 130 packages.
Actually I've used emacs since 2003 or so... but still.
Removing magit from ~/.emacs.d/elpa and reinstalling seems to have solved it. I'll check prelude.
