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