realtime updating (Re: ANN: peppy-0.7.0 "Kibbles 'n' Snouts": dogfooding release!)

4 views
Skip to first unread message

Stani's Python Editor

unread,
Oct 24, 2007, 6:15:03 PM10/24/07
to pyx...@googlegroups.com
Rob McMullen schreef:
> * Integrated Stani' fold explorer as a replacement for custom
> class browsers. It doesn't update itself in response to your typing,
> so there's plenty of work to do, but at least it shows what's possible
> without knowing anything about the syntax of the language. I suspect
> major modes will start from this information and then do a little
> additional scanning to fully populate the class browser
Hi Rob,
I had hoped you announced your new release of peppy on this list like
you did on wxpython. As you didn't, I felt free to quote you from there.
(I still think it would be good to do so. We are IDE/editor junkies here
anyway.)
I have been thinking about improving real time updating of the fold
explorer. (I have a solution in SPE, but probably this one will be
better.) The real time update requires a diff function between the two
trees. What is the most costly is probably adding and removing nodes to
a tree. Second is the renaming of the nodes. So the best would be to
have an algorythm which first updates the hierarchy and which afterwards
renames the necessary nodes.
The best solution I can think of now is a script which can translate the
tree to a plain text file in which each line represents a node. With the
diff module from the standard library the difference can be defined.
This would work for any kind of explorer. This should also work for
lists (such as todo, index, ...).
These are my ideas so far about this topic.
Stani

Rob McMullen

unread,
Oct 24, 2007, 7:22:56 PM10/24/07
to pyx...@googlegroups.com
On 10/24/07, Stani's Python Editor <spe.st...@gmail.com> wrote:
> Rob McMullen schreef:
> > * Integrated Stani' fold explorer as a replacement for custom
> > class browsers. It doesn't update itself in response to your typing,
> > so there's plenty of work to do, but at least it shows what's possible
> > without knowing anything about the syntax of the language. I suspect
> > major modes will start from this information and then do a little
> > additional scanning to fully populate the class browser
> Hi Rob,
> I had hoped you announced your new release of peppy on this list like
> you did on wxpython. As you didn't, I felt free to quote you from there.
> (I still think it would be good to do so. We are IDE/editor junkies here
> anyway.)

Indeed I didn't, and I accept the admonishment. :) I do like posting
stuff here, because it generates good discussions, so I'll add
"posting to pyxides" to my list of release tasks along with wxPython
and freshmeat.

> I have been thinking about improving real time updating of the fold
> explorer.

I've been thinking about this, too, as it's becoming obvious that the
tree is really out of date when you edit a file for a few hours.

> (I have a solution in SPE, but probably this one will be
> better.) The real time update requires a diff function between the two
> trees.

I've looked at your SPE realtime tree, but don't remember the details.
Do you do this tree -> text -> diff -> rebuild tree approach?
Whatever you do, it seems fast.

I wonder if it would be cheap enough to directly insert nodes in the
tree? We know where the user is editing, so if we keep a record of
the corresponding text position of each node in the tree, we could
narrow down what needs to be inserted in the tree. I'm assuming the
graphical changes to the wx.TreeCtrl would be the expensive part of
updating the tree -- the nodes that don't change could be updated for
the new line numbers without removing and inserting new TreeItems.

Just thinking out loud here, but it seems to me that we can use our
knowledge about the tree to our advantage somehow. A depth-first
order of the tree yields a list of nodes whose positions in the
document are monotonically increasing, so once we know where the user
is editing, we can eliminate nodes above that for updating. Nodes
below that point... I suppose we are limited by what scintilla
provides us, and its fold stuff isn't linked to our node structure.
So, hmmm, we may have to parse the fold info from that point to the
end...

Hmm. Maybe I'm optimizing too early, as is my tendency. I'm
interested to hear ideas, because this is an important part of the
fold explorer.

Rob

PS: Here is the 0.7.0 announcement if you missed it on wxPython-users.
Note that in the intervening time, I'd added fill-paragraph and a
font selection dialog, and spaces are now OK in the pathname for
running scripts. Current release is 0.7.0.2.

-----

New release of peppy, my attempt to kick the XEmacs habit. I'm
dogfooding now, and having two weeks of editing itself with itself,
I'm happy with its stability.

http://www.flipturn.org/peppy

The feature that really made it comfortable to switch from XEmacs was,
interestingly, M-x find-file, which uses the minibuffer, tab
completion, and some modifications to the textctrl_autocomplete
control to load files. Tab also scrolls through the list of available
choices.

The thing I miss the most is M-x fill-paragraph. If anyone's got a
good algorithm for that, I'm happy to include it. :)

Still working on features from sources like Robin's blog and comments,
and other requests. New features include:

* M-x processing -- all actions are available through named
equivalents. Try M-X <tab> to get the list of currently available
actions. (M-X is equivalent to Alt-X for people not familiar to
emacs.) Emacs style lower-case-with-dash aliases are available for
most commands

* Updated STC styling from Editra (www.editra.org) -- wrote an adapter
around Editra's styling dialog and am now using all the lexer and
style information from that project. Cody Precord has gone to a lot
of work to create a mapping of scintilla styling information to a
common style sheet specification. All related syntactic entities are
styled in the same manner regardless of language. Make a change in
the comment color, for instance, and it is reflected in all languages.
Cody's got support for over 40 of scintilla's language lexers, and
I'm going to be tracking his progress from now on. He's done too much
good work for me to reinvent that wheel.

* Thanks to the suggestion of Peter Damoc, you can run scripts from
within the editor, capturing the standard out/error to a logging minor
mode window. You can also run multiple scripts at the same time.

* Integrated Stani Michiels' fold explorer as a replacement for custom


class browsers. It doesn't update itself in response to your typing,
so there's plenty of work to do, but at least it shows what's possible
without knowing anything about the syntax of the language. I suspect
major modes will start from this information and then do a little
additional scanning to fully populate the class browser

* Session saving plugin that can save and load the buffers shown in
all the top level windows.

* Created a tutorial plugin (in peppy/plugins/tutorial_plugin.py) that
demonstrates how to add new actions and minor modes. I'm still
debating an architectural change to major modes that has kept me from
writing up a full tutorial on creating a major mode, but you can look
at peppy/plugins/makefile_mode.py for a simple example or
peppy/plugins/python_mode.py for a non-trivial example.

* Still no towers of hanoi, but I did add hangman from the wxPython
samples -- it uses the current buffer as the source for its words.


Lots of work still to do. I also find a buffer list mode very useful,
so that will be coming soon. M-x describe-* would be nice. Context
menus. Menus on notebook tabs to close tabs, open a new tab, show
related files, ...

I'm also in the market for good reindent code. The idea is that each
major mode will provide its own implementation of reindent, electric
return, etc. or fall back to the superclass implementation. For my
python mode my current code tries to handle the complicated cases
rather than just indenting to the previous line, but ends up getting
confused at a lot of things emacs gets right.

Feedback welcome! After closing off my trac ticket creationg because
of huge amounts of trac spam, I'm trying to see if simple math
problems are enough to keep the spambots away. Anonymous ticket
creation at http://trac.flipturn.org is again available.

Reply all
Reply to author
Forward
0 new messages