But if they need some justification, why not start with "our tools and workflow have been integrated into SlickEdit. Moving away from SlickEdit means that the IT department (*not* the Engineering department) will need to move that integration into UltraEdit/Emacs/whatever".
That kind of argument tends to backfire on me. Usually it goes like this...
[Bluff] "Fine, you can do that if you do all the work to provide feature parity and not impact our workflow."
[Calls bluff] "Yes, that's completely reasonable, and we commit to doing that."
[Sense of forboding] *I wonder to myself, when will they do it, and will they do it to my specifications?*
[Hammer falls weeks later] "Hey, you replaced our stuff, but we're all hosed, when are you going to follow up on your commitment?"
[Punchline] "Oh, we cut that work because it's too expensive."
I'd avoid bluffing. Just say "No. Go away."
Anyway:
The reason I chose SE over UE is that SE is far more configurable than UE, and I'm able to optimize my workflow much better. UE has (had?) poor macro support, so when UE didn't natively have a feature or ability that I wanted, that was the end of it. SE's macro capabilities mean it can be extended to meet my needs.
The reason I chose SE over Emacs is that SE is far easier to extend with macros. SE has a C-like macro language that's immediately familiar, versus LISP which is more of a fringe language.
But briefly the primary reasons I chose SE are:
1. Sophisticated workspace and project support, supporting very large and complex projects. (Sure I want improvements to the support, but it's strong support, especially compared to other editors -- though my comparisons are a few years old).
2. !!! Sophisticated tagging support, with background tagging.
3. Most of the editor is written in its macro language, making it almost infinitely customizable, proportional to the amount of time you're willing to invest in any particular customization (a perfectly reasonable and appropriate tradeoff IMO).
This also means if a simple quirk or bug is blocking me, I can often fix it and unblock myself quickly, without needing to wait on a heavier-weight release schedule for a product update (assuming the quirk or bug isn't considered intentional behavior that won't be fixed -- e.g. JPSoft has done that to me many times).
