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

[Joris van der Hoeven]

On Tue, Oct 19, 2010 at 10:39:51PM +0100, Sam Liddicott wrote:
> 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.

You can save TeXmacs under whatever format you prefer (native, tmml, scheme, 
etc.) anyway.
This seems a minor issue to me.

>>> 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.

Indexing can help to automatically maintain a correspondance between
two versions of the same code (TeXmacs version and ASCII version,
whatever you choose to be the real "source code").

However, this only works up to a certain extent: when deleting a portion of text
which contains some indexes in one version (say, a portion of ASCII source 
code),
you will be able to forward this information to the other version
(say, the corresponding TeXmacs annotated version), but it is not necessarily
clear what to do with the annotations for the deleted source code.
Maybe, there were dozens of very useful annotations, with further hyperlinks
pointing to them, for a very small piece of code; these will all become invalid.
Even worse, maybe the ASCII developer just performed a minor renaming,
which (somehow) was not cached by the indexer. Again, all annotations
will be lost. One further annoyance is that the ASCII developer is not
even aware of the existence of useful annotations, as long as no special
comments to this effect were inserted in the ASCII source code version.

One idea might be to add a further tool to the indexer:
some kind of script which the ASCII developer might run,
and which will notify the existence of any conflicts with
the TeXmacs version which could not be repaired by the indexer.
This script might be run automatically during 'make' or
before 'your-versioning-tool commit'.

On the TeXmacs side, we might have special tags which indicate
the semantics of annotations in the case when the corresponding
ASCII source code gets lost. For example, in the simplest case,
some specified piece of the TeXmacs document might be deleted.

>>> 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.

1) This situation only arises when you choose ASCII as the main version for 
source code.
2) If TeXmacs is used as an annotation tool, there is not much we can do else,
   but edit by hand those pieces of modified ASCII source code which could not 
be
   brought back to TeXmacs automatically. This is true for TeXmacs as much as
   for any other literate programming tool you might want to use.
3) The only real thing we can do about conflicts is somehow rule them out
   at their roots, as much as possible at least, e.g. using the two above ideas.

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

Cool.

> 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.

Yes, I am aware of this problem and having lots of new ideas.
But it will take some time before they get integrated in TeXmacs, I fear.
Hopefully in the process of implementing editable hyperlinks though.

Best wishes, --Joris