On Tue, Mar 24, 2009 at 6:57 PM, Edward K. Ream <edream...@gmail.com> wrote:
>> Therefore, we will still >> have the possibility to move chapters around and not fiddle with the >> underlining manually. This is a big win, giving us that advantage of >> rst3 while still operating completely with @thin node. > > Not really. The rst3 plugin does a lot of cool things that can not be > represented directly in rST. Probably. That's why I was saying "*that* advantage. I'd rather see that stuff done with @thin nodes though, if possible. ;-) > As I see it, the only way to get the advantages of the rst3 plugin is to > have the rst3 plugin create external files for sphinx. As explained, that won't work with many projects. It's considered "bad form" to provide derived files in version control, and it should be easy to generate the derived files from source files. > I believe we can still use @thin files as "containers" for the @rst trees, > but what we can *not* do is use those @thin files directly. That is, we can > not simply pass those @thin files to sphinx. Instead, we must continue to > use the rst3 command to create *other* external files that *can* be passed > to sphinx. Actually, there may be a simpler way. We start using the @thin files for all of the stuff, but we simulate the "@sentinelpadding 1" directive by providing a simple python script (leo-sphinx-fixup.py) that ensures all sentinels have 1 space of padding. That "fixed up" file is what is stored in version control, and is imported to leo. The fixup script only needs to be run when a user screws up and deletes that empty line. > I think this solves all the problems: > > - We get all rst3 plugin features. > - There is no need for more "fancy" new commands. > - We can use @thin files for collaboration. > - The rst3 command can insert blank lines (as it probably does already) into > the external files sent to sphinx. It doesn't solve the collaboration problem. I'm thinking of starting to use rst for documentation at my job, and it's essential that there is just one instance of "authoritary" files, and everyone (that has the right packages installed) needs to be able to generate the pdf from those files. I just can't require installation (and more importantly, learning!) of leo, just like I can't release binaries that can't be built from the sources merely by typing "dpkg-buildpackage -rfakeroot". So basically, it's either @sentinelpadding 1 or the leo-fixup-rst-sentinels script. But using rst3 is not an option unless it supports @thin files. -- Ville M. Vainio http://tinyurl.com/vainio --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
