Hi David, thanks for getting things started! The spec you wrote summarizes what we discussed really well. A couple of comments:
= Save, Load & Import I had not thought of importing plain source files (without tm-comments) before. Good idea! I think this kind of import should be available from File->Import->Source..., while the everyday import/export to source +tm-comments should happen automatically when selecting File->Save or File->Load. This is not only less cumbersome for the user than File->Export->..., but also avoids redundant duplication of data. = Determining the File Type in Load and Save Obviously we need some way to distinguish when to use our overloaded load/save functions and when to read a file as a standard .tm file. The .tm.c extensions are a very good mechanism for that. But we cannot rely on that exclusively: Think of a shell script that you want to run by calling "script" instead of "script.tm.sh". Joris suggested deciding which save method to use based on which style is set for a document. The load method can be chosen based on whether or not the document begins with "<TeXmacs" or not. = Special First Lines Speaking of the beginning of a document. We need to allow the user to customize what the first line of the saved file will look like: the first line of a shell script has to look like #!/bin/sh and the first line of an XML file has to be something like <?xml version="1.0"?> only after these lines can we start with #<TeXmacs|1.0.6> nontheless we need to parse the lines before that and propagate changes to them to the document. I am thinking of a special tag, like <lp-preamble|#!/bin/sh> When writing the document the contents of this tag are put at the very top of the text file (and the tag itself is serialized as the empty string, to make sure there is no redundancy). When reading a literate document everything preceding "#<TeXmacs..." is put into a lp-preamble tag at the beginning of the body. = Which Tags are to be Serialized Verbatim? Of course we could hard-code the tags that are supposed to be serialized as verbatim LP blocks. In fact that is probably the best way to do this in a first iteration. But in the long run we should use DRDs for this. I will have to investigate that. = Reordering Code Chunks I suggest we forget about this until TeXmacs documents are proper graphs, even though this may be a long time of. = To Do The way I see it right now the objectives are to create 1) overloaded load-save functions for source files with tm-comments 2) an import function for plain source files (treating comments as plain text) - 2) will share a lot of code with 1) 3) a database of commenting syntax (simply as a scheme file) 4) create style files that format verbatim blocks nicely (or do we use the <code> tag as is in TeXmacs?) 4) create convenience functions that split/join verbatim blocks (how would you want the user interface for this one to be like?) All of the above can be done from Scheme AFAICT. I will have to look at the load/save mechanism and the DRD stuff. Have you already started writing code? Have you any experience using TeXmacs' Scheme API? That's all I can think of ATM. Thanks again for your work, Felix _______________________________________________ Texmacs-dev mailing list [email protected] http://lists.gnu.org/mailman/listinfo/texmacs-dev
