Your mission, should you choose to accept it...

A few weeks ago I sent the following challenge to the PYxIDEs list, and I thought it might be a good idea to republish it here to give it a little more exposure.

<fade from dramatic music with a lit fuse running across the screen...>

Hi all,

Kevin O. and I recently discussed in IM about yet another
wxPython-based code editor and the subject of my Emacs use came up.
I've been an Emacs user for more than two decades, and it has been a
love/hate relationship for most of that time (I hate that I love it
and I love hating it) but I would like to dump it for something else,
iff the RIGHT something else came along. Part of our discussion
centered on the fact that it is not just the emacs-style key-bindings
that keep me using Emacs (most of the key-bindings I use are
customized anyway, or I load extensions to add CUA key-bindings, etc.)
but it is some more fundamental features that I use many times every
day that keep me there.

So here is your challenge and your mission impossible, should you
choose to accept it: Create a code editor that will pry emacs and its
25-year-old nearly dead technology out from under my fingers.

Here are the emacs features that I use very often that any editor
would need to have in order for me to switch. I've seen some editors
with some of these, but none with all unless it is an emacs clone.
I'll leave out the obvious things like platform independence, good
syntax highlighting, calltips or auto-completion. Also, these features
are just dealing with the code editor portion of the app, if it is
more than that (like a full IDE) then some of these things may or may
not apply to the non code editor parts:

* Python should be just one of the languages that this editor
supports, not the primary target. I spend as much time in C/C++ as I
do Python, and my editor of choice needs to help me with C/C++ coding
just as much as it does with Python. So some sort of support for
calltips and auto-completion would be marvelous, and also being able
to act as a front-end for gdb since I currently use emacs for that
most of the time.

* Absolutely every feature or action must be able to be done with
just the keyboard. Moving the hand back and forth to the mouse wastes
time, breaks concentration and contributes to RSI. Multi-key sequences
are fine as long as they are grouped in a logical fashion. For example
in emacs all of the version control features are accessible via the
Ctrl-x,v sequence plus one more letter.

* Incremental search, both forward and reverse, and wrapping around
after you've reached the end or the beginning of the document. I like
to have the same key to start the search and also do a search-next
after you've typed all the characters you are searching for, and also
to have backspace go back one search position and/or remove one
character from the search text.

* Multiple top level windows, and able to show any buffer in any TLW,
including those that are already displayed in another TLW. Of course
there should be key-bindings available for opening a new TLW, cycling
forward and backward through the buffer list, and a way to select a
buffer from a popup list of buffer/file names.

* The Kill-Ring. For those of you that have never used an emacs-like
editor it works like this: There is a collection of the N previous
blocks of text that have been cut or copied (in emacs 'cut' == 'kill'
more or less) When I do a yank (paste) it uses the last thing put in
the kill-ring. If I then immediately use another key-binding then it
replaces that pasted text with the next item in the kill ring, and so
on until I eventually wrap around and get back to the first one in the
ring, or I do some other command or move the cursor somewhere else.

* Registers. A text snippet can be copied into a register, which is
like the kill ring except you refer to each one by name, where the
names are 'a' through 'z'. You can also append to a register that
already has text in it, and you can paste the contents of a register
into the document at the current cursor location.

* Able to have selections be either a stream of characters or a
rectangle. A stream selection is like what you have in all text
editors, it starts from position a on line N and continues forward or
back to position b on line M and includes all the characters in
between. A rectangle selection is all the characters between position
a and b on lines N to M. In other words, it has width and height and
it might be something like positions 5 through 10 on lines 20 to 25.
Cutting or deleting a rectangle removes the text in the rectangle and
shifts any text to the right of the rectangle over. It does not remove
any lines although they may end up being empty. Pasting a rectangle
inserts the new text with the upper-left of the rectangle at the
current cursor position, shifts existing text to the right if needed,
and fills with spaces on the left if a line affected by the paste is
not long enough. New lines are not added unless the file needs to be
extended to accommodate the rectangle paste. Rectangles can also be
put into registers.

* Good keystroke macro recording and the ability to save and load
keystroke macros, and the ability to assign a key-binding to a saved
recorded macro. Any time I need to make the same edits to a bunch of
lines or groups of lines I'll record doing it on the first one
including the keystrokes needed to reposition for the next line, and
then stop recording and then it's just one keystroke to replay the
keystrokes for every other line that needs it done. I record, use and
throw away up to a dozen or so macros per day.

* If you must have a toolbar make it optional and keep it simple.
Toolbars require the mouse and the goal is to keep the hand off the
mouse as much as possible.

* Similarly, avoid using popup dialogs whenever possible. This
includes things like the file dialog. I don't mind seeing the file
dialog if I select a menu item, because most likely my hand is already
on the mouse, but the rest of the time I just want to hit a key, type
a path name (with tab-completion to help find stuff, up/down keys to
cycle through past selections) and press enter. So I would prefer this
editor to have something like emacs' minibuffer, or the QuickFind
panel in Firefox. In other words, when there is something you would
normally use a dialog for just create a small panel that rolls up from
the bottom of the frame, put the keyboard focus there, perhaps do
stuff in the main buffer as they are typing if appropriate, and then
when the user is done the panel rolls out of sight again and keyboard
focus is restored to their active buffer. This can be done for file
open/saves, search & replace, specifying build or grep commands (see
next item) choosing to execute some editor function by name that may
not have a key-binding yet (see item after next) etc.

* Flexible build/grep commands. Emacs handles both of these in almost
the same way so I'll list them together here. I hit a key and am
presented with either the default, or the most recently used compile
or grep command. I can edit the command or use the up/down arrows to
select previous commands that I've used. I then hit enter and emacs
runs the command putting the output in an editor buffer. There is a
key I can hit to kill the compile if needed. It then parses the output
and there is a key I can use to find the file listed in the compile or
grep output, load it, and position the cursor on the reported line.
(This can even be done while the compile/grep is still running.)

* For access to editor commands/functionality that may not be bound
to a keystroke it's real nice to have the ability to hit a key, type
the command name, press enter and then it's done. This can also allow
for commands that might need to prompt for parameters, be interactive,
etc. All editor commands should be named and can be bound to keys by
name or executed by name in this way.

* Regex search. Emacs has support for regular expression search modes
for all of the search types, incremental search, search/replace,
although I don't use it that much.

* Multi-file search and replace. Be able to select files
interactively, or by wildcard, or both. Enter search string, or regex,
and replace text. The editor loads each file and does the search,
allowing you to choose for each one whether to do the replacement, or
replace all.

* If it is a full IDE it would be nice to have a way to start just
the code editor portion for quick edits.

Things that would be nice to have, but that I could live without:

* Interactive diffs, merges and applying of patches.

* Able to be a front-end for gdb.

* Able to be a front-end for CVS, SVN, etc.

* Be able to run shell commands, or the shell itself in an editor
buffer.

* have a built-in psychotherapist or be able to play towers of hanoi.
;-)

<warning: this message will self destruct in 5 seconds...>