On Sunday, July 27, 2014 8:58:40 AM UTC-5, Edward K. Ream wrote: > > On Sat, Jul 26, 2014 at 11:19 AM, 'Terry Brown' via leo-editor > <[email protected]> wrote: > > > Having said all that, there are writer modules where needed, so, best > > of both worlds :-) > > I think so, but this is a tricky area, so we'll have to see. >
It turns out that the simplest, most useful things to do are following: 1. There will be no readers, just importers. Leo's import code is now *fully* driven by tables created at startup using the data in the importers_dict dictionary in each .py file in leo/plugins/importers. The basescanner.py file has no such dict because it only defines the BaseScanner class used by all the other importers. 2. For now, only the existing writers are needed. **Important**: There are many more importers than writers because each importer must parse the incoming text. In contrast, we only need writers for languages that define their own outline structures: we can use the "default" @auto *write* code for all other language, because the default @auto write code needs to know only the language delims in effect for the language. In short, for now and for the foreseeable future, the importers and writers will support just @auto. Limiting importers/writers plugins to @auto greatly simplifies the task of supporting the plugins. In particular, only at.writeOneAtAutoNode needs to "dispatch" writers based on the various flavors of @auto that it is trying to write. Crucially, writer plugins can be blissfully *unaware* of all the horribly complex "setup" and "teardown" code in at.writeOneAtAutoNode. Furthermore, writers just call to at.os and at.nl! (The setup code inits the file-like object used by these two methods.) It seems we have stumbled upon an amazingly simple interface for writers... In principle, one could imaging replacing *all* of Leo's @<file> write code in leoAtFile.py by plugins, but that would *hugely* complicate each writer's job, without accomplishing much. How likely is it that a user will want (or be able!) to revise Leo's write code for @file, @shadow, @nosent etc.? Even if we wanted this "flexibility", the chance of going horribly wrong would be great. If I were designing this code from scratch, I might be tempted to go this route, but not now. I am far from confident that I could refactor the code without introducing subtle time-bombs in the read/write code. Keeping the write code *exactly* as it is (in its effect) is much more important than making the code look cleaner. This is so important. Understand? Edward P.S. This post will be pre-writing for readme.txt and howto.txt files to be placed in the plugins/importers and plugins/writers folders. The howto.txt files will explain in detail how to create new importers and writers. EKR -- You received this message because you are subscribed to the Google Groups "leo-editor" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/leo-editor. For more options, visit https://groups.google.com/d/optout.
