flipturn.org - stuff. things. other stuff.
dvorak | pantera | hacks

Proposal
In Royce's terms, this is the Business Case.

Background and Motivation

What is the setting and history behind this project?

I'm a long-time XEmacs user who'd like an editor that is easier to modify. See the vision document for more information.

The initial target audience for peppy is the set of developers who use XEmacs or Emacs, but are looking for a replacement that can be extended in Python. A smaller set of potential users might include those who like a Python editor or those who want to easily extend a Python editor to handle new classes of files.

What is the problem to be addressed?

XEmacs uses elisp to extend it; I want an XEmacs workalike that is extensible in Python. See the vision document.

What are some current approaches to the problem?

Why is this problem worth solving or worth solving better?

XEmacs is tied to elisp, so that's out (duh). I like to have an editor and a web browser available on the screen at the same time, and all the current python editors (SPE, PyPE, and UliPad) are pretty tied to the single top level window model. Looking through the source code trees of each, it doesn't look easy to extend them to support multiple top level windows.

SPE

SPE does have an MDI mode, but suffers from the MDI defect which is that all the little editor windows are constrained within a big window. I like to have an editor and a web browser available on the screen at the same time so I can compare things side-by-side. SPE has a bunch of great features, like UML, the multi-file find and the great stuff available in the sidebar, so I'll be using it as inspiration. It is, however, hard to extend to other types of files. The assumption was to be a great Python editor, and in so doing didn't encapsulate the language dependent actions in classes.

PyPE

PyPE has some great stuff, too, including a nice Python shell, a great find-as-you-type feature, and nice "electric" automatic indent features like XEmacs. Also, PyPE does have the ability to edit multiple types of files, but not in an object oriented way -- peppy will encapsulate major mode support in plugins. There are switches throughout the code which would take a big rewrite to fix. With the limitation that there's only one top level window, I didn't feel like forking off the editor because I thought it would be too much work. I will borrow liberally, however. Also, the author wrote a nice proof of concept of multi-stage keybindings that I modified.

UliPad

UliPad appears to be more compartmentalized, but it virtually all the documentation is in a language I can't understand (Chinese). On the surface, UliPad might be the most likely candidate for modification, but the source code is very sparsely documented, which doesn't make it fun to try and learn. peppy is a spare-time project for me, and it needs to be fun for me to work on it.

peppy

So, I'm starting from scratch, but I will probably borrow heavily from all of the above projects when I get a chance. They are all licensed under the GPL, as is peppy, so it is easy to share code.

How will this product be better than previous approaches?

  • It will be based on Python, not elisp
  • It will be modularized, so it's easy to add support for new languages
  • It will be well documented and commented, so it's easy for others to learn
  • It will have these nice project management documents

Where is there more information on this problem?

You mean, besides this? :)

Goal

What is the goal of this project?

The overarching goal is to produce a publically-available set of artifacts related to the modern software process. In order to do that, a software product must be produced. This product is a text editor and framework called peppy that will have an XEmacs-like feel with multiple editing frames and the ability to extend the editor using Python instead of emacs lisp.

What are the defining features and benefits of this product?

As noted above, it will be based on Python and wxPython, be extensible, be well documented, and be featureful.

Where are other documents that further explain the goal of this project?

The overview and the vision document.

Scope

The scope of the program is going to be bounded by the ability to load, edit, and save files of various types. Anything not related to file editing (such as the kitchen sink approach of Emacs - reading mail, reading news, etc.) or the documentation of the system itself is going to be a very low priority.

Deliverables

  • Source code
  • Documentation
    • User's guide
    • Developer's guide
  • Tutorial
    • Sample plugins

Risks and Rewards

What are the main risks of this project?

  • I'll get bored with this and won't finish it.

What are the main rewards if this project succeeds?

  • A cool editor that will replace my use of XEmacs
  • A reference that I can use again when developing new projects