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

[Sam Liddicott]

On 17/10/10 22:30, Michael Lachmann wrote:

On 17 Oct 2010, at 9:51PM, Joris van der Hoeven wrote:

Sure, as I said, I plan to include editable hyperlinks later this academic year.
This will make it even easier to edit external files from within TeXmacs.

Cool!

If I understand correctly, it isn't mainly intended for
interactive work, but to create files that can be compiled or processed
in other ways.

Yes.

Of course, it could be that one can combine both. Provide a way to
interactively edit a file, and create it right there, but also convert
the whole document.

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.

However authoring style with literate programming is different enough that any more then sending a patch to the generated source

 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.

I fully understand that making a decision on which evil you prefer
naturally leads to two different blends of literate programming tools.
Nevertheless, it might still be best to have a tool which
can operate in both modes: use TeXmacs documents as source code,
or use native source code.

Another challenge is to reduce the clobbering in 2) as much as possible.
One idea is to make TeXmacs grammar-aware, so that searching for a particular
piece of code becomes very robust, even in absence of special directives.
Unfortunately, this does not entirely solve the problem, because an external
person might delete or rename our particular piece of code using another editor.
Actually, the external person is not even be aware of the fact that
our piece of code was annotated.

Aye, and it only needs to be a light grammar awareness, so as to detect where the insertions or deletions occurred.

Anyway, at a certain point, I will dive into these issues.
At the moment, I will just try to follow the ongoing experimentations.

I think that TeXmacs should produce the code, or something from which the code can easily be extracted. But there are many other tools that need to deal with the code - debuggers, profilers, diff, revision control systems, etc etc.

And, I think the point you brought up also goes in that direction - what if you work on a big project, with many programmers. Does it force everybody to use TeXmacs?

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.

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?

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.

--