ANN: peppy-0.5.1, editor and software development process experiment

wxPython Users
1

I've always struggled to find good public documentation of the modern
software development process. I finally found the
http://readyset.tigris.org software engineering templates, and in
combination with a good book on the modern software process by Walker
Royce, 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 -- 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. It uses the
AUI toolkit for the internal frame management, so there are lots of
configuration possibilities that I've yet to explore.

Peppy already has the concepts of major modes and minor modes of
emacs, and you can switch among them using the same buffer. For
instance, you can look at an image with the ImageView major mode, then
switch to the HexEdit major mode to look at the bytes, and switch
back.

I've used the Trac component architecture for plugins. 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.

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

Thanks,

Rob

PS: It even has psychoanalyst (open the URL shell:eliza), but not
zippy or psychoanalyze zippy. Yet. :slight_smile:

2

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@noaa.gov

3

Christopher Barker wrote:

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

I use an emacs module that rebinds the CUA keys such that if there is a selection then ctrl-C is Copy, otherwise it goes to the mode specific keymap. IOW, when there is a selection then the standard clipboard keys are mapped to clipboard actions, otherwise they do their normal emacs thing.

Recent versions of Emacs include this module in the standard lib, I don't know if XEmacs has something similar. In Emacs you turn it on with (cua-mode).

···

--
Robin Dunn
Software Craftsman
http://wxPython.org Java give you jitters? Relax with wxPython!

4

[snip]

I've used the Trac component architecture for plugins. 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.

My goodness. I could have sworn that I wrote everything so horribly
that it was not only impossible for 3rd parties to modify, but that it
being GPLed was really only useful as an example of "what not to do".
Congratulations on managing to find a use for some of it. :smiley:

I also congratulate you on managing to get multi-window editing working.
Since you (or someone else?) posted about it, I've been thinking about
how one could make it possible, specifically how I could make such a
thing work in PyPE. I have some ideas, but they probably won't happen
for quite a while (perhaps PyPE 3 or 4), if at all.

One of the things that has slowed me down (and what slowed me down when
initially working on PyPE 2.0 a couple years back) is saving and
restoring the edit control state when moving documents between editors.
PyPE handles most everything with regards to state saving and restoring
for a document (except for styling and lexers), specifically
PythonSTC.GetSaveState and SetSaveState . You may want to ignore
folding, as for large documents, getting and setting folding state can
be slow (and incorrect, PyPE doesn't do it quite right).

Good luck!
- Josiah

···

"Rob McMullen" <rob.mcmullen@gmail.com> wrote:

5

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

"I know the world doesn't need another editor" was going to be the
opening line in my announcement, but I didn't want to turn people off
immediately. They'd have to wait at least one paragraph. :slight_smile:

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.

That really was the main point for me as well. Maybe I could have
adjusted to a single frame had I really given it a shot, but there's
so many times when it is useful to compare documents side by side, or
to have one frame on one virtual desktop and another frame on another
desktop, or just the freedom to move the windows around on the
screen...

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

I was really interested in pyxides when Stani proposed it last year; I
was up to my neck in grad school and my full-time job and had no spare
time. Maybe peppy can become something like that -- I did go into it
thinking that I'd be designing a framework that would be easily
expandable.

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.

I agree -- wxPython buys us the feel of the native apps.

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>!)

I am so tied to XEmacs that I always forget and hit C-X C-S to save in
windows apps, and am just lucky that I don't have a region selected.
But the keybindings in peppy will be customizable. I'm interested in
that cua-mode, which I hadn't heard of before. I'll keep that in mind
as I continue with the keybinding customization.

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

Amen, brother!

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

Which we get for free in Scintilla.

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.

That's why I designed peppy the way I did -- major modes and minor
modes as Trac components that are registered simply by importing the
module. I would hope that when I get a stable enough architecture,
people would be able to easily contribute major modes for their
favorite language. For example, I don't often admit that I know
Fortran, and while I could write the Fortran major mode, it certainly
wouldn't be as good as the one written by someone who uses Fortran
regularly.

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!

