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

[danieleavitabile]

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]

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]

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.

[lervag]

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.

Thanks for understanding; and sorry for the delay in answering!

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 \[…\].

Ok, cool - then it is only the other way you find surprising.

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, …

I didn't understand the last part here; "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 \[..\].

It may be helpful if you show a concrete example of this.

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 don't use it too often myself, so I don't know.

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: …

Well, yes; you could argue it would be right to change the defaults. But it is a breaking change, so I'm not that comfortable doing it. Also, it is quite easy to change the toggle sequences if you want to.

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

Do I understand correctly that the following option actually works well for you?

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

And that you are also proposing that it should be made the default value?

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.

<3

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 mind to make changes if I agree with the changes proposed. But I don't like to make changes that increases the complexity and maintenance burden unless it is also a significant improvement.

In this case, I think it is useful for me to first properly understand 1) what you personally want for your workflow, and 2) what you are suggesting should be a default behaviour. If I understood correctly above, then it seems that you can get the desired functionality through an existing option, and that you are also suggesting that we change the default.

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.

Thanks, I think we agree here. So let's just make sure we understand things before we decide.

[nilsbecker]

I didn't understand the last part here; "commenting one"?

It could be that the OP has line comments within the display math?

\[
a=b
% a = c % this was wrong
\]

[danieleavitabile]

