I know the project exists since forever, and has a brand of its own, but whenever I hear about it, my first thought is "oh, latex package/mode for Emacs. Nice".
The name choice is unfortunate, since I'm not the only one with that association.
You ought to consider a name charge seriously, at least for the 3.0 version, in my view. It's hard to estimate how much a name impacts adoption, but it is quite likely people would be reluctant to even try a tool which creates associations that they find unappealing.
Switching to some phonetically adjacent name, say TypeMax or SciMacs or ... could be a friendly invitation to a new generation of users to give the platform a spin.
It uses guile scheme as a scripting language which I like. I think if you are using LaTeX already, going between TeXmacs and LaTeX is not too bad. I have to troubleshoot LaTeX issues within LaTeX all the time when I use special packages and then move to a LaTeX install without those packages. The immediate mode of TeXmacs is good for composing technical documents. I usually fall down a LaTeX hole when I try to get a report done that needs to be done by end of day! TeXmacs is my goto for that, and Pluto notebooks and RMarkdown as well.
2.1 does not introduce new features with respect to 1.99.21, the software has been gradually refined with new features and bug fixes along the whole 1.99.x series of releases I think (I am following it starting from about 1.99.9).
Important features of 2.1 are a much improved LaTeX export filter, improved HTML export, a comment facility (for collaboration), improvements on plugin support for several programming languages (I did not test these extensively), a very nice mechanism for making it easier to use the label/ref mechanism (includes a tiptool for immediately seeing the referenced object).
I've successfully used TeXmacs to take more than 100 pages of notes live during a math class. The keyboard shortcuts used to build math formulas are extremely effective and quite easy to learn. I still use it from time to time when I need to write a quick draft of some idea with formulas, or as a wysiwig editor for non-technical text documents. Unfortunately it is not compatible with LaTeX in both directions (export works, import is only partially supported), which means I'm unable to use it when collaborating with other researchers that are used to LaTeX. I'll be happy when LaTeX dies the horrible death it deserves and a better structured document format like TeXmacs emerges as a new consensus, but sadly I don't see that happenning in the forseeable future.
I would like to see what kind of documents cannot be imported from LaTeX, because the LaTeX -> TeXmacs converter works correctly or nearly correctly on thousands of documents from ArXiv.
There is also an option for conservative conversions (see Basile's comment below).
The way you phrase 'not compatible with LaTeX' and 'partially supported' suggests that TeXmacs is to blame for this situation. IMHO, TeXmacs does the conversions as well as reasonably possible: you could have said 'LaTeX is incompatible with any other format', which I consider a better assessment of the situation. If you don't agree, then please tell me which other document format is compatible with LaTeX.
FWIW that comment reads like a significant endorsement of TeXmacs to me. The comments about conversion sound more like practical concerns rather than pointing fingers and blaming. They're clear on their opinion of LaTeX as a horrible mess, so it's unlikely they're going to disagree with your assessment in the last paragraph.
I understand that it can be frustrating when something you've worked hard on gets (seemingly) inaccurately portrayed, but I think you comment takes an unnecessarily defensive and passive aggressive tone against what's largely a supportive comment. (I'm assuming you're the creator/major developer of TeXmacs, based on other comments in the thread about naming choice.)
It is not my intention to sound aggressive, but just to get things straight. I understand from the original comment that the author likes to use TeXmacs, but that (s)he thinks that the proclaimed incompatibility with LaTeX is too big a drawback for more than occasional use.
Now one has to be fair when making this kind of statements.
First of all: how 'big' is this incompatibility? I think that it is not that big at all and roughly as big as when you use a new style package with LaTeX or when trying to recompile a 25 year old LaTeX file.
Secondly: who is to blame for this incompatibility? TeX/LaTeX was designed to have a Turing complete grammar, which makes it impossible to write 100% reliable converters. The way the comment is stated, it suggests that TeXmacs is not good enough. I think that this is a misrepresentation.
Now it is plausable that the author is not even aware of the implicit bias of the terms 'incompatible with LaTeX' and 'partial converter'. Therefore, my reply might sound aggressive. But if you carefully reread it, then you will understand that it isn't.
Hey, thanks for sharing your perspective. I'm sorry you interpreted my comment in that way, I did not mean to say that TeXmacs had shortcomings in the way it imports LaTeX, in fact I do believe it does its best given the constraints it faces, but as you justly said the task is impossible in the general case given LaTeX's Turing completeness. To be clear the problem is not TeXmacs, but the fact that in a team most people work in LaTeX and having to constantly convert from one another would be impractical. In particular I rely heavily on git to manage document history and to view diffs from my co-authors, and having to manage a document that exists in two languages simultaneously would add significant complexity to a workflow that I'm already barely able to make my co-authors follow. This would be of course significantly simplificated if import followed by export (and the reverse) was the identity function, which would technically allow TeXmacs to directly edit LaTeX documents without having to rewrite them entirely, but I don't believe that to be the case and again I don't see how it could be possible.
To answer your other comment, this paper of mine https://arxiv.org/abs/2102.04063 has many problems when importing in TeXmacs: the title is not aligned correctly, the algorithms are messed up, the figures don't have the correct sizes, and one of the figures which is exported from Inkscape is not even imported at all. There are also a bunch of macros that are shown as raw visible commands in TeXmacs and I don't know what to do with those (but that's certainly something I could learn to manage). Again not blaming you or the particular TeXmacs devs working on import, this situation is a fatality of how LaTeX works.
One thing that makes a small part of the import not work is that in the LaTeX source some of the macros are defined after the start of the document, and TeXmacs sees them too late to take them into account when formatting the title.
Said this, TeXmacs finds the references, and LaTeX does not (I do not find the bibliography file, which is named "bibliography") ... how is this possible?
In my experience pandoc is not better than TeXmacs in converting LaTeX. The problem, as vdhoeven stressed, is that LaTeX is not a document format which can be converted reliably in something else. Usually I just convert to LaTeX the last version of the document, e.g. before submitting to journal. In this way I always dispose of some alternative storage formats: TeXmacs, PDF, LaTeX and sometimes HTML if needed. The LaTeX produced by TeXmacs uses few packages, which also means that it can be easily maintained.
(1) You may want to work with other formats. (2) You may not trust TeXmacs to be around in the future or to be installed on the machines you use. The ability to convert using Pandoc would not prevent anyone from using the existing conversions.
I agree that having more converters would be nice. But which formats are most urgent? A high school teacher would argue that we should support conversions for Word. Programmers would stress that we support Markdown or Pandoc. GNU hackers would ask us to support Texinfo. Any help is welcome...
TeXmacs is one of those apps that I reinstall from time to time when I want to scribble some math notes and find the split screen setup of most LaTeX editors or Markdown with preview too distracting. It is hands down the most pleasant to use for that purpose.
But I still get distracted by this one issue that bugged me since I first tried it 15 years ago: the anti-aliasing quality. The font doesn't look as crisp as what you'd see in other ClearType-enabled applications.
Earlier this year, I checkout out the SVN repository to see what's going with the renderer. The default Roman font is not TTF and cannot be rendered by FreeType, so TeXmacs has its own bitmap renderer for TFM fonts.
Basically, a glyph is rendered monochrome at a large size and then scaled down to the needed size with 8 color grayscale, IIRC. The bitmap is cached so wherever the glyph of the same style and size is needed, the same thing is drawn. Due to this, the font can sometimes look like it has weird kerning.
I tried to at least try subpixel rendering of the glyph bitmap to see if it makes things look better. The subpixel thing worked, but it didn't look any better. In the end, I gave up working on the issue.
I think that this issue was very interesting twenty years ago. With modern high resolution screens, I have to admit that we no longer bother too much...
In the future, we might only use Opentype fonts and use a font like TeX Gyre Pagella as our default font. I am afraid that we need to keep the old (tfm+pfb) Computer Modern as a legacy font so that people can reliably continue to use their old TeXmacs documents (remind that minor microtypographic changes may completely change lines and pages are broken).
I would be interested in improving (or at least experimenting) in this direction. Do you have any hint on what to do, or what was the problem when you tried? As with PDF we are not bound with a specific rendering pathway in the code, there could be the possibility to improve the Qt rendered for, at least, those fonts which are supported via Freetype.
I went back to see what changes I made to my local checkout. It seems I never made as far as to implementing subpixel rendering. I think I experimented with subpixel stuff on some other medium (maybe used GIMP to do the shifting manually, I forgot). So there may still be some hope.
On the other hand, regarding the kerning problem, there's not much you can do with the current one bitmap per glyph approach. One idea is to create multiple subpixel offset versions of the glyph. It'll cost more memory though. And the offset version of the bitmap may need to have its leftmost or rightmost column overlap the neighbouring glyph, and I'm not sure if the renderer supports gray level addition or if it would just overwrite the existing column from the previous neighbour.
As for Freetype supported fonts, there is an API for enabling subpixel rendering which you can call right before rendering the glyph. I've never experimented with it.
I've looked a bit around and in particular in the poppler library code to see how it works, they use QRawFont in the Qt backend to exploit subpixel antialiasing and native font technologies for each platform. We could do the same, essentially replace our glyph rendering code with something similar to their code. In this way we will make TeXmacs rendering similar to that of Okular, for example.
There is another far lest costly thing that we can (should) do and that was long on my wish list (less and less high with the higher resolution screens :)
The idea would be to see words that are "broken" into characters and use a global hyphenation algorithm for optimizing the "breaking".
TeXmacs is great (probably best-in-class). However, my biggest gripes with it is how non-portable the TM files are. The only tool that works with these files is texmacs itself. In particular, you can't even convert these files without the full texmacs GUI/runtime. Pity, since I would love to use it as a markup language.
The converter (e.g. to HTML or LaTeX) do not require strictly all the program but nobody took the pain to extract it and make it independent of the GUI layer. This could be a nice side project. We are also thinking to implement a facility to use TeXmacs as markdown editor. My personal experience is however that you want to create your content in TeXmacs and then eventually export to other formats, e.g. markdown or HTML to embed in blogs, etc..
I use TeXmacs' conversion capabilities from/to LaTeX on a regular basis. I find that the converter works very well, both ways.
When exporting to LaTeX, I have only encountered very few, minor issues, which are easy to fix if you know LaTeX. These glitches are corrected quickly in new versions of TeXmacs. The LaTeX code that TeXmacs produces is nice and readable — certainly much better than typical LaTeX code produced by typical users.
The other way around, it all depends on the quality of the source LaTeX file. If you start from standard LaTeX with a reasonably clean style, it works very well. If the source file makes use of very specific commands from very specific packages, then you may have to tweak the result, e.g. re-implement some of the non-standard features.
Overall, I think conversion works as well as it could possibly.
I am currently importing a 350 pages book into TeXmacs. The conversion works very well, but essentially reveals the flaws in the source files.
When sharing a document produced in TeXmacs with LaTeX but non-TeXmacs users, there is also a very nice feature, called conservative conversion: when you first export to a LaTeX file and then import the LaTeX file edited by your colleagues back into TeXmacs, TeXmacs will retain the original TeXmacs file wherever possible (preserving some advanced features that have been lost in translation, such as table management), i.e., TeXmacs will import from LaTeX only at those specific places that have been edited outside of TeXmacs.
The export filter allows one to work in my opinion (I used it a bit, I picked up feelings from discussions of others).
The import filter is limited (I have read that any LaTeX import filter is limited because of LaTeX's grammar), and in my judgment of this moment (that is, with very limited experience) it may work only if the people you are collaborating with "collaborate", keeping within the set of LaTeX expressions that TeXmacs recognizes.
There is work which may be helpful: https://www.texmacs.org/joris/latexconv/latexconv.pdf
but I do not know its current status and may not be relevant if people that write LaTeX code use syntax (e.g. a package) that the TeXmacs import filter does not support.
By the way, on the topic of using TeXmacs for one's work, I picked from someone the following suggestion: presentations, they usually do not require collaboration.
Years ago I looked into both LyX and TeXmacs. I could already quickly write math in LaTeX but I wanted to work out calculations on a single screen without the code/renderer split screen setup (having the math directly visible is a game-changer for doing long calculations, by the way). TeXmacs won hands down for me. I had no problem learning the intuitive shortcuts (e.g. any letter - TAB for its Greek counterpart). If you know the LaTeX counterpart you can almost always type that in. The converter to LaTeX source is quite good. I love that the "nesting hierarchy" in a math expression is visible. For instance,
"(x^2 + 4)"
has four distinct components: the parentheses "(...)", the term "x^2" (two components, "x" and "2"), and the term "4". If you place your cursor before or after the parentheses and use SHIFT+RARROW or SHIFT+LARROW (respectively), you highlight the parentheses; if you do the same before or after the x^2 term, you highlight x^2. I find a lot of math editors (e.g., Word 2016) get this wrong because they will just highlight the parentheses or the exponent. Smart highlighting is super useful for fast manipulation of equations. Oh, and also -- if you are within a set of parentheses, you can keep hitting TAB to cycle through (), [], {}, ... . Not to mention, TeXmacs handles all the \left and \right parentheses sizing for you (the parentheses in the above example would expand if, for instance, you made 4 a fraction like 4/3 -- a quick Meta-f away)
> but I wanted to work out calculations on a single screen without the code/renderer split screen setup (having the math directly visible is a game-changer for doing long calculations, by the way).
If anyone wants to play with this there are 'online editors' so you don't even have to download/install software nowadays:
https://www.mathcha.io/editor is indeed much closer to TeXmacs than https://latex.codecogs.com/eqneditor/editor.php. No matter how instant the rendering is, the latter is still split-screen. It may not seem like much, but when you are knee-deep in a calculation the advantage of having a single point of focus for your eyes is huge (at least to me).
Thanks, I'll look into it. I enrolled in a Master' Degree after almost 20 years out of the University, and had to do some mathy reports. Forgotten most of my raw LaTeX skills and not interested on doing the investment again, went directly into LyX, which I remembered it was already nice in the 00's. It was OK.
But if I have the time(and the need), I'll try TeXmacs.
Well, is more an opportunity to move forward. You just have to consider LaTeX as another output format, not really for human consumption, similar to PDF and HTML. Something you do not want to edit by hand. Many people are anyway moving in this direction using Markdown+pandoc and similar solutions. TeXmacs is another possibility in this direction which allows you to concentrate on the contents, including structure, and not on the programming of the content.
There is always the possibility to switch to source; there is a menu item in the editor (Document->Source->Edit source tree), and when examining source the editor becomes a structure editor (this enforces syntax as far as I understand).
I would really like to use TeXmacs for preparing linguistic publications, which may include multilingual text. TeXmacs does not seem to support Unicode combining diacritics. E.g. when I paste `бе́ля` in a TexMacs document, the accent is rendered as a full-width character between `е` and `л`, no matter which font I choose. Typing `⌘' e` (Latin `e`, not Cyrillic as above) renders `é`, but it does the job only for precomposed Unicode characters known to TeXmacs. OpenType `gpos` table has (e.g. in Times New Roman) a `mark` feature, specifying a "base" mark-to-base anchor point on Cyrillic vowels and a "mark" mark-to-base anchor point on U+0301 (combining acute accent), so the renderer can position the mark correctly above the preceding character. However, TeXmacs reimplements most of font rendering instead of reusing Harfbuzz which implements countless script-specific shaping quirks using OpenType tables. IMHO it's a Sisyphus' job.
Thanks for the detailed description. I understand better the problem. I'm not very accustomed to other scripts so I would need to look into this with more details. But at least now I understand what HarfBuzz is about :)
The name choice is unfortunate, since I'm not the only one with that association.