feat: Newline command

[zeyad-ahmad-aql]

• Added newline command \\. Inspired by KaTeX.
• Added feature to add new line on enter press.
• In virtual keyboard, replace [action] key with [return] key. Also, pressing return adds new line, pressing shift + return performs commit action.

[WildYellowfin]

I don't think the default behavior of return should be a newline - it's just not the expected behavior in most cases. Though unreleased, alt + return will create a lines environment, which seems like what you're looking for.

[arnog]

Thanks for the PR! This is something I was just thinking about. This convention of interpreting \\ as a new line even when outside of environments seems pretty common, and it makes sense.

I would go a bit differently on the implementation, though. I think using the lines environment that was recently added would be better. It would give you the benefits of being in an environment, such as keyboard navigation with up/down arrows, being able to control the height of lines (with \\[18mu]), supporting the existing keybinding to add a line before or after the current one and being able to convert to other environments (by adding a column, for example). It would also avoid introducing a new kind of atom.

The lines environment currently serializes to \begin{lines}...\end{lines} but I was thinking of changing that so that it would serialize to just its body (i.e. the rows, separated by \\). The trick would then be to recognize a \\ at the root while parsing and automatically interpret the root as if a \begin{lines}...\end{lines} had been present.

I agree with James that the return/action should not add a line by default. Maybe that can be an option (multiline attribute?).

A few other comments:

• in core-definitions/symbols.ts you call both newSymbols() and defineFunction(). You should only call defineFunction(). newSymbols() is to define commands that are not functions, i.e. that do not have arguments and map to a plain literal.
• the e2e tests are currently failing. It looks likes there's a \\ added at the end of serialization. This might be related to the superfluous call to newSymbols()

[michelmar]

@arnog Hello! I noticed you're considering the \lines environment for your project. I'd like to recommend using the Gathered environment instead, as it is well-supported by both MathJax and KaTeX. Unfortunately, the lines environment is not currently supported in KaTeX, which may lead to compatibility issues.

By opting for the Gathered environment, you can ensure seamless integration with MathJax and KaTeX, providing a more robust and user-friendly solution for your mathematical expressions.

[arnog]

@michelmar indeed, the lines environment has been added to MathLive. Unless I'm mistaken, gathered is center-aligned. I couldn't find a "standard" multiline environment that was left-aligned. Another option would be to use the \displaylines command.

[WildYellowfin]

@arnog @michelmar my suggestion would be to serialize lines as:

\begin{align*}
  & row_1 \\
  & row_2 
\end{align*}

Which will produce left aligned equations in standard latex environments. It may be possible to replace the lines environment with an align environment, but it would need to change the default column spacing (try pasting the above in a mathfield and you will see a gap).

[michelmar]

@arnog I understand the challenge you're facing in finding a suitable environment for your multiline math expressions. I was thinking in using the matrix environment, but it is primarily designed for matrices, which might not be the best for most use cases. But the behavior of creating a new pmatrix with each new line within parentheses is logical within the context of matrix formatting, so we could think in use the matrix environment instead.

Creating a custom environment in KaTeX would have been a great solution, but as you've noted, this feature is currently not supported. Therefore, the workaround I'm considering is building a parser that converts the lines environment into either a gathered or equation* environment.

I remember that in the past, the default behavior of copying an equation on mathlive was to add an equation* environment, but I don't know if this persists.

I don't really know what the best choice, but this feature is really awesome. I'm thinking to use mathlive to render my static math as well, but I don't have any comparison, if it is slower, I know that it uses the same font. And I'm using a nextJS application and sometimes I have some issues with mathlive in SSR.