Rev 1775 contains a start on the grand rst round-tripping project. This "start" serves mostly to show the problems that remain.
What I did: - Added rstScanner class and related machinery to leoImport.py. - Added a script in test.leo that calls this scanner. - Made Leo aware that .rst and .rest are file extensions associated with rST. ".." is now known as the official comment delims for rST. - Added two unit tests to unitTest.leo for rst imports. The first passes, the second fails. Problems remaining: - The unit test fails because indented rst sections aren't handled adequately, so round-tripping fails. - The importer simply copies the underlining into the imported file. This isn't precisely wrong, but it won't play well with @rst tree. In such trees, the rst3 plugin generates the underlining of sections automatically. - At present there are no other mechanisms that would allow Leo to remember the underlining in effect in the original rst file, or the indentation in effect in the original. Discussion The parsing of the original file isn't hard. As usual in leoImport.py, that is done by overriding startsHelper. The code is neither exceptionally pretty, nor exceptionally ugly. The present code should (but does not) create "indented" nodes for rST sections. That is, the importer should change the indentation level of a node if a section is indented relative to its predecessor or successor. This isn't rocket science, but it will involve overriding the scan method of the base importer class. The importer should remove the explicit underlining from the imported code, and remember, somehow, what underlining was used. Perhaps a single @underlining directive would remember the association of indentation levels with underlining characters. Details a bit hazy. There is a question of whether the importer should import the rST file into an @rst tree, in such a way that writing that tree (with Leo's write command, or with the rst plugin) would faithfully recreate the original file. The problem with using Leo's write command is that the write code knows nothing, at present, about rST. I'd rather use the rst3 plugin, but that opens up other problems, namely that round- tripping would become substantially harder for the user. My impression is that today's work is not too surprising. Kent and I have discussed most (all?) of these issues previously. Although the solutions are not here yet, perhaps today's work has clarified the problems. Kent, please feel free to jump in with your own observations. I haven't studied your rst-related code in detail, though I did import rst2leo for the purposes of study. Your approach creates objects that describe the rST input, and that has advantages...Maybe the only advantage of using leoImport.py code is that it shows that creating Leo trees is easy, given the base importer classes. But we knew that :-) Edward --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "leo-editor" group. To post to this group, send email to leo-editor@googlegroups.com To unsubscribe from this group, send email to leo-editor+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/leo-editor?hl=en -~----------~----~----~----~------~----~------~--~---