I'm with ya. I have this little list of features that I use regularly
that I'm trying to get into peppy 0.6, and then that will be enough to
try to use peppy as my regular editor and see how it works on a daily
basis. Rectangular selection, fill-paragraph-or-region, regex
search/replace...

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?

I understand what you're saying, and I expected questions about this.
The problem with adapting other editors, and believe me I spent quite
a lot of time looking at those you mentioned (even Eric3 of PyQT), was
that they weren't designed to be general frameworks. It looked like
they all evolved from the goal of being good python editors, and
extended as the feature requests came in. They all have a bunch of
good features, but the two assumptions they all made were: each file
has only one view; and one top level window. Those are two
fundamental design decisions that affect everything else about the
architecture. I'm sure I could have picked one and gone for it, but I
found that the XEmacs features I wanted to implement would require
many, many changes. Not nearly as easy as starting again with my
architecture in mind.

Also, as the AUI toolkit became part of wxPython, I really became
interested in the possibilities. No other editor has used AUI yet. I
had written my own notebook/tabbed frame/minor mode management system,
but happily threw that away and let AUI handle the perspectives. One
less responsibility for me to code.

Plus, as much as reinventing the wheel is to some extent wasteful,
it's also fun because you don't have to code around assumptions that
don't fit your purposes. As a spare time project, I needed this to be
fun in order to continue with it.

And, I'm not really intending to reinvent the whole wheel -- the hub
at most, and I'll borrow the spokes and tire. :slight_smile:

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

Thanks for your comments!

Rob

···

On 2/12/07, Christopher Barker <Chris.Barker@noaa.gov> wrote:

6

My goodness. I could have sworn that I wrote everything so horribly
that it was not only impossible for 3rd parties to modify, but that it
being GPLed was really only useful as an example of "what not to do".
Congratulations on managing to find a use for some of it. :smiley:

:slight_smile: Actually, I found most of your plugins fairly self-contained. I
mean, there are a few global references (e.g. the _pype global), but
most of the stuff is passed in to the plugin through its init method,
so I can provide adapters for those. It took me (literally!) less
than 30 minutes to write a peppy plugin and adapter for your
filesystem browser. It took me longer to adapt the search and
replace, but I did those first and I was still trying to understand
your code. Once I understood more about it, it was very easy to
modify. I'm sure I'll be incorporating more of your stuff as I go,
and hopefully if I extend any functionality, you'll be able to plug it
back into PyPE with no changes to your code.

One of the things that has slowed me down (and what slowed me down when
initially working on PyPE 2.0 a couple years back) is saving and
restoring the edit control state when moving documents between editors.

You mean, like saving and restoring sessions? I hadn't really thought
about that much, but as I pause to check into
GetSaveState/SetSaveState I see you've also coded up a VIM settings
decoder which I'll probably borrow at some point. :slight_smile: I also hadn't
thought about code folding much, either, as I've never really used
that coming from XEmacs. I did have an idea for a minor mode that
automatically folds docstring comments so someone familiar with the
code could get more of it on screen at once.

Good luck!
- Josiah

Thanks! I'll let you know as I borrow more of your stuff. :slight_smile:

Rob

···

On 2/12/07, Josiah Carlson <jcarlson@uci.edu> wrote:

7

> My goodness. I could have sworn that I wrote everything so horribly
> that it was not only impossible for 3rd parties to modify, but that it
> being GPLed was really only useful as an example of "what not to do".
> Congratulations on managing to find a use for some of it. :smiley:

:slight_smile: Actually, I found most of your plugins fairly self-contained. I
mean, there are a few global references (e.g. the _pype global), but
most of the stuff is passed in to the plugin through its init method,
so I can provide adapters for those. It took me (literally!) less
than 30 minutes to write a peppy plugin and adapter for your
filesystem browser.

