An idea for collaborative work with LaTeX users

one of the main arguments which seem to prevent the adoption of TeXmacs is the lack of possibility for collaborative work with people which wants to use LaTeX. This is certainly my personal experience and also the experience of some of the people I know.

So far we tried to address this problem by thinking to conservative editing of TeXmacs documents, i.e. by taking TeXmacs a bit nearer to LaTeX. However another solution could be to take LaTeX nearer TeXmacs. Most of the time these collaborators wants only not to be forced to use a different program than they are used to, especially to edit files. They are not using all the dark sides of LaTeX: usually they just want to type in text and formulas in the way they are used to and have their screen divided in two halves, one for writing and one for displaying the result. They seems happy with that. (ok I’m a bit exagerating but maybe you get the picture).

We could devise a format for TeXmacs documents which “looks like” LaTeX, i.e. a textual format with slashes and { and }, … which can be edited in an ASCII editor and which can be fed to TeXmacs via the command line to produce a PDF. In this way it can be both used in the good old ways but also edited in TeXmacs.

I do not think it is too difficult somehow to realize but I’m not sure it is a good idea. I wanted to share it to see what do you think.

I don’t think that such kind of functionality helps. It will only distract the developers of TeXmacs. In my opinion, some kind of “mixed programming” might make the collaborative work easier. Possibility to load the intermediary files from the compilation of LaTeX to get the information about labels might also help.

I like the idea, but I have some comments about it.

I’m not sure which type of LaTeX user this would attract. Die-hard LaTeX users will probably not want to switch because of this, as they are too invested in LaTeX already. I somehow also don’t think that for the more technically inclined users the interface is the problem. Those who are forced to use LaTeX, on the other hand, may even be put off by the idea of getting a LaTeX-like experience.

It could also be that if we start to “advertise” this approach that we will be reinforcing the idea that TeXmacs is (and should be) 100% compatible with LaTeX. Users may wonder why pasting their LaTeX code into TeXmacs doesn’t work.

These are just my impressions, they can be wrong. Just want to add to the discussion.


Maybe :slight_smile:
I would need to think more about this. I would like very much to see a double-view editor (like Lilac—
In the current realization, the source of a TeXmacs document is editable better in the TeXmacs editor than by hand; and some of it (but not all) is difficult to read, but might be made easier by a different layout (e.g. the graphics; I do not know what to do for the mathematical formulae). The representations provided at this moment do not include the ones I would like to have :slight_smile:
Perhaps a double-view editor is already enough.

I do not know if it is important changing the format so that it can be easily edited by hand; one advantage is that you would need the TeXmacs typesetting engine only, not the editor, and this could be a welcome option for some users; one disadvantage is that this would force one (IMHO) to write error messages for the very many errors that one may do when typing and that may stop the conversion from code to document. The source code editor of TeXmacs forces one to write code with the correct opening and closing brackets, allows one to insert arguments only when the macro accepts them and perhaps does other things which I am not aware of—thus it does not need error messages (in fact the error messages of TeXmacs are not meant for the user as far as I understand).

This idea doesn’t address the social aspects of using TeX/LaTeX though — namely, you will be putting your academic career at risk by even suggesting anything other than TeX/LaTeX.

Let me clarify the extents of my proposal: it is about collaborative work on a paper from multiple parties. Currently there is no choice: either everybody uses TeXmacs or nobody can. What I’m proposing is a way to alleviate this problem. I can manage the document in TeXmacs as a TeXmacs document, but the others will see something which resembles very much a LaTeX document, which they can edit as a LaTeX document (using all their well known commands). I’m not thinking of anything fancy: all the fancy stuff can be done in TeXmacs and the people in the LaTeX contribute essentially writing, formulas, tables, etc… all things which taken one by one are quite easy to convert back to TeXmacs. What is difficult to manage is the wilderness of a general LaTeX document, which this methods avoid by restricting what users can do in the LaTeX side. This is not a general solution and will not dilute TeXmacs in LaTeX but it has the specific purpose to allow collaboration between the two sides. Instead of initiating the collaboration from a LaTeX document (which requires conservative conversion on the TeXmacs side) we manage the collaboration from the TeXmacs side. For most use cases I have in mind this could be sufficient.

Dear Amir, this does not corresponds to my experience. I know many colleagues which use TeXmacs and whose carrier is not threatened by the LaTeX-using colleagues. Also many of my colleagues do not use LaTeX directly but things like Scientific Workplace, LyX or others interfaces.

A simple version of the “mixed programming” that I proposed is the possibility to include tex files in TeXmacs. When loading them, at least after an update, TeXmacs invokes LaTeX to compile the source code, then include the pdf along with some linking information which allows \label, \ref etc. to work.

Does your idea make sense with journals/conferences that require TeX/LaTeX submissions?

Okay, I think I misunderstood the proposal initially. It’s an interesting approach. When I need to work in LaTeX, I often use SyncTeX to move between pdf and source. I imagine many TeX users do and would miss such functionality. I have no idea how complicated this would be to integrate.

That should be not complicated at all, indeed around 2003-2005 I developed one of the first PDF pdfviewers on Mac which integrated the pdfsync technology (TeXniscope, now defunct). It is just a matter to emit in the PDF the right metadata. But you are right, this is something people would expect to work. The tricky point is that the line number information is not know from the start since in memory the file is not stored in an string but a tree.

Since ~2015 most of my papers are written exclusively in TeXmacs, in particular these paper have been fully written in TeXmacs and just at the last moment converted to LaTeX for submission to arXiv or to journals:

Three of my doctoral students wrote their thesis in TeXmacs, other students or collaborators started to use TeXmacs working together and just keep using it in their own work. The only problem I have is that some of my older collaborators do not want to learn a new program and in that case I’m obliged to use LaTeX to be able to collaborate with them. They are not very sophisticate LaTeX users, they just do not want to learn a new program and they have to type text or equations, with references or some bibliography. That cover 80% of the math papers I usually see around. There are no images, there are no tables. That is the reality for which the solution I propose is meant. As I told you I’m not certain is a good idea. But thinking that TeXmacs has no place in the academic world is simply not a reality. In fact many people in the mailing list and in the forum belongs to the academic world, I would even say that most of the users of TeXmacs are either professional mathematicians or from other nearby fields.

This is not what I was meaning and technically it would be unacceptable since patching uneditable PDF in a TeXmacs documents would result in very low quality documents and not very practical to work with.

Perhaps now I am understanding … but faintly yet. I do not understand how you restrict the constructs that authors can use—I am interpreting your idea in that authors would edit a text file, and I do not see how to stop them inputting syntax that TeXmacs does not recognize.

It will give an error, or the wrong output. I think you trust too much a generic LaTeX user: most LaTeX users do not know LaTeX, they just look at recipes in stack exchange and copy them in their files, if it does not work they look for another recipe. In particular all my collaborators never do this, they just want to type basic constructs. I’m not speaking to emulate LaTeX, I’m speaking to covering the 80% of the normal workflow in a collaborative writing of a paper. Look around and then tell me which are the frequent construct which is difficult to cover, apart from TikZ and other things like this which we can even do right now in a typical TeXmacs document by calling out to LaTeX and importing the resulting image.

An error at compilation? If so, maybe the error message for construct x could say “construct x not allowed in TeXmacs collaboration mode”.

Edit after re-reading your message:

I have in mind that the conversion should give users clear instructions, i.e. when it is the case tell them that the constructs are not accepted by TeXmacs, regardless of whether they are valid LaTeX.

Ok, so basically your idea depends on the fact that TeXmacs is much better at exporting to LaTeX than importing from LaTeX. Is that the key point?

BTW, do conferences still have page limits? Wouldn’t exporting to LaTeX possibly change the number of pages?

Does LaTeX give such meaningful errors? A typical LaTeX user would be offset by this intelligibility. :slight_smile:

1 Like

Indeed, we can control the output language but not the input language. We can also control well if in a well exported document another user make small modifications. All other cases are very hard to manage, even if Joris and François made some progress in this direction.

The LaTex export is never 1-1 faithful. Nobody care anyway, the paper will need reformatting to fit into the format of the journal. So some postprocessing of the LaTeX file is necessary: the editors use the authors as unpaid typesetters nowadays.

I don’t think that the LaTeX users would use your “simplified” version of LaTeX. I download the LaTeX codes from arXiv several times in order to produce an epub file to tranfer to my Kindle. My impression is that their code is pretty non-standard.

You are correct that most users don’t deliberately use the “dark side” of LaTeX, but unfortunately, from time to time, they learn some “dark side” from their practice, or existant non-standard codes. For example, it is very common to see codes like A_\mathfrak{m} instead of, say, A_{\mathfrak m}. They might also use \over. I also find, from time to time, the usage of \def instead of \newcommand to “solve” a conflict but they really need \renewcommand.

In short, they are already used to their own, even non-standard codes. Moreover, they are also accustomed to their toolchain (not just a text editor) and it seems hard to satisfy their needs.

What I proposed about embedding pdf is used for drafts. Given that journals might only accept LaTeX codes, the issues you mentioned don’t seem to be serious.