Motivation

Currently, there are a few notable inconsistencies in how math mode handles the distinction between fonts for variables/operators and for text. In particular, the syntax $ "double quotes" $ is used both to introduce multi-character variables (such as in $ "speed" = 5 $), and also to introduce text (such as in $ 6 > 5 "iff" 5 > 4 $). However, the text produced from the double-quote syntax will necessarily use the math font, not the normal text font used along the document. Not even manually inserting #text[...] fixes that (the inserted text still uses the math font); the only way to manually insert the normal text font in math mode is to use #text(font: "The text font here")[...], which is very verbose.

Additionally, the double quotes syntax behaves a little weirdly right now: "a" is displayed italicized, while "aa" is upright (see #274).

Therefore, the purpose of this RFC is to hear opinions regarding what the best syntax would be to introduce normal text inside math mode (using the document's or context's text font), and to make it separate from math font text (variable/operator names and stuff), thus potentially fixing many other minor issues in the process.

We already had some discussion regarding this over Discord, and I'll try to show some of the suggestions sent there here.

Proposed alternatives

1. Use text() for normal text font

This possibility suggests that all math mode text should default to the math font, including text inserted with double quotes, as it is now. However, a math.text function would be added, letting you use $ 6 > 5 text("iff") 5 > 4 $ to enforce the document text font.

• Pros:
  • Syntax would be familiar to LaTeX users (where it's \text{})
  • Pretty clear that it's the text font (it's called "text" after all)
  • Fully backwards-compatible (everything written in the old syntax would remain exactly the same)
• Cons:
  • Still a bit verbose (and the "..." syntax has been quite convenient)
  • Could be annoying nonetheless for those who don't come from LaTeX
  • Wouldn't fix "a" not being upright (might be something that could be fixed in other ways though)
  • Would be confusing, since #text() would revert to math font (since that would be the default text element, not the math-specialized one, due to how the internals work), and overall the logic would look backwards (a user could ask: why does the default text element produce math text in a math environment, while math.text produces normal text?).
  • User could be confused regarding why " " and text(" ") are different.

2. Use var() for math font

This possibility suggests that all math font text should, instead, be wrapped in a special element called var, and all double-quoted text in math mode would default to the document/context text font, unless wrapped in var. Sample usage would be $ var("speed") = 5 $ (note that var(speed) wouldn't work, as it would try to read speed as a variable or function). Single-letter variables (e.g. $ e $) would be implicitly wrapped in var by default (and operators such as sin or op("...") would also be in math font by default). In contrast, writing $ "speed" = 5 $ would display "speed" in the document text font, not in the math font.

• Pros:
  • Would be explicit regarding what uses math font and what doesn't (var() is pretty clearly a variable, and " " is pretty clearly text)
  • Would make it easier to control the math font, without having to set the font for the whole equation (something like #show var: set text(font: "New Math Font") could be made to work).
  • Would make math mode less "magic": instead of having all content be magically interpreted and represented as math when inserted in math context (which also leads to issues like Single letter strings get parsed as italicized in math mode #274), only content explicitly wrapped in var would look like math.
  • This would also lead to cleaner internal code (non-var things would not require much special treatment in equations), and could make it eventually possible to merge text layouting and math layouting procedures.
  • Could potentially allow math font in text without having to insert things into equations (or $ $).
• Cons:
  • var("something") seems a bit annoying to type compared to just "text" for text. (See the next alternative for a possible solution here.)
  • Could be potentially confusing to use at first, due to the new or altered syntax that users (new or not) would have to learn. Should be solvable with proper docs and communication.
  • Could inherit the redundancy with upright() for multi-character variables (though that's just the status quo).
  • Could also be seen as redundant with op() (but it does have spacing implications, while var would just set the font). Shouldn't be a problem, as it would be a similar distinction between upright() and op().
  • Wouldn't be fully backwards-compatible (anything using double quotes would change to use the document text font).

3. Add @variablename shorthand syntax for var("variablename") (preferred, but debatable)

This possibility is a complement to the previous one: not only do we use var("...") for math font and just "..." for text font, but we also introduce shorthand syntax for simple uses of var("..."), a.k.a. syntax which is just sugar for (is replaced with) var("..."), to make it less verbose. Initially, we proposed the @ syntax (up for debate). That is, one would be able to write something like $ @speed = 5 $ (for example), which would be replaced with $ var("speed") = 5 $, and would thus have speed be written in math font (in contrast with $ "speed" = 5 $ for text font). For more complex uses, one will still be able to use $ var(#[very complex text]) = 5 $.

• Pros:
  • All the pros for var("...") (as it's an extension to that proposal).
  • Shorter syntax for simpler use-cases (@speed for a multi-character variable).
• Cons:
  • All the cons for var("...") (except for verbosity).
  • Could be confusing with the currently existing @ref syntax, but it's probably fine as one isn't expected to cite things in math mode anyway (and, if one really wants to do so, just insert it through #[...]).
  • Not yet clear what would happen if the user tried to do @"a b c" or @[a b c] or something like that. (Up for debate.)

Next steps

Please leave your opinions below. In particular, we need some thoughts regarding:

1. Which alternative above to pick;
2. Any additional pros and cons which weren't considered above;
3. If we pick the preferred one above (the shorthand syntax), then which syntax should we use (@variable or something else);
4. If we do use @syntax, then whether we should allow things like @[aaa bbb] or @("aaa bbb") or @"aaa bbb", or what should happen in case the user specifies one of those (throw some error, display with spaces, just literally insert the @ there [could be annoying to parse], ...).

Thanks for reading!