That was really only a small wrapper over the pre-existing stuff.

It took me longer to adapt the search and
replace, but I did those first and I was still trying to understand
your code. Once I understood more about it, it was very easy to
modify. I'm sure I'll be incorporating more of your stuff as I go,
and hopefully if I extend any functionality, you'll be able to plug it
back into PyPE with no changes to your code.

The search tab should also be fairly straightforward, as there really is
only one place where it opens documents, finds the "current document",
etc. The code is awful to read, use, and modify (I just about cry every
time I need to dig into it), but in the next version of PyPE, it pulls
out all of the searching into a secondary thread, which among other
things, makes the search go faster (so you may want to wait for it).

> One of the things that has slowed me down (and what slowed me down when
> initially working on PyPE 2.0 a couple years back) is saving and
> restoring the edit control state when moving documents between editors.

You mean, like saving and restoring sessions? I hadn't really thought
about that much, but as I pause to check into
GetSaveState/SetSaveState I see you've also coded up a VIM settings
decoder which I'll probably borrow at some point. :slight_smile: I also hadn't
thought about code folding much, either, as I've never really used
that coming from XEmacs. I did have an idea for a minor mode that
automatically folds docstring comments so someone familiar with the
code could get more of it on screen at once.

There's the session saving/restoring, but then there's moving documents
between different frames. Scintilla allows for a single document to
have multiple "views", so when you type a character into one view, you
see it in the other view automatically. See the MultiSash demo for an
example of this. In the (as of yet unreleased) next version of PyPE, I
use this particular feature to offer a read-only secondary view of a
document.

The reason I mentioned it is so that when you "split" the view, or
otherwise display a document on a "secondary" frame, you may consider
saving the information and handing it off to the new view so that the
user sees the portion of a document that they expect, with cursor,
folding, etc.

- Josiah

···

"Rob McMullen" <rob.mcmullen@gmail.com> wrote:

On 2/12/07, Josiah Carlson <jcarlson@uci.edu> wrote:

8

>
> It took me (literally!) less
> than 30 minutes to write a peppy plugin and adapter for your
> filesystem browser.

That was really only a small wrapper over the pre-existing stuff.

So, I wrapped a wrapper. :slight_smile: But, still, it was nice to have your code
already debugged and be able to plug it in without starting from
scratch.

The search tab should also be fairly straightforward, as there really is
only one place where it opens documents, finds the "current document",
etc.

Yep, already found it and incorporated it.

The code is awful to read, use, and modify (I just about cry every
time I need to dig into it), but in the next version of PyPE, it pulls
out all of the searching into a secondary thread, which among other
things, makes the search go faster (so you may want to wait for it).

Hopefully I'll just be able to plug it in.

There's the session saving/restoring, but then there's moving documents
between different frames. Scintilla allows for a single document to
have multiple "views", so when you type a character into one view, you
see it in the other view automatically.

The multiple view stuff is already done in my Buffer class; you just
call Buffer.createMajorMode and you get a new view. In fact, you can
even have a single file with scintilla views and non-scintilla views
(e.g. the HexEdit major mode) and changes in one view propagate to all
the others.

But, I see what you're saying about opening the second view with the
same cursor position, folding state, etc. I hadn't thought about that
yet. I may have to maintain some sort of stack of views, so that when
two views are already open and the user opens a third, it takes the
most recently used view as the cursor/folding state to clone.

Rob

···

On 2/13/07, Josiah Carlson <jcarlson@uci.edu> wrote:

"Rob McMullen" <rob.mcmullen@gmail.com> wrote:

9

Rob McMullen wrote:

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

Oh -- incremental search you HAVE to have incremental search! (and one you can use without grabbing the mouse)

HMM, this is getting pretty off-topic -- maybe there should be a wxPython editors discussion list. Did Stani set one up for his pyXides project?

I'm interested in
that cua-mode, which I hadn't heard of before.

