Follow-up to the Emacs saga

In Momentary Inf-IDE-lity, I tried to express my thoughts as I tried to find a full-time replacement for Emacs when I'm writing PHP. On a follow-up post, So much for cheating on Emacs, I related the pretty much dismal results of said search.

At this point, I've pretty much given up.

I've been using Emacs for about a decade now, coming from using Vim and then UltraEdit-32 before that. So, as you can probably imagine, my fingers are pretty much used to working with Emacs.

I suppose a large part of my desire to have a stand-in for Emacs is my deep and absolute loathing of PHP. It's inelegant, it's a crock, it's a band-aid slapped on a duct tape held together by bailing wire and spit.

Except for the part that it's what's letting me pay the bills and put food on the table.

But, still, I thought I could rid Emacs with the crap attendant with supporting PHP. Not Emacs' fault, mind you: even the most elegant, beautiful vase becomes near-worthless once you've decided to use it as a shit-receptacle.

So, anyway, until and unless I find an editor that's:

• reasonably lightweight (Emacs takes a lot of flak for being so damned heavy, but stock Emacs starts up faster than stock gVim on my machine),
• has support for Emacs keybindings,
• can do multiple modes in a single file,
• can work with Xdebug as a remote debugging client; and
• is free software

then I'll have to deal with having the evil-but-necessary PHP scaffolding to support my favorite habit: living.

(Maybe I'll break down and keep a copy of XEmacs installed. Hey, at least it meets all of my requirements-- er, except for the Xdebug one. Still...)