DevelopmentOverview - robmcmullen/peppy GitHub Wiki
Peppy is designed around the emacs idea of major modes and minor modes, and further extends this with global plugins. In writing the editor, I also borrowed quite a lot from emacs terminology, including frames and buffers, the minibuffer concept, and the keyboard bindings.
I did not borrow emacs lisp, however; that being the primary reason for me wanting to move away from my editor of over 10 years, XEmacs.
My goal for writing the code is to be as simple as possible (but no simpler), to paraphrase Einstein. Someone other than me will be the judge of that, but I'm willing to sacrifice speed or optimization for readability. While the code is somewhat complex at first glance, I hope that after reading a bit about the organization, it will make more sense than some other codes did to me. My hope is that it seems complex simply because there's a lot of it, not because there's a lot of interdependencies.
The raison d'etre of this project is the software development process, which, as it applies to the coding, means that I need to write a lot of documentation. I'm not always good at keeping up with that as I go, so this is a challenge for me to keep the docs up to date with the code.
My goal for extensibility is to avoid problems resulting from high coupling. I wanted it to be easy to extend the editor with new major and minor modes, but in a way that has low coupling. Many other editors are extensible, but require changes in lots of places, requiring you delve deeply into the internal structure of the editor. For example, to add a C++ source code editing module, I don't want to have to parse every source file looking for if/then or case statements and adding a new case for C++. I want to have a single file that encapsulates all the C++ functionality, independent of other major modes.
As much fun as it might be writing your own code, it's useless trying to reinvent every wheel. Why throw away the time that someone else has spent coding and debugging, just because they didn't design it exactly how you would have? Sometimes, the code is so orthogonal that you can't reuse it, but other times an application of the adapter pattern can make it work. As an example, I found that Editra already supported scintilla language lexers for over 40 languages, and rather than come up with a competing scheme decided to adapt the Editra system for my use. While I may have designed the system differently had I started from scratch, it was adaptable to my needs, and works. I adapted it in about 8 hours of work, compared to probably hundreds that the author Cody Precord spend developing and testing.
There is one application object, PeppyApp (defined in main.py), that extends from wx.App. It manages the loading and saving of the configuration file, and loading plugins. It is also available from frames as frame.app.
As in emacs parlance, a frame is a window. There can be many frames open simultaneously -- unlike most python IDEs out there currently, this was a big factor in me writing my own editor. I hated being constrained to a single window, and all the current python editors were designed from that point of view. It was too hard to try to modify an existing editor to work with multiple top-level frames, so I wrote my own.
A buffer represents a data source of some sort, typically from a file or read from a URL. There is only one buffer object for each file in memory, but there may be many views of the same data.
A major mode is a view of a buffer, and is where the user interacts with the representation of the data: editing text, changing hex values, drawing pixels, etc.
Minor modes are enhancements to a major mode. They augment the major mode by providing more functionality, either by providing new user interface elements or by automating tasks behind the scenes. For instance, the function list minor mode shows a hierarchical list of classes and methods, and clicking on the name of a function moves the view of the source file to that line.
Sidebars are enhancements to peppy that exist independent of the current major mode. Their user interface elements remain displayed even when switching major modes; in fact, sidebars should not even be aware of the current major mode.
The menubar is dynamic and updates depending on the major and minor modes of the file currently being edited. Changing the major mode will change the menubar to show only the menu items related to that mode.
Like the menubar, the toolbar is dynamic and only shows items related to the current file. It is an AUI element, so is repositionable.
Peppy has a configuration system based on the class hierarchy of the source code. User settings are specifiable in the ~/.peppy/preferences.cfg file, which is a windows INI style file. Section names correspond to the class name in the source code, and searches for unspecified values proceed up through the class hierarchy. So, for instance, if a value is set for word wrapping on the Python major mode, the Python major mode will stop looking right there and pick up that value. But, if word wrapping is not set in the Python section of the config file, it will start looking if it's set in the next superclass; in this case the Fundamental mode. If found, it will use that value. If not, it will continue looking until it gets to object, upon which time it will return a value of None.