Neither had I, and I may well give it a try on Xemacs, but I think it will be confusing -- it's really better to have the same keys mean the same thing regardless of whether something is selected or not.

I'd avoid emulating emacs key bindings -- that may be a good way to go for long-time emacs users, but speaking as one such user, I'm ready to re-train myself, IF I can find an editor that does what I need it to do. In short, I want the power of emacs, NOT the keybindings.

By the way, Are mode setting hierarchical? I'm imagining that there could be a setting that is set globally, then may or may not be overridden my a major mode, then may or may not be overridden by a minor mode.

You mean, like saving and restoring sessions?

Maybe it's just the way I work, but I have no need for that. If I shut down the editor, it's unlikely that I'll want to open it up again in the same state. I certainly want to be able to turn that feature off!

I did have an idea for a minor mode that
automatically folds docstring comments so someone familiar with the
code could get more of it on screen at once.

I like this -- or, more generally, good control over code folding. I think it's really only useful to have code folding if it's very flexible.

when you "split" the view, or
otherwise display a document on a "secondary" frame, you may consider
saving the information and handing it off to the new view so that the
user sees the portion of a document that they expect, with cursor,
folding, etc.

Maybe to start, but the whole point of different views is that they are, well, different. I can certainly imagine wanting one view folded, and the other not, or instance.

-Chris

···

On 2/12/07, Christopher Barker <Chris.Barker@noaa.gov> wrote:

--
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@noaa.gov

10

Rob, thanks for starting this. I've had something like this in the back of my mind for a long while, but never had the time and motivation to tackle it.

I am so tied to XEmacs that I always forget and hit C-X C-S to save in
windows apps, and am just lucky that I don't have a region selected.

LOL -- I resemble that remark!

I have this little list of features that I use regularly
that I'm trying to get into peppy 0.6, and then that will be enough to
try to use peppy as my regular editor and see how it works on a daily
basis. Rectangular selection, fill-paragraph-or-region, regex
search/replace...

Adding my own gotta haves, in the order they occur to me: the whole regex bit, including the ability to delimit "chunks" in the pattern and use them in replacements; dired mode, in general and specifically the part that lets me conveniently move through a set of folders/files, stopping at matches to a regex pattern (the A command); shell mode; using external tools like grep, uniq, and sort to operate on buffer contents; case switching (M-u, M-c, M-l); the ability to use newline in a search pattern and in a replacement; incremental search with full-window highlights; moving forward and backward over balanced sets of brackets (and moving up and down in nests); ediff/emerge... I imagine there's more I can't think of right now.

It sounds like I should pick up a copy of peppy soon, and maybe put one foot on it gingerly while keeping the other on emacs, then contribute to adding features to gradually "shift my weight".

This could be the start of something very nice!

···

--
Don Dwiggins
Advanced Publishing Technology

11

Rob McMullen wrote:

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

Oh -- incremental search you HAVE to have incremental search! (and one
you can use without grabbing the mouse)

I presume he picked it up from PyPE already.

HMM, this is getting pretty off-topic -- maybe there should be a
wxPython editors discussion list. Did Stani set one up for his pyXides
project?

Maybe, but the site is down.

> You mean, like saving and restoring sessions?

Maybe it's just the way I work, but I have no need for that. If I shut
down the editor, it's unlikely that I'll want to open it up again in the
same state. I certainly want to be able to turn that feature off!

It's all about use-cases. Personally, I keep my editor open 24/7 with
10-20 documents open at a time. I preserve folding, cursor location,
etc., because when I shut down the editor, it's because I want to use a
new version or because I'm restarting the computer, and I *like* to pick
up where I left off (especially on lines that read, "fix me now!").

> I did have an idea for a minor mode that
> automatically folds docstring comments so someone familiar with the
> code could get more of it on screen at once.

I like this -- or, more generally, good control over code folding. I
think it's really only useful to have code folding if it's very flexible.

