I have to try this out some time: There is an Emacs mode for code completion using CLang. It is mentioned in a blog entry by some guy. The nice thing here would be, that it enables ObjC code completion, which is a good thing™. Especially if your are coding for OS X or iOS.
…it’s buggy. I tried the snapshot, but that behaves strange as well. My workaround so far is to go fullscreen. Still, customize is broken: the customization buffer shows up in the wrong buffer. I haven’t found a bug description for that yet. Also, the git interface does not work. I will install magit next, to see if that helps. Anyway: Emacs on (K) Ubuntu is in bad shape…
Update: I fixed the first two problems. Turns out, emacs-snapshot does work, I just forgot to de-install emacs23-gtk and install emacs-snapshot-gtk. Thus I still fired up the old version. Customize works as well now, after uninstalling cedet and ecb, and instead using the latest ecb and cedet from Sourceforge. The versions shipping with Kubuntu are slightly out of date and were causing the buffer problem.
The quit command C-g is pretty much standard in Emacs. It runs the interactive function keyboard-quit and also serves as the default quit-char. It aborts basically every running function, also it allows you to cancel operations in the minibuffer. The Emacs documentation describes current-input-mode, set-input-mode and set-quit-char for getting and setting the quit-char value. Also, global-set-key allows you to rebind keyboard-quit to another character. However, this does not work very well. The quit-char is not settable for non-tty Emacs versions, e.g. on OS X using Cocoa Emacs you get this:
So, basically nothing changes. On a tty it looks more promising:
After rebinding the keyboard quit as well, using (global-set-key (kbd “C-q”) ‘keyboard-quit), not much happens either. It seems the minibuffer assumes C-g to be the choice of the day. Running find-file with C-x C-f or interactively via M-x find-file, and then hitting C-q does nothing except printing “Quit”. Hitting C-g however quits the minibuffer. This seems to be documented in Bug #1218 of Emacs.
Update: This is really nice, now also the GUD debugger frontend works nicely. Check it out:
(let* ((dic ispell-current-dictionary)
(change (if (string= dic "deutsch8") "english" "deutsch8")))
(message "Dictionary switched from %s to %s" dic change)
(global-set-key (kbd "<f8>") 'fd-switch-dictionary)
On OS X, I recommend to use emacs-app or emacs-app-devel from MacPorts. For flyspell to work correctly, also make sure to install aspell and e.g. aspell-dict-de. Otherwise the above function will complain, most probably.
I am working on a C++ project which is organized such that source files (*.cc) are in some subdir called, let’s say, project/dir1/, and header files (*.h) in a directory called project/include/. Now Emacs has a function called ff-find-other-file, which is able to switch between header and implementation of C/C++ files. If you take a look at the source of this function, you will find another function called ff-get-file-name, which tries the following: first, it looks for already visited buffers, if they contain the appropriate file. Then it will search a certain set of directories, if they contain the file. Last, it will ask to find or create the file in a user specified directory. However, in my case, although both files are already being visited by buffers, the first test (finding the file in already loaded buffers) fails. Actually the offending piece of code looks like this:
(if (bufferp (get-file-buffer filename))
(setq found (buffer-file-name (get-file-buffer filename))))
The problem is that this always fails, and found will always be nil. The filename constructed is not being expanded, as get-file-buffer demands. However, expanding it is useless, since the exact expansion (absolute path) of the searched file is not exactly known! However, you can rework these lines to just look for a buffer whose name matches the file you are looking for:
(let ((b (find-if (lambda(x) (string= (buffer-name x) filename)) (buffer-list))))
(setq found (buffer-file-name b))))
Note that this will only do a simple string matching. It might happen that for a certain file foo.cc you have to buffers visiting some foo.h. The function will only find the first one. But in my opinion, there is not simple solution to find the semantically correct header file, anyway. So this is still better than the broken solution in Emacs.