19 comments

[ 76.9 ms ] story [ 573 ms ] thread
Fyi, there's an alternative available to JDEE for those doing Java work with emacs. malabar-mode drops some of the legacy stuff, but adds support for generics and uses Groovy in place of beanshell:

http://github.com/espenhw/malabar-mode

cscope is also incredibly useful for those doing Java and/or C++ with emacs.

This is exactly what I've been looking for! Thank you.
Nice, thanks! (Hmm, I wonder how much it relies on maven..)

Now that I remember (I haven't tried it yet), there's also this: http://github.com/senny/emacs-eclim

(a headless eclipse instance providing eclipse features inside emacs)

Title should probably mention that this is Steve Yegge's .emacs, and not Joe Shmo Programmer's.
JDEE thwarted my first attempt at learning Emacs. I wanted to get into it for Java development.

>It's an absolutely unbelievable pain in the arse to

>install. And his website is buggy, and the code is often

>buggy, and I generally detest the application, and Paul

>K's no picnic himself. Other than that, it's great.

I felt the same exact way. And at that point I felt if I could not use emacs for Java, I might as well stick to Eclipse. Luckily I'm a python guy now, so I'm free to avoid JDEE.

Any Emacs gurus know this one: how can one add a macro to the macro ring without re-defining it? I can't operate on a macro (e.g. with kmacro-step-edit-macro) unless it is in the macro ring, but sometimes macros have already been deleted from the ring (kmacro-ring-max defaults to 8) and are saved only as an elisp definition in the .emacs file.
(comment deleted)
When do you decide to use some directory like ~/emacs or ~/elisp or whatever instead of your ~/.emacs.d/ directory for your packages? A lot of emacs sites say to use ~/.emacs.d, but then I see a lot of masters putting them in a directory of their choosing...
Personal preference I suppose. In Windows, the default /User/Name/AppData/Roaming/.emacs.d/ is a little annoying.
When I started out, I think I somehow was under the impression that .emacs.d was some sort of cache, and not for end-users to mess with. Actually, I feel like when I first started out on Red Hat 5 it wasn't there, but I probably just wasn't being very observant.

At some point I set up auto-insert for a variety of files, and the howto I found used the directory .autoinsert, and at the moment that's actually where my elisp that isn't in my .emacs lives. It's a little hacked together and ad hoc, but not worth my time to fix. Nowadays I've customized everything I want to, and mostly am installing thirdparty packages.

.emacs.d is fairly new. I created my ~/site-lisp/ dir 15 years ago and just haven't felt the need to rename it to something "standard".
I see - yes, most of the masters whose .emacs.d file I've had the privilege to look have been from the old guard.
The "a combination of the Spam problem and our switch to Exchange finally drove me to Outlook" part threw me off for a bit, until I saw "Published Sep 25th 2004".
Yeah, I sensed it was just a little dated when he mentioned migrating from CVS to Subversion.
I wonder why everyone writes out the function invocations to add each directory they're adding, rather than doing something like

(labels ((add-path (p) (add-to-list 'load-path (path-join emacs-root p)))) (let ((paths '("foo" "bar"))) (mapc 'add-path paths)))

Is there an advantage to writing it out?

I wouldn't say everyone does that. I would just say that it is a artifact of the incremental nature of building a .emacs over many years, and isn't really worth refactoring.
Sorry, meant "from my limited observation it seems that everyone"... but what you suggest makes sense.