There is an interesting conversation. What kinds of folding would you
find useful (beyond fold all, unfold all, ctrl/shift clicking fold
points, and perhaps, 'fold everything at x-level' - for classes, etc.).

> when you "split" the view, or
> otherwise display a document on a "secondary" frame, you may consider
> saving the information and handing it off to the new view so that the
> user sees the portion of a document that they expect, with cursor,
> folding, etc.

Maybe to start, but the whole point of different views is that they are,
well, different. I can certainly imagine wanting one view folded, and
the other not, or instance.

Different scintilla views can do *many* different things (folding,
cursors, selection, etc.).

- Josiah

···

Christopher Barker <Chris.Barker@noaa.gov> wrote:

> On 2/12/07, Christopher Barker <Chris.Barker@noaa.gov> wrote:

12

Josiah Carlson wrote:

There is an interesting conversation. What kinds of folding would you
find useful (beyond fold all, unfold all, ctrl/shift clicking fold
points, and perhaps, 'fold everything at x-level' - for classes, etc.).

I'm speaking here as a heavy user of the outliner of my favorite PIM (Ecco Pro); take a look at http://www.compusol.org/ecco/outlining.html for an introduction to its outlining capabilities.

For a Python (or other programming language) editor, some of this may not be appropriate, and other capabilities may be desirable. OTOH, Python is rather outline-based anyway, so this may be a good spec for it.

···

--
Don Dwiggins
Advanced Publishing Technology

13

The Ctrl+Shift+[1-9] keybindings (the functionality specifically) seem
interesting, though the vast majority of the 'press key combo X to
create a new node [at the same level after all children, at the same
level if there are no children, as a new child at the start of the
children, as a new child at the end of the children, etc.]' is fairly
unintuitive, especially when you can "create a child node" with the 'tab'
key in most editors.

I'm going to have to look into folding details again at some point.

- Josiah

···

Don Dwiggins <ddwiggins@advpubtech.com> wrote:

Josiah Carlson wrote:
> There is an interesting conversation. What kinds of folding would you
> find useful (beyond fold all, unfold all, ctrl/shift clicking fold
> points, and perhaps, 'fold everything at x-level' - for classes, etc.).

I'm speaking here as a heavy user of the outliner of my favorite PIM
(Ecco Pro); take a look at http://www.compusol.org/ecco/outlining.html
for an introduction to its outlining capabilities.

For a Python (or other programming language) editor, some of this may
not be appropriate, and other capabilities may be desirable. OTOH,
Python is rather outline-based anyway, so this may be a good spec for it.

14

Josiah Carlson wrote:

The Ctrl+Shift+[1-9] keybindings (the functionality specifically) seem
interesting, though the vast majority of the 'press key combo X to
create a new node [at the same level after all children, at the same
level if there are no children, as a new child at the start of the
children, as a new child at the end of the children, etc.]' is fairly
unintuitive, especially when you can "create a child node" with the 'tab'
key in most editors.

I've been working with Ecco for so long that I'm probably disqualified as a judge of what's intuitive; at this point, it's just in my fingers.

I will say that _some_ key combinations should be available to allow creating either a child node or a node at the same level or next level up, whether or not the current node has children. I also do a lot of rearranging with the Alt-arrow keys. These things shouldn't require moving your hands from the normal typing position.

···

--
Don Dwiggins
Advanced Publishing Technology

15

I'd avoid emulating emacs key bindings -- that may be a good way to go
for long-time emacs users, but speaking as one such user, I'm ready to
re-train myself, IF I can find an editor that does what I need it to do.
In short, I want the power of emacs, NOT the keybindings.

I like the emacs keybindings, so I guess the rule is to make it
configurable, which it will be. Every emacs user has their own
personal preferences, which is why emacs has worked for so well for so
long, and those of us who use it are religious about it. And, also
explains why we've never changed editors. :slight_smile:

