[wxPython-users] ANN: peppy-0.5.1, editor and software development process experiment

[Christopher Barker]

Rob McMullen wrote:
> I'm developing this text editor in an attempt to provide an
> example of the modern, iterative software development process and the
> artifacts used to document the process.
> 
> The editor peppy is the main artifact of the process -- 

First response: AARRGG!!! not Another wxPython based editor!

But then --

> it's designed
> to work like XEmacs, with multiple top level frames that seemed to be
> the one feature that other editors or IDEs didn't allow.

Yes, yes yes!! this is key! I have no idea how anyone else is productive 
without being able to put different documents in different frames -- 
really, I don't.

Indeed, When Stani started SPE, he was struggling with MDI or tabs, 
or... and I tried to make my case for multiple top-level frames -- I failed.

> It uses the
> AUI toolkit for the internal frame management, so there are lots of
> configuration possibilities that I've yet to explore.

This is cool too. I've done a bit with Eclipse, and do like the idea of 
"perspectives" -- different way to arrange the components for different 
tasks. As a simple example, in hard-core software development mode, I 
may well want to have tree-view of the file, an object browser, etc, but 
at other times, I just want to edit a file. Period. Of course, Eclipse 
doesn't let you just edit a file...

> Peppy already has the concepts of major modes and minor modes of
> emacs, and you can switch among them using the same buffer.

Very nice also -- this is key to Emac's success.

> I also used
> the adapter pattern to wrap several plugins from Josiah Carlson's PyPE
> editor (without changing any of the borrowed code) so I can leverage
> his GPL'd work.  That'll be one of my goals going forward -- try to
> use existing code from other GPL editors as much as possible.

Also good, so you're not totally starting from scratch. Maybe this can 
be the starter framework for Stani's "One wxPython IDE"

> Anyway, I've been overly verbose at the website:
> http://www.flipturn.org/peppy but I'm not sure how coherent it is,

It's pretty coherent.

 > so
> I'm interested in feedback both about the process documentation that
> I've written, and the peppy code and its usability.  I've got a Trac
> instance running, so if you have any bug reports/enhancement
> ideas/improvements, I'd be happy to hear them there or via email.

Maybe it's because I'm a long time Xemacs user also, but I really like 
your design. I've been trying to get away from Xemacs for years, but 
haven't yet. My reasons are similar to yours, but there are a few more, 
that influence what I'm looking for.

Why I want to leave Xemacs:

1) I work on 3 platforms regularly. While you can run XEmacs on Windows 
and OS-X, it just doesn't feel right there.

2) I use a lot of other software too, and most of it has common 
functionality like cut&paste, etc -- it's really confusing that my 
editor has different conventions for this stuff than everything else -- 
at least the basics should follow what has become the standard (though I 
really wish OS-X would use <control>, rather than <command>!)

3) I'm really not interested in learning elisp....and I'd like to be 
able to customize in Python.

4) It STILL doesn't have a decent "soft wrap"

What I'm really going to miss, if I can't find it in a new editor. (and 
what's kept me from switching so far...

1) (x)Emacs has a mode for EVERYTHING I ever need to edit - Fortran, 
LaTeX, html, Python, matlab, BibTex, C, C++, etc, etc.. And the modes 
are very good. emacs Python mode is the best I've seen
   -- The way it accomplishes this is:
      a) Modes can be written in elisp, by anyone -- most of the good 
ones were donated by others, not the core developers.
      b) It's designed to be general purpose an extensible from the 
beginning.
      c) the concept of major and minor modes is very powerful.

2) Multiple top-level frames -- and tabbing in one frame -- key!

3) Multiple views of the same buffer.

4) Easy extensibility -- I've only done a tiny, but but it's nice to be 
able to add a little function, remap keys, etc. I'd do a lot more if I 
could do it in Python.

5) Lots of little features -- rectangular selection, M-space replaces n 
whitespace characters with one, etc, etc. If I can write these myself, 
I'll be happy!

One comment/question:
 > configurable key bindings with emacs-like multi-key bindings

There is a real power to the multi-key bindings, but I'm concerned how 
they can mesh with the desire to have my editor work like other software 
for the common stuff. For instance, ctrl+X, C,V for cut, copy and paste. 
  It's nice that the multi-key approach gives a clear way to have 
mode-specific bindings that don't override the global ones:

ctrl-X whatever -- global
ctrl-C whatever -- mode-specific

But ctrl-C is taken by copy already, so I wonder...

Regarding my first point -- I really don't think it would be that hard 
to adapt one of the other good wxPython editors -- SPE, Ulipad, 
DrPython, PyPE, to have multiple top-level; windows, better mode 
support, etc., so ti's a bit of a shame to see Yet Another Editor. 
Couldn't you apply Modern Software Development to a re-write/ upgrade of 
a legacy project?

Oh well -- it does look very promising, I'll be checking it out!

-Chris











-- 
Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/OR&R            (206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115       (206) 526-6317   main reception

Chris.Barker at noaa.gov