Here is a concrete example for wanting to move from an equation on display to an equation inline (I do this a lot, but I can't think of any other use for such transition). I start from this equation on display

measure $\prob$ are given by
\[
  \Omega = \bigtimes_{\alpha \in \USet} \Omega_\alpha, \qquad
  \calF = \bigtimes_{\alpha \in \USet} \calF_\alpha, \qquad
  \prob = \prod_{\alpha \in \USet} \prob_\alpha, \qquad
  \quad
  \mathbb{U} =
  \begin{cases}
    \{w,g,v\} & \text{if $\LSet = 1$,} \\[0.5em]
    \{w,f,g,v\} & \text{if $\LSet = 0$.}
  \end{cases}
\]

The equation is on display, and I am evaluating whether I should put it inline. This typically involves commenting part of the equation

measure $\prob$ are given by
\[
  \Omega = \bigtimes_{\alpha \in \USet} \Omega_\alpha, \qquad
  \calF = \bigtimes_{\alpha \in \USet} \calF_\alpha, \qquad
  \prob = \prod_{\alpha \in \USet} \prob_\alpha, \qquad
  % \quad
  % \mathbb{U} =
  % \begin{cases}
  %   \{w,g,v\} & \text{if $\LSet = 1$,} \\[0.5em]
  %   \{w,f,g,v\} & \text{if $\LSet = 0$.}
  % \end{cases}
\]

and then invoke ts$ to pass from \[ ... \] to $...$. And this is what happens:

measure $\prob$ are given by $\Omega = \bigtimes_{\alpha \in \USet} \Omega_\alpha, \qquad
  \calF = \bigtimes_{\alpha \in \USet} \calF_\alpha, \qquad
  \prob = \prod_{\alpha \in \USet} \prob_\alpha, \qquad
  % \quad
  % \mathbb{U} =
  % \begin{cases}
  %   \{w,g,v\} & \text{if $\LSet = 1$,} \\[0.5em]
  %   \{w,f,g,v\} & \text{if $\LSet = 0$.}
  % \end{cases}$ \end{hypothesis}

I will now get an error, as the $ sign has been put after a comment

This example is not overly fitting, as the starting equation is really too large for one to put it on display without further edits. But it shows the problem in my opinion: I think the intended use of the transition is for very short inline equations. I often use this type of transition to check whether a mid-sized equation can be put inline (or else, why would one use this transition at all?). As you can see, the text is now garbled, and it also produce code with an error, starting from perfectly legit code.

I propose to have an intermediate stage between \[ ... \] or \begin{equation}... \end{equation} and $...$. With it I obtain the code below:

measure $\prob$ are given by
\(
  \Omega = \bigtimes_{\alpha \in \USet} \Omega_\alpha, \qquad
  \calF = \bigtimes_{\alpha \in \USet} \calF_\alpha, \qquad
  \prob = \prod_{\alpha \in \USet} \prob_\alpha, \qquad
  % \quad
  % \mathbb{U} =
  % \begin{cases}
  %   \{w,g,v\} & \text{if $\LSet = 1$,} \\[0.5em]
  %   \{w,f,g,v\} & \text{if $\LSet = 0$.}
  % \end{cases}
\)

Hence, without trying to join lines as with $...$. The suggestion you make above does not solve my problem, because when \(..\) is toggled, the plugin still tries to join lines, which is where my problem comes from.

I proposed to have \(..\) by default not to try to join lines, and let those who want to join lines do another keypress and toggle until $..$.

[lervag]

Here is a concrete example for wanting to move from an equation on display to an equation inline (I do this a lot, but I can't think of any other use for such transition).

Thanks! And sorry for the long delay (again). There's a steady stream of new issues and I tend to reply to the new ones. As my time is limited I end up not having time to follow up on things. 🤷

By the way, notice that I edited your comment and changed from screenshots to verbatim example snippets. It is easier to work with text that I can easily copy while working with things.

I start from this equation on display …

and then invoke ts$ to pass from \[ ... \] to $...$. And this is what happens: …

Interesting example.

I will now get an error, as the $ sign has been put after a comment

Yes, I agree this is a bug, but I'm not sure I want to invest time in fixing it. It's slightly hard to fix, and it feels like a rare edge case.

I propose to have an intermediate stage between \[ ... \] or \begin{equation}... \end{equation} and $...$. With it I obtain the code below: …

Ok, how about doing it like this: We let the $ behaviour work as before, but instead of inlining with \(...\) we could let it behave similar to \[...\]. That's an easy update and would resolve your issue, I think. It may end up breaking other people's workflow, but not severely and I could rethink it if someone complains.

I proposed to have \(..\) by default not to try to join lines, and let those who want to join lines do another keypress and toggle until $..$.

Ok. I'll update and we can test it. But if it's OK by you I won't change the default value of g:vimtex_env_toggle_math_map. Thus, you will still have to add the \( rules to this option.

[lervag]

Please update and test if you find the changed behaviour more preferable.

Notice, for this to work with the ts$, you need something like this:

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

[MithicSpirit]

It may end up breaking other people's workflow, but not severely and I could rethink it if someone complains.

Yeah, this is slightly bothersome to me. I don't mind the originally proposed solution of not reformatting on multiline → \(, but the fact that \( → multiline no longer reformats is annoying to me.

In particular, I like to use \( exclusively for short math (≤30 characters), and instead switch to a math environment (using cs$) for anything longer than that. Before, this worked fine, but now the environment delimiters remain inlined, which is obviously undesirable and annoying to fix.

[lervag]

It may end up breaking other people's workflow, but not severely and I could rethink it if someone complains.

Yeah, this is slightly bothersome to me.

Sorry for the inconvenience!

I don't mind the originally proposed solution of not reformatting on multiline → \(, but the fact that \( → multiline no longer reformats is annoying to me.

That was a bug. I'm pushing a fix for it now. Please let me know how the updated version works for you.

In particular, I like to use \( exclusively for short math (≤30 characters), and instead switch to a math environment (using cs$) for anything longer than that. Before, this worked fine, but now the environment delimiters remain inlined, which is obviously undesirable and annoying to fix.

You will still find the changed behaviour where going from a multiline to \( no longer turns it back to inline. I'm curious to hear what you think about that.

[MithicSpirit]

I don't mind the originally proposed solution of not reformatting on multiline → \(, but the fact that \( → multiline no longer reformats is annoying to me.

That was a bug. I'm pushing a fix for it now. Please let me know how the updated version works for you.

I've been using it for a couple of days, and it works great. Thanks for the quick response!

In particular, I like to use \( exclusively for short math (≤30 characters), and instead switch to a math environment (using cs$) for anything longer than that. Before, this worked fine, but now the environment delimiters remain inlined, which is obviously undesirable and annoying to fix.

You will still find the changed behaviour where going from a multiline to \( no longer turns it back to inline. I'm curious to hear what you think about that.

This isn't really an issue for me. I rarely need to go back to inline, and when I do, I needed to reformat anyway; now, this just means I need to join the lines before doing that. Considering joining lines is a lot easier than splitting them, I think it's better to err on this side.

[lervag]

That was a bug. I'm pushing a fix for it now. Please let me know how the updated version works for you.

I've been using it for a couple of days, and it works great. Thanks for the quick response!

Great; glad to hear it!

... Considering joining lines is a lot easier than splitting them, I think it's better to err on this side.

Glad to hear that also. :)