tuhdo

You are pretty out of date then. See my C/C++ guide (with demos): http://tuhdo.github.io/c-ide.html. It works fine on navigation projects like Linux kernel, it should work for you likely. With Projectile, I can jump any file instantly, even in Linux kernel with more than 46k files, and I've never seen this in an IDE.

And use GNU Global instead of etags. Finally, keyboard boost productivity many times over the mouse.

You can customize style as much as you can. Take a look at Emacs theme gallery: http://pawelbx.github.io/emacs-theme-gallery/

Emacs is an IDE, first and foremost, to Emacs Lisp itself. Other Lisps are close. It's an excellent editors for other languages, and a good enough IDE for some languages. See my C/C++ guide in Emacs: http://tuhdo.github.io/c-ide.html.

Fyi, people wrote parsers, chat and email clients in Emacs that LT is still dreaming.

If you don't like to chord, you can always use M-x, the same way as invoking commands in light table and even better. See helm-M-x: http://tuhdo.github.io/helm-intro.html#sec-4

You can use the popular Emacs Prelude: https://github.com/bbatsov/prelude . It's an Emacs setup that improves the original Emacs. The author is also a ROR developer, so he sure knows how to configure it properly.

To learn the basics of Emacs, start with my mini-manual: http://tuhdo.github.io/emacs-tutor.html

You can switch between .h and .cpp easily with ff-other-file. Bind it to a key:

(add-hook 'c-mode-common-hook (lambda() (local-set-key (kbd "C-c o") 'ff-find-other-file)))

If the .h is in the same directory as .c/.cpp, then Emacs automatically opens. Otherwise, you prompt for the .h file. Once the .h file is opened, subsequent execution of the command switches between the two files.

It's fine that you use the default. But when you seek more power, it's always available.

How do you refactor complex C code with myriad of macros? I think we should avoid writing code that having to seriously change its structure later. If we want to refactor, it should be minimal and manageable.

And if you mean seriously refactoring as in this article from Qt Creator: http://qt-project.org/doc/qtcreator-2.6/creator-editor-refac... that includes reformatting code, generating getter/setter or automatically detect and fix mistake for you, then no. I have never write such code in the first place that having to back later and I believe we should not fall into the use cases listed in that article.

My only use case for refactoring is to rename variable/function names.

I am using both GUI and terminal. I prefer the GUI for my local use. But when working, I have to connect to remote server only through SSH under the terminal. Instead of using Tramp (which is not practical for the current latency), I setup Emacs on the remote servers and use it from there when I connect to the servers.

Thanks for the explanation.

Because such refactoring is not really needed. You can do easily with sed.

What's so difficult about using Elisp to configure your editor? If you know how to turn on a light switch, you already know how to configure Emacs at its basic level!!! Most of Emacs lisp configuration is like this:

(semantic-mode 1) ;; 1 means turn the feature on

If you want to turn it off:

(semantic-mode 0) ;; 0 means turn the feature off

Most of Emacs plugins work this way, with a few more Elisp code for setting key bindings and other things. Anyway, the package maintainers always give you config Elisp code. Your only work is to copy/paste into your config file and it's done.

Your IDEs appears nice at first since they hide most of the complexity in a menu item called "Options". But when you need to adjust something, and when you click the "Options" menu, things are not so nice anymore. For example, try Eclipse.

I added a demo on how CEDET works with Boost: http://tuhdo.github.io/static/c-ide/semantic-boost-demo.gif

Here you also have an outline tree the Emacs way, which is very efficient to use when a file contains lots of function/variable definitions: http://tuhdo.github.io/static/part3/helm-semantic-or-imenu.g...

What's so complex? I wrote in the very beginning of the guide:

"In this guide, I will help you to setup an efficient working C/C++ environment. Despite looking long, the setup is short and easy (mostly copy/paste Emacs Lisp code into your init.el); most of the guide are explanations and demonstrations of many useful features. "

Most of the text are just explanations to help you understand what you are doing, why you need these features.

Or, you can have a simple recipe with 42 steps for setting up a working environment with Linux kernel in Ecliplse with barely any explanation, just learn by heart: http://wiki.eclipse.org/HowTo_use_the_CDT_to_navigate_Linux_... . The guide is merely for NAVIGATING the Linux kernel. Even with the first section of my guide with setting up ggtags or helm-gtags that you can do in 5 minutes, you can freely roam the linux kernel.

Well currently I only work with C not C++ anymore so my knowledge might be outdated. I thought that the rvalue reference is something new in C++11, as I read it here: http://thbecker.net/articles/rvalue_references/section_01.ht.... Your article seems to mention different thing from 2008? In the article I read, a function returns a pointer that you can assign it like this: get_pointer() = 1;

Thanks for the info. You must be David Engster, the current CEDET maintainer.

Yes, I agree with the preprocessor handling since we still have manually tell Semantic what preprocessor exists in the current project. But CEDET is still very usable for most of the things and I love it.

AutoComplete has nothing to do with C/C++. It's just a package for displaying completion candidates, but you must give it a source for displaying. It is pretty outdated compare to company-complete. Company also has a Clang[ backend, available through the command company-clang.

Emacs also has Clang based solutions such as rtags: https://github.com/Andersbakken/rtags that can index code as you type but is complicated to setup. Or you can use Clang to generate a tag database for your source code with clang-ctags: https://github.com/drothlis/clang-ctags , but the performance for creating tag database is not so good for large source tree: it took "98 minutes and a peak memory usage of 140MB" to generate a tag database for entire LLVM source.

As for CEDET, in what way it could not handle library like Boost? Could you be specific? I tried it before with Boost, and it works pretty well (i.e. gives correct completion candidates in a namespace). I used CEDET for getting completion candidates all the time in Boost.

I think it's pretty basic. I created a demo repo for people to play with, so they don't have to configure themselves: https://github.com/tuhdo/emacs-c-ide-demo

For C++, CEDET works pretty nicely with templates and libraries like Boost. I haven't used much C++ aside playing with lambda, so I'm not sure. I've looked at rvalue reference, and it seems to return an assignable pointer to do other thing from a function. Currently, you can jump to the function but not the pointer that the function returns.

Currently, I only work with C. But being able to jump anywhere in the Linux kernel source tree and your system include source (such as "/usr/include", "/usr/local/include" is already very useful, don't you agree?

I did write about customizing and extending Emacs here, and made a clear point about extending and customizing:

" Because the nature of Emacs is an extensible system, people write extensions to improve Emacs and share with others. The extensions improve various aspects of Emacs: Improve existing and add new editing features, integrate 3rd party tools, add programming languages supports, change Emacs appearance… Without the ability to extend, Emacs will just be another obscure editor with some useful features but cannot meet the demands of people, because different people have different needs, and Emacs maintainers cannot provide them all and integrate all into Emacs. With the ability to extend, people can bend Emacs the way they want, much like Lisp.

Unlike other editors which encourage users to stay with the default as much as they can, Emacs encourages users to customize and extend Emacs as much as they can."

http://tuhdo.github.io/emacs-tutor3.html

I just don't want to mix the two things: Emacs basics and Emacs extending together in a guide. It should be separate. I used to use packages a lot, until I realize that many built-in features which I didn't know serve me well. Learning stock Emacs is beneficial because users get the features that are always available.

> I started learning with Emacs Lisp Manual, not a tutorial or Emacs Manual and it got me up to speed in no time at all

I guess you method could work for, but I think it would be intimidating for most new users when they first read that to be able to use Emacs, they will have to learn Emacs Lisp. This is contrasting to everything else, even Vim.

Vanilla Emacs is definitely better than Notepad++ or Gedit:

- Emacs is an implementation of Emacs Lisp with an editor on top of it. The other editors are just... editors.

- Emacs has many useful features such as:

+ how to use mark and point and region. A useful feature is exchange-point-and-mark; other editors do not have this.

+ Dired

+ ibuffers, that can manage hundreds of buffers

+ a window management system (so you don't have to use things like tmux, screen)

+ registers, you can save anything, like window configuration, text, position

+ the help system

+ Bookmark (to quickly access things later)

+ Calc (a scientific calculator)

+ CEDET a language framework for building IDE features (like context-sensitive completion, jump, find references...). The best language it is supporting is C/C++, as demonstrated in the guide.

...more features that typical editors won't have...

Learning all these things should not require customization and external packages to further add burden to learners. After people learned something like Dired, if they want more, they can look it up for packages like Dired+.

Finally, Prelude disables arrow keys and encourage users to use key bindings like C-f, C-b... I think most of the key bindings for editing in Emacs are fine and make editing faster. Of course, the bindings are not as ergonomics as Vim, but it is still much better than other editors.

Since you don't like C-f, C-b... I guess you don't like key bindings with prefix C-x and C-c as well?

You can use Ag right inside Emacs with this package: https://github.com/Wilfred/ag.el

If you use Helm, there's helm-ag: https://github.com/syohex/emacs-helm-ag

Use MELPA and package manager to install the above packages: http://tuhdo.github.io/emacs-tutor3.html#sec-4-1

Ahhh this is good to know

Thanks for writing such a good article, so people can have a better glimpse of what Emacs is capable of. It saved my time because I don't have to research all of those and make my article even longer :D

I used byzanz-record for these screenshots: http://askubuntu.com/a/123515/13847

Do you use this patched Emacs for Windows: http://semantic.supelec.fr/popineau/programming-emacs.html#s... ? According to the guide in that page:

"There is no installer. All you have to do is:

- Unpack in a location like c:\Local\

- Setup a shortcut on your desktop to c:\Local\Emacs\bin\emacsclientw.exe

- Double click the new shortcut."

Or just use the 32 bit version from official GNU Emacs homepage.

Could you tell me what the problems are? I use Emacs on Windows fine, with all my 3rd-party packages. At least with stock Emacs, it should work on Windows.

I've fixed that. I only wanted something simple for new users to try out the new feature (Macro).

This manual is only about stock Emacs features, not adding complexity with 3rd party packages. When I first introduced on Reddit, someone advised me to stick to stock Emacs (which I did) because they see this section using an external package (ggtags) for browsing kernel source code: http://tuhdo.github.io/emacs-tutor.html#sec-8. When people are good with the basics, they understand what they need and find appropriate packages.

If you want advance techniques, the primary resource should be Emacs Lisp Manual, Emacs docstrings, and learn code written by package maintainers.

EDIT: Even before working with Emacs Lisp, using 3rd party packages already makes Emacs much more advanced.

I've fixed some mistakes in sections before the "Concepts" section (which is the core of the manual). Hopefully it improves reading before getting the actual part.

Sure, thanks! I've never used IRC and always wanted to learn it. Now it's the chance to learn ERC. In what IRC channel can I connect to you?

You need extension package. Workgroup2 is great for this: https://github.com/pashinin/workgroups2

With workgroups2, windows configurations can be stored in a workgroup, and you can create as many workgroups and named it; later, you can switch back. Because you can name your window configurations, you don't have the burden to remember which to which in registers. You can also save your window configurations to continue using them in later Emacs sessions.

You can issue a command to save current session with workgroup2.

Thank for your feedback. I will improve it. Please tell me my mistakes , I will fix it quick. Even a little is better than none. For your convenience, feel free to open a new issues at https://github.com/tuhdo/tuhdo.github.io

Great. Keep up using Emacs and you won't regret, especially using it for writing Lisp code.

You should use Projectile: https://github.com/bbatsov/projectile . Projectile allows you to Grep a project under VCS easily.

And use Helm with it like this: http://tuhdo.github.io/helm-intro.html#sec-28

Is able to use GNU Global/Cscope/Ctags to jump around Linux kernel source code, in Linux/Mac OS/Windows good enough? Like this: http://tuhdo.github.io/emacs-tutor.html#sec-8

If you want to see what Emacs is capable of, check "Emacs Mini Manual" that has the demo at the beginning: http://tuhdo.github.io/emacs-tutor.html

Then, if you worry about fuzzy project finders, better one exists that does not need fuzzy (I ditched all fuzzy finders for it): http://tuhdo.github.io/helm-intro.html