Keyboard Emulations. Eases the transition from other editors. Plus, you can set up additional key bindings.
Context Tagging and References. Text-mode editors like Emacs and VI[M] lack two big components to do anything close to what we do. First, they just don't have the level of symbol analysis we do - ctags and etags are primitive compared to what we do with C++, Java, etc. Second, they don't have the graphical chops to do list-symbols or function parameter help, or display symbol comments right in your editor view. SlickEdit really brings completion suggestions directly to you. And of course, if you like doing things the hard way, you can turn it off, or configure it to be on-demand, or to just assist with specific types of completions.
We are very configurable. We are fast, and we handle large files, really large files, and large numbers of files in our project system.
Multiple cursors. But it's not *just* that simple, we support multiple cursors with undo. Clark made sure that our implementation of multiple cursors wasn't just a feature check-box, it's full and robust and performant. He believes, and I agree with him, our implementation is the best multi-cursor editing implementation out there.
Projects and Workspaces. At the most basic level you can use projects as simply a list of source files you are going to be working with. It tells SlickEdit what files to build a symbol database for, and SlickEdit will assist you with filename and path completions when opening files. Using this, along with symbol navigation, makes switching between the source files you are working on much faster. At higher levels, you can use 3rdparty projects, or set up incremental builds, or use integrated debugging, or easily integrate other 3rdparty tools into your build menu.
Macro Recording.
Comment wrap.
FTP support.
Version control integration.
Code beautifiers.
Hex editing.
DiffZilla.
Backup history!
Too many others to mention.
As for what an Emacs user would miss after upgrading to SlickEdit, I have to say the #1 thing that comes to mind is they would miss their user-written Lisp macros. Ironically, the kind of coder who writes his own Lisp macros for Emacs, is probably the kind of person who would *most* appreciate the power of SlickEdit and the ability to write macros in Slick-C and the other power-user features of SlickEdit. However, this user is the most entrenched in Emacs, and would also have the most work to do to get settled in with SlickEdit (that's the irony).
On the other hand, the coder who uses Emacs out-of-the-box and basically is operating at a notepad with color coding and syntax expansion level would seriously benefit from SlickEdit and probably never look back. They would gain access to powerful features much more quickly than the Emacs learning curve.
Best of luck with your demo. I hope these comments don't come too late, I was out of the office for a while. Editors are a religion, you might get laughed out of the room, and don't take it too seriously if that does happen. The best way to evangelize SlickEdit from your position is to finish projects faster than your peers and be the guy who can dig into anything by using SlickEdit's power and come up with the solution faster. Eventually, someone's going to ask how you did that...
