On 10/24/07, Stani's Python Editor <[EMAIL PROTECTED]> 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.
