On Sun, Mar 28, 2021 at 10:46 AM [email protected] <[email protected]>
wrote:

My Sphinx documents use a Sphinx-type table of contents at the top of the
> tree,  a hierarchy of rst files, and inter-file links.  Nothing more
> complicated.  The content includes text, code snippets,  entire small
> programs, output captures formatted as plain mono-spaced text, and images.
> I don't use anything more complex, and until a few days ago  was not aware
> that you could do anything more complicated with rst3.
>
> So when you are done with the revamped rst3, I want to be able to run it
> on my tree and get Sphinx-ready output, just like you can get currently.
> If that will work, I will be happy.  If it won't, I will probably have to
> do a lot of work to be able to generate my documentation, and I won't like
> that.
>

Everything should work exactly as before when you run the "new/simplified"
rst3 command.

Presumably you are using @bool rst3_call_docutils = False, as in
LeoDocs.leo. That option creates intermediate (.html.txt) files for use by
sphinx, without calling docutils.

As of rev c0fff62
<https://github.com/leo-editor/leo-editor/commit/c0fff62fb452d83bef254cdf3ce18cbccdf956c7>,
git diff confirms that the new version of rst3 produces .html.txt files for
all `@rst` trees in LeoDocs.leo that are *binary equal* to those produced
by the legacy version of rst3. This is a major milestone.

So it looks like #1867
<https://github.com/leo-editor/leo-editor/issues/1867> is complete, except
for cleanups and documentation. However, I am going to wait to merge the
ekr-new-rst branch into devel.  Here's why:

Despite what I have been saying for a few days, a new script might be
worthwhile. This script would simulate some of the old features of the rst3
command, but in a straightforward manner.

In hindsight, the bad old features were intended to abstract or filter
nodes/text.  Well, we now have c.cloneFindByPredicate.  We can imagine an
initial filtering/gathering of nodes using c.cloneFindByPredicate, followed
by an optional additional filtering of text within nodes. Instead of
cloning, it would be easy to create c.copyFindByPredicate, to allow
unrestricted munging of filtered text without affecting the original
outline.

I have no idea how this will turn out. I am sure only that the new rst3
code will be a much better base for experimentation than the old. There is
a real possibility that sphinx, sphinx-gallery, and jinja already do
everything people will need, so before charging ahead it would be good to
study the sphinx world.

*Summary*

The ekr-new-rst branch looks to be code complete, but I won't rush to merge
it into devel.

Today's work marks the end of the "pause" in my sabbatical.  I'll take a
break for a day or two, then resume my sabbatical. Studying the sphinx
world and its relationship to rst3-oriented tasks seems like a good next
sabbatical project.

As always, I'll be happy to answer questions and fix urgent bugs during the
sabbatical.

Edward

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/leo-editor/CAMF8tS2p1xfQC%3DXQEyF17LvZXhCC8vpncVNej%2Bnuqa-VZMVb0g%40mail.gmail.com.

Reply via email to