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

Using \( ... \) as opposed to $ ... $ when toggling using ts$ #3040

Open
danieleavitabile opened this issue Nov 12, 2024 · 2 comments
Open

Comments

@danieleavitabile
Copy link

danieleavitabile commented Nov 12, 2024

Is your feature request related to a problem? Please describe it.

When toggling between equation environments using ts$, I find the move to $ ... $ ineffective: one comes from a multiple line equation, and when toggling to inline, vimtex puts into a single line. In the vast majority of cases I have to go back to the text, and modify it or re-format it.

Describe the solution you'd like

I would like that $ ... $ be replaced by \(...\), or the latter be added to the toggle list. I also would like that what is within the delimiters stay as is (no equation rearranging).

@lervag
Copy link
Owner

lervag commented Nov 24, 2024

First, you can change the desired toggle sequence with the option g:vimtex_env_toggle_math_map. E.g.,

let g:vimtex_env_toggle_math_map = {
      \ '$': '\(',
      \ '$$': '\[',
      \ '\[': 'equation',
      \ 'equation': '\(',
      \ '\(': '\[',
      \}

This would solve one part of your issue. The second part is currently not possible, but I could consider it.

In my personal opinion, inline math $...$ and \(...\) should be part of actual text, thus it feels "wrong" to not actually inline it. This is the reasoning for the current behaviour, and since 2013 you're the first to ask for a different behaviour.

I prefer not to add more options, but what you are asking would need more options. So I'm curious if you could reconsider if you really want this.

@danieleavitabile
Copy link
Author

Thanks for your help, and please do not feel like you must take more work in just because I ask, especially if it involves creating an option and maintaining it further down below. Let us think along if creating an option is necessary at all.

I completely see why you have designed $…$ to put text on one line, as it is meant to be inline math. I am puzzled about the intended use of toggling though.

When I toggle from $…$ to \[…\] is typically because the expression I am writing inside the $…$ is becoming too large to display. In that instance, there is no problem: vimtex moves the enclosed text on multiple lines between \[…\].

Toggling from\[…\]to $…$ on the other and, typically involves a long-ish text that I am trying to move on display. So I come from code on multiple lines, of which I am maybe commenting one, and I want to try to display the formula inline. Moving the text on one line inside $…$ typically garbles my text, and it also ends up commenting automatically code that has not been commented under \[..\].

I am actually curious of how people use the toggle from \[…\] to $…$, as I can’t imagine other cases than the ones I have above.

I thought that adding the \(..\) and forcing the text to be displayed on multiple lines without adding further options may be useful middle ground. At the moment users of \(…\) are not catered for by vimtex, and we cycle without options as follows:

$…$ —> \[...\] text moves on multiple lines
\[…\]—> \begin{equation}…\end{equation} text remains on multiple lines
\begin{equation}…\end{equation} —>$…$ text moves on one line

What I have in mind would add one extra layer without options:
$…$ —> \[...\] text moves on multiple lines
\[…\]—> \begin{equation}…\end{equation} text remains on multiple lines
\begin{equation}\end{equation} —> \(…\) text remains on multiple lines
\(…\) —> $…$ text moves on one line

But please do not think I’m insisting on this, really. I just love your software, and the pleasure I get from writing papers with it. The discomfort I have is very minor, and there is no need to do any changes if you find the behaviour forceful or unnatural. I don’t even know how much work this entails, and if it makes the code harder to maintain. I would say that if we have to go for creating a new option, then I don’t think it’s worth it.

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

No branches or pull requests

2 participants