Re: [Texmacs-dev] Re: [TeXmacs] ANNOUNCE: texmacs-fedit plug-in

[Sam Liddicott]

On 19/10/10 17:33, Joris van der Hoeven wrote:

On Mon, Oct 18, 2010 at 09:09:07AM +0100, Sam Liddicott wrote:

As I said before, the main problem I see with literate programming is
the fact that you have the choice between two evils:

 1) Force all developers to use the same literate programming tool:
    the TeXmacs documents become the actual source code.

I'm hoping tmml will help here; a docbook <-> tmml converter will go  
someway to avoid the problem - not that people will want to use docbook,  
but it gives them a choice as well as a way out.

This does not really address the issue: docbook is nice,
but many developers will want to edit the ASCII source code.

Yes. I was thinking of tick-box acceptance, but it's not a priority; but .tm files will be a harder sell. Folk can accept xml for what it is, but .tm format will raise obstacles.

 2) Clobber the native ASCII source code with special comments which
    contain directives for the literate programming tool.

I'm planning to do this with a separate index file the relates key  
points in the generated source, to the document; to act as a mediator  
for a diff so that it can be shown which parts of the document need  
updating so as to be able to generate the modified source.

Yes, I also plan to use indexing for this kind of thing,
but you still will have to clobber the ASCII source code with IDs.

Could you explain a little more - I don't see that it would be needed. Correlation between existing symbols in the generated code ought to be enough.

So, I think TeXmacs will need to produce a text file or a collection  
of text files that are easily readable by a human, and so that edits  
to them can be brought back to the original document by TeXmacs.

This bringing-back often involves re-factoring as a modified segment of  
code may be an emitted meta-chunk that is emitted in many parts of the  
project.

Yes, this bringing-back is *the* main problem on which one has to think hard.

I know the python guys (pydoc?) have done some work on that.

I closer problem is that of supporting multiple collaborators all of  
which use texmacs - how easy is it for texmacs to support multiple  
collaborators at the same time?

What is the problem?

Resolving conflicts in .tm documents by hand, by people who didn't want to accept .tm as a format in the first place.

One light problem is automatic label name generation. If a label near  
the front is removed and the document "update all" then label  
re-numbering occurs causing a large diff for such a small change, and it  
can be dreadful to merge git branches in such a case.

This is a minor issue, which is mostly due to your current way of
doing things. Notice also that you may wish to set the save-aux variable
to false in your preamble, as for the tmdoc style.

Thank-you for that great tip!

I've decided while reviewing it tonight to pretty much halt work on the newfangle awk script. It works, and has been hacked to work for text export of .tm files - so it's sufficient.

I'll now start work on the native texmacs untangler.

If you've got any tips on resolving forward declarations (getting nodes from further on in the document) it'd be helpful. The texmacs macros are good for assembling pieces as the document "progresses" - that is to say I like the model better than navigating a document tree - but makes forward references hard.

Sam

--