New Editor: CodeEditor

Please see editor requirements.

I haven't had time to actually test the editor yet but I took a quick look at the code and here are a few things which I think needs work.
We don't maintain the actual editor libraries, so only the implementation files in the wysiwyg folder are relevant here. The editor itself (and preferably also previous versions of it) needs to be available from a public location.
The editor doesn't have a version string, and the version is currently hardcoded into the .inc file, making it impossible for Wysiwyg to detect which version is actually installed.
The editor instances can not be configured individually (at all?).

The editor "pollutes" the global namespace by adding several global functions, we try to avoid this when we can and make all functions methods of a single global object representing the 'thing' you're interacting with. Like the Drupal or jQuery global objects.

Support for at least an 'insert' method for the clientside implementation would be very nice and is likely to become a requirement for Wysiwyg 3.x as more and more modules want to use it.

About the version, yes I know that this is the only version, but what happens if a bug is found or a new feature is introduced?
As we keep the implementations and editor libraries separate, the implementation layer must be able to read the current version of the editor from one of its files. This editor may be written specifically for Drupal/Wysiwyg, but others may at some point want to fork it and adapt it to some other project, and then that version number will come in handy. It's GPL code after all. ;)
You shouldn't need to much abstraction to get that in, just move the '1.0' string from the codeditor.inc file to codeditor.js and make codeditor.inc read that string in the same way the other implementations do.

There's nothing to configure. All it does is add position, line and column information to the screen just below the textarea.
Ok.
... I did preface all the function names with "codeeditor_" to avoid conflicts.
I should have been clearer about this not being a strict requirement, other editors use global functions as well, and I do appreciate the functions being prefixed.
It was not so much an OOP thing as more a convenience when debugging via tools like Firebug. When everything belonging to an 'entity' it's more easy on the eyes to have all that folded away until needed in the DOM representation. =)

An "insert" method at which point? There's already an attach and a detach function. Does there need to be more?
Oh, I assumed you had looked into the other implementations which have an 'instance' object.
Each editor can create an Object in Drupal.wysiwyg.editors.instance.editorName which will be copied into Drupal.wysiwyg.instances.fieldName for each attached editor.
One of the methods that the Object can have is 'insert(newContent)' which is used by other modules to insert snippets at the cursor/selection.
As your editor uses the original textarea, you could probably just copy this code from wysiwyg/editors/js/none.js (which is the 'editor' used when all are detached). That should not require any changes to the editor code itself.
This 'instance Object' is a bit clunky and we'll refactor this for 3.x and improve the documentation a lot.

As of now, I have no idea how to handle such feature requests.

Please don't get me wrong and please don't take this personally or anything like that. It's just that Wysiwyg module focuses on proper integration of various external editor libraries and it's not our intention to write yet another new editor library. We have therefore setup clear rules and requirements for supporting a new editor library, which TwoD already linked to.

Clearly, there are several other attempts and projects with regard to code editing, and ideally, I'd recommend you to join efforts with them. However, if that is not an option, then we still need a proper "CodeEditor" project, which hopefully leads to sufficient developer and user interest so that it is worth including and maintaining support for that library in Wysiwyg, as this eats a lot of time and energy, and may even hold off releases. You could look into hosted systems like github or Launchpad for that, but make sure they support proper release management but also ticket/issue tracking, so users of the library can actually report bugs and help to improve it.

In the end, it is impossible for us to support integration of libraries that do not have their own, dedicated project space. We regularly have to forward people to library vendors for bug reports and feature requests that are unrelated to integrating with Drupal.

Marking won't fix for now. I'll add a pointer to this explanation to the requirements page. Feel free to re-open this issue if you disagree.

The EditArea Source Code Editor http://www.cdolivet.com/index.php?page=editArea works perfectly with Drupal WYSIWYG. You just have to write a simple wrapper .inc file. The Editor supports, among others, PHP, CSS, Javascript, Python, HTML, XML, VB, C, CPP, SQL, Pascal, Basic, Brainf*ck. With some more effort you can also achieve a flexible node/language dependant integration with Better Input Formats.
Attached is an example for a textarea .inc file.

And with the JS file

Thanks for taking the time to report this issue.

However, marking as duplicate of #412148: Add editor: EditArea. You can follow up on that issue to track its status instead. If any information from this issue is missing in the other issue, please make sure you provide it over there.