By the way, Are mode setting hierarchical? I'm imagining that there
could be a setting that is set globally, then may or may not be
overridden my a major mode, then may or may not be overridden by a minor
mode.

Yes, they are. I couldn't find an implementation of that, so I did
end up writting my own. It's the ClassSettingsMixin in
configprefs.py, where I use the method resolution order of the class
hierarchy to set up the preference order. For example, Python mode
extends FundamentalMode, so for Python if a setting exists in the
Python prefs, that's used; otherwise it falls back to the
FundamentalMode setting. I thought sure someone would have written
something like that, but I never found one.

Rob

···

On 2/13/07, Christopher Barker <Chris.Barker@noaa.gov> wrote:

16

> Oh -- incremental search you HAVE to have incremental search! (and one
> you can use without grabbing the mouse)

I presume he picked it up from PyPE already.

Yep.

> HMM, this is getting pretty off-topic -- maybe there should be a
> wxPython editors discussion list. Did Stani set one up for his pyXides
> project?

Maybe, but the site is down.

I'll wait to hear from Stani before I think about setting one up. I
can't remember if there's a list or not. Most of what I remember was
centered on the wiki.

> > You mean, like saving and restoring sessions?
>
> Maybe it's just the way I work, but I have no need for that. If I shut
> down the editor, it's unlikely that I'll want to open it up again in the
> same state. I certainly want to be able to turn that feature off!

It's all about use-cases. Personally, I keep my editor open 24/7 with
10-20 documents open at a time. I preserve folding, cursor location,
etc., because when I shut down the editor, it's because I want to use a
new version or because I'm restarting the computer, and I *like* to pick
up where I left off (especially on lines that read, "fix me now!").

I'm like you, Chris, in that I never save and restore sessions. But,
I can see its utility for someone who works differently than me.

> > I did have an idea for a minor mode that
> > automatically folds docstring comments so someone familiar with the
> > code could get more of it on screen at once.
>
> I like this -- or, more generally, good control over code folding. I
> think it's really only useful to have code folding if it's very flexible.

There is an interesting conversation. What kinds of folding would you
find useful (beyond fold all, unfold all, ctrl/shift clicking fold
points, and perhaps, 'fold everything at x-level' - for classes, etc.).

I've never bothered with code folding, so I would be interested to
hear how others use it. It sort of hit me that the docstring-autohide
mode would be nice as I type all these epydoc comments that take a lot
of screen real-estate, but that's the first time I ever thought it
would be useful for me.

Rob

···

On 2/13/07, Josiah Carlson <jcarlson@uci.edu> wrote:

Christopher Barker <Chris.Barker@noaa.gov> wrote:

17

Rob, thanks for starting this. I've had something like this in the back
of my mind for a long while, but never had the time and motivation to
tackle it.

I figured to do the documentation for this modern process stuff, I had
to have a project that I wouldn't lose interest in, and this is the
only one that I could see retaining my interest.

> I am so tied to XEmacs that I always forget and hit C-X C-S to save in
> windows apps, and am just lucky that I don't have a region selected.

LOL -- I resemble that remark!

:slight_smile:

Adding my own gotta haves, in the order they occur to me: the whole
regex bit, including the ability to delimit "chunks" in the pattern and
use them in replacements; dired mode, in general and specifically the
part that lets me conveniently move through a set of folders/files,
stopping at matches to a regex pattern (the A command); shell mode;
using external tools like grep, uniq, and sort to operate on buffer
contents; case switching (M-u, M-c, M-l); the ability to use newline in
a search pattern and in a replacement; incremental search with
full-window highlights; moving forward and backward over balanced sets
of brackets (and moving up and down in nests); ediff/emerge... I
imagine there's more I can't think of right now.

Wow, that's a great list of stuff! The cool thing is most of that is
stuff that I don't use regularly, or at all. The search and replace
with newlines, incremental search, and ediff are things I do, but the
others aren't. This is why emacs is so great -- everyone uses it
differently. I'm trying to make peppy general enough that new modes
and commands can be added without touching the core framework code.

