wxForty-Two

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...>

You might have just narrowed it down to an emacs clone with the list of specific features. We all know vim is just as capable an editor so why not try vims way

(That is a very big smiley and I’m ducking under my fire-proof desk).

- Paddy.

I don’t understand; why not continue to use Emacs? You list a number of Emacs features your new editor must have, but the only complaint you mention is “its 25-year-old nearly dead technology” — an insult the millions-year-old technology in my nearly dead head finds quaint.

A new editor would enable me to not have to struggle with elisp any more and switch to Python instead. Also better integration with platform standards (look ‘n feel, default color schemes, file system access, OS services, etc.) by default, out of the box, would be real nice, especially on Mac where using Emacs feels like repeatedly stubbing my toe every other step.

One more comment, then I’ll shut up — otherwise I might sound too religious.

Pymacs allows you to use Python to extend Emacs.

For Emacs on the Mac, try Aquamacs. It might be closer to what you want — it’s got things like standard OS X file dialogs, easy access to the Services menu, etc.

Good luck with your quest. Many have preceded you, and many will follow.

Yep. I’ve looked at both of those. Pymacs felt like too much of a kludge, but maybe it has gotten better since then. I should take another look. Aquamacs is nice but it is close enough to the original that when something doesn’t quite work the same the frustration level is much higher than it would have been if I had been using something totally different. Thanks for the response though.

I’m just writing to totally second Robin’s comment here, and to add just a touch.

First of all, I’m in exactly the same position — I’ve only been using Emacs (actually Xemacs) for 15 years, but the same principles apply:

I’ve never actually like Emacs, but I have always loved that it has an excellent mode for EVERY kind of text file I’ve ever had to edit — sure, the obvious ones like C/C++, html, but also LaTeX, BibTex, Matlab, Fortran, etc. These modes are often the best version out there on any editor (the python mode is the best I’ve seen).

The reason that (X)emacs has so many very nice modes is that the modes are written not by the core emacs developers, but by the users of the language at hand (I think Guido van Rossum wrote the first python mode, for instance). So I’m going to add a key feature:

* Easy to write and improve new major modes.

And a couple more, that (X)emacs doesn’t support well:

* good “soft wrap” of text — that is, the text wraps on screen but no newlines are added to the file.

* good support for multiple styles of newline characters — even mixed styles. The python “universal” file ‘U’ flag works great here.

Oh, and my thoughts on why not just keep using Xemacs. As I’ve said, I never really liked it all that much — the keystrokes are weird, etc. So, key for me is that I want an editor that is the same on all three platforms I use (Linux, OS-X, Windows), and that also integrates well with the system — visually, native file dialogs, and common keystrokes that match everything else: ctrl+X,ctrl+C, ctrl+V for cut,copy paste, for instance. I spend half my life in my text editor, but the other half in other apps: Thunderbird, etc — keeping two sets of keystrokes in my head in not productive. So, another item:

* Full Customization of key bindings — some folks will want their old emacs binding, some will want ones that mess modern UI guidelines.

-Chris

I added a few items to Robin’s message on that list, so I’ll piggyback them here as well:

* Emacs provides a “buffer list mode”, showing all the current buffers. It makes it easy to browse the list, mark some of the buffers for deletion, etc. Particularly useful when you’ve been doing edits and searches in many files of a project, and your popup list is getting just too long.

* A help mode that lets you type a keystroke or command name and get a description of what it does (in a Help Mode buffer, of course). (If you type the name, it’ll show the keys bound to it; if you type a key, it’ll show you the command name.)

* Regex search: I use it maybe 1/3 of the time.

* A directory edit mode. I use this mode mostly to support incremental multi-file search through a directory hierarchy of source code. Since I’m maintaining a mixed set of VB, SQL, Python, etc., this is a very useful feature. (By incremental, I mean that it begins the search until it finds a match, then opens the file where the match occured in a buffer with the point at the match; you can look around in the buffer and edit it as usual. A single keystroke moves to the next match.)

* Look at Emacs’ point and mark concept for selection. The question it addresses is, how do you allow convenient, flexible selection of chunks of text using only the keyboard?

* When you open a file, make some changes, and undo all of them, Emacs marks the buffer “not modified” on the last undo. I’ve seen too many editors and word processors that don’t properly keep track of undone changes.

Guess that I’m the junior emacs user here; it’s been only a decade.

One powerful emacs feature I use all the time is the speedbar (M-x speedbar). This gives me a small window on the side listing all the files with the same extension in the PWD and lets me switch among the buffers (already loaded or not) with a trackball click.

I, too, prefer to use only the keyboard, but have found the trackball to be quite useful for many tasks. Accessing the speedbar is one of them.

Rich

Peppy? Ah, it seems you already know about it (thought of this post the moment I got to their page).

For those not aware:
Peppy
(ap)Proximated (x)Emacs Powered by Python.
– an XEmacs-like editor in Python. Eventually.

http://peppy.flipturn.org/