What would you like to change about TeX/LaTeX/XeTeX/etc.?

Question

Like the title says, is there anything about the system you're using that you would like to change? Some annoyance that should be fixed, some feature that could be improved or added?

Answer 1

One area of TeX which needs to be improved is math spacing (starting from 2007, Word does better than TeX in this area). The TeXbook (in chapter 18) recommends quite a few manual adjustments most which could (and thus should) be automated (and the list is not complete). Here are a few examples, with the correct spacing below (the cos²+sin² is a bit subtle as it’s a thin space instead of a medium space, but it is an important change since it also changes the shrinking and stretching values):

The problem is that the 8 spacing classes (\mathord, \mathop, \mathbin, \mathrel, \mathopen, \mathclose, \mathpunct and \mathinner) are not enough to cover all the cases. You would need at least the following supplementary classes: \mathnull (no spacing at all, for / and the backslash used as quotient), \mathfact (for factorials), \mathsqrt (for square roots) \mathdiff (for differentials in integrals) and \mathdpunct (for double punctuation like : and ; in French typography, in which you want a thin space both after and before).

Answer 2

TeX is a system written by a genius, and it has many great features, but the underlying architecture is flawed. The programming interface, and the programming mechanisms provided within the system contrast the intuition of most computer programmers. The list of idiosyncratic features is too long to enumerate:

• Character codes and non standard lexical analysis.
• Clumsy support for imperative programming, including numbered variables of a limited number, no variable names, no control flow, no boolean type, etc.
• Use of Pascal.
• Arbitrary constants and numbers (file numbers, character codes).

In short, if I could do it all over again, I would (a) use a decent modern programming language for the implementation (b) design a clean programming interface, including the usual tools of the trade, block structure, typed named variables, procedures, exceptions, and, yes, even object orientation.

Finally, I would (c) apply a clean design which does not reveal or discuss issues such as mouth, stomach, and \expandafter, and of course, I would write a book without dangerous curves signs...

Answer 3

Top 1 on my list: (1) better error messages and (2) better debugging facilities.

1. I found it notoriously hard to understand LaTeX error messages, especially if "advanced" document classes (such as beamer) or packages (such as biblatex or hyperref) are involved. (For instance, with beamer frames the reported error location is often just the closing brace of the frame.)

2. Even more difficult, at least for the beginner to intermediate developer, is the debugging of own macros. Using \show and \meaning is IMHO painful. What I really would like to have is a "symbolic" debugger where I could step through the expansion process to understand what is going on.

Answer 4

I hope that the author of XeTeX spends some time and fixes XeTeX bidirectional primitives bugs and also adds few new primitives as already suggested. Doing bidirectional macro programming with various bugs and shortages of XeTeX in terms of bi-directionality, has been a headache for me.

Answer 5

Nice automagickal default spacing, alignment and line-breaking in display math mode and in tables, with the user not having to rake his/her brain about whether to split his gathered's or align his multline's or start his tables with {p{\wildguess}|cpr|@{h}lp||pl@{z}}. You should be able to write a really long equation, or a table, and for that to "just work".

Answer 6

I think too many parameters and algorithms are "hard-wired" into the TeX engine, in particular when it comes to math typesetting. One example is the algorithm for placing a sub- and superscript combination, which sometimes leads to undesirable results, as I explained in this answer. (Very strange: The distance of a superscript from the baseline is at least 80% of the x-height only if a subscript is present and by default too close to the superscript, otherwise the superscript is allowed to be lower.)

It would be great if some improvements in this direction could be included in LuaTeX.

Answer 7

Surprisingly high on my list: not calling that verbatim-handling macro \next. I think

"file ended while scanning use of \next"

(or whatever the phrasing is) is the archetypical meaningless error which you have no chance to fix unless you happen to already know it's caused by the \end{...} of your verbatim-like environment not starting on column 0. I think somebody reading the code would have less problems with a not-quite-appropriately-named \getnextverbatimline or whatnot than the normal user has with \next.

Answer 8

"Weak" groups

I've found myself quite a few times trying to temporarily modify a macro, but this method has some very real problems:

\bgroup <stuff> \def\x{\egroup <more stuff>} \x

In particular, if the first "<stuff>" defines any macros, they'll be lost when \x is performed. A certain kind of "weak" group that all \defs "escape" by default except stuff explicitly declared so would be nice. That way you could write stuff like this:

\bwgroup
  \let\a\relax
  % make any subsequent changes to \a local to this weak group:
  \weaken\a % or \weakencsname a\endcsname.
  <do stuff with \a>
  \let\b\relax
\ewgroup % the weak redefinition of \a disappears in a puff of logic.
\a\b % no error. They are both equal to \relax

instead of

\let\a\relax
\let\OLDa\a % and *hope* that \OLDa is not defined already
<do stuff with \a>
\let\a\OLDa
\let\OLDa\undefined % and *hope* that \undefined is actually undefined
\a

Exporting macros out of an enclosing group

If for no other reason than the fact that this would make writing packages safer since you would know that anything you didn't explicitly export could not pollute the global namespace (speaking of which... namespaces would be nice too)

\begingroup
  \begingroup
    \export1{\let\a\relax}
  \endgroup
  \a % no error. The definition of \a was exported 1 group level outwards.
\endgroup
%\a % error. \a is not defined here.

Answer 9

Transforming boxes to tokens and back

I very often find myself in a situation where I would like to

1. find out exactly something which is "hidden" in a box (say, is there a hyphenation at a specific line, or how much is glue stretched)
2. make a small modification to a box's contents

It is possible up to a degree to analyse box contents with \lastbox, but as the name already says, any kind of box content which is not a box or glue or kern or penalty (like rules, characters or specials) makes the analysis futile.

In particular, it is impossible this way to analyse and recursively reconstruct a box in a modified way, apart from trivial cases.

So I'd basically like two primitives:

1. Transform a box into a token list
2. Transform a token list (which was derived from a box) back into a box.

Needless to say, transforming a box into a token list and transforming that token list back to a box should always reconstruct the same box.

Mind you, I am not talking about transforming a box back into the tokens it was originally generated from (which would mean, say, "undoing" paragraph formatting), because that process is a "trapdoor" function.

All the tokens in the token list could be special just for representing box content, as long as I can analyse and modify the box in all respects by analysing the token list.

If you look into the log listing of a box:

..\vbox(548.5+0.0)x390.0, glue set 505.11273fil
...\write-{}
...\glue(\topskip) 3.66669
...\hbox(8.33331+2.33331)x390.0, glue set 320.08823fil
....\hbox(0.0+0.0)x17.62482
....\OT1/cmr/m/n/12 s
....\OT1/cmr/m/n/12 o

then I would be perfectly content to get everything listed there as a sequence of (nested) tokens, as long as all information and content is there in "parseable" form.

Answer 10

• I'd change the (0,0)-point of the page to be at the top left corner of the paper, instead of assuming it's one inch from left and top (although note the later --compat).
• Some of the plain macros are defined in terms of points, I'd change those to use em's and ex's instead (i.e., relative to the used typeface).

• If I were to re-implement TeX (lol!), I'd do it with a multi-paradigm high abstraction level language with a consistent syntax. Although I do understand why one would seek to achieve efficiency over everything else; to quote Knuth from TAOCP Vol. 1's Preface:

  For example, some combinatorial calculcations need to be repeated a trillion times, and we save about 11.6 days of computation for every microsecond we can squeeze out of their inner loop.

  That's a nice angle! But maybe not one which fits the nature of TeX, though. At least not to the point where efficiency goes over everything else. What with the compiler targeted instruction sets and all.

  So I'd be choosing cost of programmer time over the cost of computation time, and a language which has survived even longer than TeX itself.

  I'd make it backwards compatible with a toggle --compat, but without that option flag, it would handle math much in the same way Philippe describes with some additional exceptions for constants for example.

  If I'd choose the other way around, efficiency over everything else, that just would have to be done in MMIX for a custom computer! ;-D

Daydreaming...

Answer 11

For me, it's about simplification:

Package integration

Integrate some of the most common packages into LaTeX directly, e.g. array for tabular extensions, geometry for page dimensions, fancyhdr for headers and footers, etc.

I think we could determine a limited number of core packages that implement very common features, iron out whatever incompatibility / instability / missing feature they still exhibit and integrate them into LaTeX.

LaTeX currently require (trained) users to load the same packages over and over to do simple things like produce a right-aligned fixed-width tabular column, and, even worse, forces new users to waste time figuring out how to achieve this.

Package rationalization

Combine / throw out unmaintained or redundant packages. This is probably a very touchy topic, but I think having 5+ packages to achieve the same thing is a waste of resources. For example, shouldn't we agree that biblatex (example!, please don't shoot me...) is the way to go for bibliographies, integrate whatever missing features from natbib, multibib, etc. and slowly depreciate these packages?

It would be very challenging to find the right balance on when this "rationalization" should kick in (we shouldn't discourage anyone from creating new packages), but I believe that sometimes there is too much choice for beginners, and too much work for class / package writers that want to ensure compatibility.

Engine & fonts

This is a long shot, but if we could move everyone over to LuaTeX, integrate fontspec (see first point) and provide a base of great fonts in Open Type (no more Type 1, no more cm-super etc.), I believe TeX would be more attractive to more people.

Or to put it differently, I think that a combination of a simplified font system / handling with a selection of great free fonts (from such foundries as The League of Movable Type, exljbris, etc) would attract a much more broader base of "regular" and "creative" users than today.

Answer 12

I'm missing a paragraph rebreak feature when part of a paragraph is carried to the next page during a page break. When one has to change the page width, e.g., from page 1 to page 2 of a letter, this would be very useful!