It sounds like I should pick up a copy of peppy soon, and maybe put one
foot on it gingerly while keeping the other on emacs, then contribute to
adding features to gradually "shift my weight".

That would be awesome, because I expect that you would be able to work
on just adding the commands or modes that you were interested in.

I don't know that the documentation and overall architecture is there
yet, but I'm working on it. If you do happen to get into the code,
comments on the architecture are welcome.

This could be the start of something very nice!

I'm hoping. :slight_smile:

Rob

···

On 2/13/07, Don Dwiggins <ddwiggins@advpubtech.com> wrote:

18

Rob McMullen wrote:

> HMM, this is getting pretty off-topic -- maybe there should be a
> wxPython editors discussion list. Did Stani set one up for his pyXides
> project?

Maybe, but the site is down.

I'll wait to hear from Stani before I think about setting one up. I
can't remember if there's a list or not. Most of what I remember was
centered on the wiki.

Hi Rob,
It looks like you've bitten the bullet! I have not yet tried peppy, but I will. The pyxides mailing list is hosted by Google, so it is not down. Activity on the mailing list has boiled down, although recently there was some curiosity:
http://groups.google.com/group/pyxides If I were you, I would announce your project there as well, it never hurts and you might get useful feedback.

The wxpython and pyxides mailing list are different. On wxPython mailing list you will find wxpython developers of course and on the other pyxides mailing list you will get feedback from all the other python IDE developers. (As far as I can see everyone is still subscribed.) In general my feeling is that nobody will quickly leave his gui toolkit, although Leo seems to move from tkinter to wxPython. wxPython is home to several IDE's such as Boa, Ulipad, DrPython, PyPe and SPE. It would still be a better idea if all this energy could be bundled. Most of the developers are probably reading your postings on this list, so do I. I hope to find some time soon to explore peppy. I've quickly read your site and I like it so far. Probably I will contact you later to give my thoughts and I would not be surprised if Limodou would do the same.

Good luck!
Stani

···

On 2/13/07, Josiah Carlson <jcarlson@uci.edu> wrote:

19

Hi Rob,
It looks like you've bitten the bullet! I have not yet tried peppy, but
I will. The pyxides mailing list is hosted by Google, so it is not down.
Activity on the mailing list has boiled down, although recently there
was some curiosity:
http://groups.google.com/group/pyxides If I were you, I would announce
your project there as well, it never hurts and you might get useful
feedback.

I will subscribe and post over there, and maybe we can continue the
discussion of emacs features that we like over on pyxides. :slight_smile:

The wxpython and pyxides mailing list are different. On wxPython mailing
list you will find wxpython developers of course and on the other
pyxides mailing list you will get feedback from all the other python IDE
developers. (As far as I can see everyone is still subscribed.) In
general my feeling is that nobody will quickly leave his gui toolkit,
although Leo seems to move from tkinter to wxPython. wxPython is home to
several IDE's such as Boa, Ulipad, DrPython, PyPe and SPE. It would
still be a better idea if all this energy could be bundled.

I agree, and I wish I would have had more time to contribute to the
original pyxides discussion when you set it up last year.

Most of the
developers are probably reading your postings on this list, so do I. I
hope to find some time soon to explore peppy. I've quickly read your
site and I like it so far. Probably I will contact you later to give my
thoughts and I would not be surprised if Limodou would do the same.

That would be great. I've certainly looked at everyone's editors, and
there are lots of excellent features in all of them. I'm initially
aiming for the emacs crowd, but hopefully it is a general enough
framework that I can continue to borrow all the cool features from all
the other editors. I'm definitely going to be looking to incorporate
your UML mode, for instance.

Looking forward to some pyxides discussions.

Rob

···

On 2/13/07, Stani's Python Editor <spe.stani.be@gmail.com> wrote: