研究の書類を書くに私はLaTeχを使います｡

For writing research papers I use LaTeχ.

Pour écrire des papiers de recherche, j’utilise LaTeχ.

While this program is in my opinion much more suited for writing academic documents than a classical word processor, and has a lot of useful features and add-ons, it also has its shares of problems.

LaTeχ is not a word-processor in any sense of the word, its authors call it document preparation system, in fact it is a language that can be compiled into documents. So when you use LaTeχ, you typically edit a source text file and then compile it into a graphical file, typically a DVI file, a postscript file, or more recently a PDF file. This means that LaTeχ is not a WYSIWYG system. Instead you type what you mean and let the layout system do the layout for you. While there are graphical front-ends to LaTeχ, you can basically write documents by using all the tools and techniques designed for handling programming source code. This is both the strength and the weakness of LaTeχ: it is a programming language, you can define marcros, function, even conditions. For instance when teaching, I use a set of macros that builds the cover page of the test with the sum of the maximal points and helps build two version of the test. You can do similar things with macros in Word, but not in such a clean way. The problem, is, you need to compile and debug your LaTeχ files. And LaTeχ, as a programming language is seriously dated.

So while I use LaTeχ daily, here are some wishes for improvements:

Better error reporting

When LaTeχ cannot compile a file, it simply stops with an error message and waits for input (not abort/retry/fail, but nearly), the error messages are not that helpful, and if the problem lies in a macro definition, or an unclosed list, the line number will often be bogus. Nowadays, even GCC compiling C++ with templates can do better than that.

Unicode support

LaTeχ is by default a ASCII only program. There are packages for enabling certain encodings in the source file (like ISO-8959-1) or even UTF-8, but they are hacks and in the case of UTF-8, only support a limited number of characters.
While I accept that LaTeχ is not a WYSIWG system, if my text-editor can handle characters, so should the LaTeχ compiler. In fact, I could not put the content of this post into a LaTeχ document directly.

Any character outside math mode

LaTeχ has a special mode, where the typographic engine does not follow the rules for normal text, but instead the rules for equations, this affects most notably the spacing between characters. Current versions of LaTeχ allows certains characters (say a greek ξ) only in math mode. So not only can you not only type the xi letter directly, but you have to type its code in math mode, so the resulting text is $\xi$, really inconvenient when you mention variables in the main text.

Better font control

Font control is quite primitive in LaTeχ, you usually specify the font-size in the document declaration. Want to change the default font? You need a special package. Want to do slides with LaTeχ and use a special font? Good luck. I typically use sans-serif text in my articles, but the sans-serif font look larger than the serif font. Even adjusting font size is complicated. The problem lies in the fact that LaTeχ has its own font back-end, with its own font tables. So even if your machine probably has a complete true-type rendering engine, LaTeχ won’t use, instead it will rely on its own engine.
Of course, the way characters sets (be it for math mode or unicode) are handled and the font-rendering engine are linked