Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

feat: Newline command #1931

Open
wants to merge 8 commits into
base: master
Choose a base branch
from

Conversation

zeyad-ahmad-aql
Copy link
Contributor

  • 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
Copy link
Collaborator

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
Copy link
Owner

arnog commented Apr 16, 2023

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
Copy link

michelmar commented Apr 19, 2023

@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
Copy link
Owner

arnog commented Apr 19, 2023

@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
Copy link
Collaborator

@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
Copy link

@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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants