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

vimtex-env-change-math and indenting #1858

Closed
ces42 opened this issue Nov 17, 2020 · 31 comments
Closed

vimtex-env-change-math and indenting #1858

ces42 opened this issue Nov 17, 2020 · 31 comments

Comments

@ces42
Copy link
Contributor

ces42 commented Nov 17, 2020

I usually write inline math in my source, e.g.

I write simple math such as $y = x^2$ or $c = 1/a$ inline.

When I use \[ displaymath I usually write it in separate lines using indentation. Example:

The expression
\[
    \Chi(\mathcal{L}) = 1 - g(X) + \langle c_1(L), [X], \rangle
\]
is more complicated, so I indent it.

This is also the universal convention for equation, align, etc.

Describe the solution you'd like
It would be useful if (the very useful command) vimtex-env-change-math (i.e. cs$) would automatically adjust the formatting. That is cs$\[<CR> on inline math inserts three new lines containing \[, + the math, and \] respectively. Analogously it would be handy if cs$$<CR> on a displaymath expression such as

\[
    \Chi(\mathcal{L}) = 1 - g(X) + \langle c_1(L), [X], \rangle
\]

were to convert it to a single line $\Chi(\mathcal{L}) = 1 - g(X) + \langle c_1(L), [X], \rangle$ (though its not clear whether completely inlining it into the surrounding text is desirable).

It would probably be best to make the format-aware cs$ optional. I was thinking that it could depend on the argument provided to the command, i.e. \[ is format-aware while \[ remains the same.

Describe alternatives you've considered
An alternative solution to this problem (I'm not sure if this has been implemented already) would be to have a functionality that allows (de-)inlining math.

@lervag
Copy link
Owner

lervag commented Nov 17, 2020

I think this sounds like a pretty good idea. I'm quite busy at the moment, but I'll look into it when I get the time.

@lervag
Copy link
Owner

lervag commented Feb 7, 2021

Ok, so, summarized: The current behaviour is:

text $math$ text
% ci$\[ ---->
text \[math\] text

text
\[
  math
\]
text
% ci$$ --->
text
$
  math
$
text

You are proposing to change this to the following:

text $math$ text
% ci$\[ ---->
text
\[
  math
\]
text

text
\[
  math
\]
text
% ci$$ --->
text $math$ text

Am I right? This would also fit with my personal style, so I am generally positive to making this change. I'm curious if it should be updated with a new option, e.g. g:vimtex_delim_changemath_autoformat, so that the old behaviour can be retained. I don't like adding new options, so in a way I would prefer not. But should I expect anyone to be annoyed with making this change?

@ces42
Copy link
Contributor Author

ces42 commented Feb 7, 2021

Yes, that is what I had in mind.

There might be a small use case for indented $-math in source code: If a formula is short enough to be displayed inline but the source for it is very messy (e.g. due to \operatorname or \prescript) people might want to write it indented in the source code.
What is the drawback of adding new options?

@lervag
Copy link
Owner

lervag commented Feb 12, 2021

There might be a small use case for indented $-math in source code: If a formula is short enough to be displayed inline but the source for it is very messy (e.g. due to \operatorname or \prescript) people might want to write it indented in the source code.

Yes, but people can of course write exactly what they want, when they want. This kind of formatting features only work well if they provide the expected feature 99% of the time, and then it is not a problem if one has to manually tweak things sometimes.

What is the drawback of adding new options?

Increased complexity for user customization. In general, the more options, the more likely it is that someone will not configure VimTeX optimally. Also, more options means more complexity in the code and more things to maintain (both in code and documentation). More work. More things that can go wrong. And VimTeX is already quite complex and it takes a lot of time to maintain it.

However, I don't mean I can't or won't add new options. Just that I only do so after careful consideration. And in this case, I'm fealing that an option might not really be necessary, because I would expect this feature would be welcomed by everyone. But I'm not 100 % sure about that...

@vneiger
Copy link

vneiger commented Jan 26, 2022

Since this seems to be waiting for user opinions: I cannot speak for others, but the suggested change would be perfect in my case as well. Nothing urgent at all, but it would be a welcome enhancement.

@lervag
Copy link
Owner

lervag commented Jan 27, 2022

Thanks, @vneiger - I think I've waited for user opinions here, yes. And there's been a lot of other issues getting in the way (and life, work, in general). In any case, thanks for bumping.

I'll implement the described behaviour in not too long. First without an option. Then I'll consider an option if there should be complaints afterwards. :)

@vneiger
Copy link

vneiger commented Jan 27, 2022

Yes, maybe unfortunately, in general it seems easier to get spontaneous user opinion from angry users than from the numerous happy ones. So the most efficient way to know if many people don't like the change might be to do the change, indeed... In any case my goal was not to add any pressure, this does not seem like an urgent change. Whenever you find the time. And thank you for the amazing work on vimtex!

@lervag
Copy link
Owner

lervag commented Jan 27, 2022

Thanks for the kind words! And don't worry - by commenting here you got my attention and I still believe this is a relatively easy thing to implement. So I'll just do it, as I think it will also improve my own writing workflow :)

lervag added a commit that referenced this issue Jan 27, 2022
WIP: This implements cs$ -> $, it remains to implement cs$ -> \[.

refer: #1858
@lervag
Copy link
Owner

lervag commented Jan 27, 2022

I've implemented half of this now. Can you please test? I.e., cs$$ should now work more or less as expected for turning \[ ... \] to $...$.

@ces42
Copy link
Contributor Author

ces42 commented Jan 27, 2022

Current behavior in the following situation

	indented text

	\[
		m = a t_h
	\]
	More text

is to turn this into

	indented text
 $m = a t_h$ More text

arguably this has the wrong indentation. Maybe this should check whether the line above the math is empty and if so use the indentation of the line with \[ instead of the indentation of the above line?

It's also unclear whether it's desirable to remove the empty line between "indented text" and the displaymath (although the answer probably is yes).

@vneiger
Copy link

vneiger commented Jan 27, 2022

I've implemented half of this now. Can you please test? I.e., cs$$ should now work more or less as expected for turning \[ ... \] to $...$.

Thanks!

  • Concerning the above remark, I had almost the same: testing with non-indented text and a white line above the displayed math content, then after the action the resulting inline math content replaces the white line but starting with a whitespace character, which was surprising. In fact I'm not sure the empty line should be removed, since in my way of writing tex, I almost never have an empty line before a displayed formula, so when I have one it must be for some good reason (but that might not be the common practice).
  • One additional remark: for consistency it may be nice to also replicate this behavior for cs$\( instead of cs$$, and I suppose the former could enclose the math content in \(...\) rather than $...$

lervag added a commit that referenced this issue Jan 28, 2022
lervag added a commit that referenced this issue Jan 28, 2022
@lervag
Copy link
Owner

lervag commented Jan 28, 2022

Now I've implemented the opposite direction and a new command ts$ to toggle between inline and displayed math. As you've noticed, there are kinks. The best way to solve them is to get examples of situations in which it does not work as expected. Preferably in the form of:

  1. A minimal tex snippet before doing cs$.
  2. Indicate if it is cs$$ or cs$\[.
  3. The expected output.

@clason
Copy link
Contributor

clason commented Jan 28, 2022

To muddy the waters even further, what I most often wish for is a shortcut for changing \[...\] to \begin{equation*}...\end{equation*}...

(Easily enough done using :%s/.../... -- just adding this for the sake of completeness while these things are thought about.)

@lervag
Copy link
Owner

lervag commented Jan 28, 2022

@ces42

Current behavior in the following situation ...

I agree - the indents should be corrected here and the empty line should not be deleted. The empty line indicates a paragraph separation, but a displayed math environment could be the start of the paragraph as well. I'll add this to the tests and figure it out.

@vneiger

One additional remark: for consistency it may be nice to also replicate this behavior for cs$\( instead of cs$$, and I suppose the former could enclose the math content in \(...\) rather than $...$

Yes, I believe you are right. There is also $$ which acts like displayed math. Should that work similar to \[ as well?

@clason

To muddy the waters even further, what I most often wish for is a shortcut for changing \[...\] to \begin{equation*}...\end{equation*}...

Perhaps ts$ could toggle between $...$, \[...\] and \begin{equation*}...\end{equation*} as a three-way toggle?

@clason
Copy link
Contributor

clason commented Jan 28, 2022

Perhaps ts$ could toggle between $...$, [...] and \begin{equation*}...\end{equation*} as a three-way toggle?

Hmmm... I feel that those are orthogonal: inline vs. display and short form vs. long form. If anything, I'd include the equation* form in the command that toggles between $...$ and \(...\) (so it has two behaviors, depending on whether it's in inline and display math)? In this case, one could even extend it to the transformation

$$ ... $$    ->     \[ ... \]    <->    \begin{equation*} ... \end{equation*}

(so you can use it to remove -- but never add! -- "TeXisms" as well as toggle between the two valid LaTeX variants)?

@clason
Copy link
Contributor

clason commented Jan 28, 2022

(Just brainstorming a bit, not saying your suggestion is bad!)

@vneiger
Copy link

vneiger commented Jan 28, 2022

Yes, I believe you are right. There is also $$ which acts like displayed math. Should that work similar to [ as well?

I'm not sure that it is a good idea to add support for $$ (which is similar to displayed math but not the same, and advised against, see this discussion ).

One thing about \begin{equation} : this may not work if the package amsmath is not loaded. In which case, a general toggle could result in the code not compiling if some package is not loaded... not sure this sounds good (?).

what I most often wish for is a shortcut for changing [...] to \begin{equation*}...\end{equation*}

From \[...\] we can easily switch to the version with equation, by something like cs$eequation and then pressing enter. Just like we can also already change between inline and displayed math. But this is in some way different in spirit from the original question here, which was more about nice formatting when toggling between inline math vs displayed math.

@clason
Copy link
Contributor

clason commented Jan 28, 2022

I'm not sure that it is a good idea to add support for $$ (which is similar to displayed math but not the same, and advised against, see this discussion ).

Note that my proposal never adds $$, it only ever removes it (because it is indeed advised against)!

From [...] we can easily switch to the version with equation, by something like cs$eequation and then pressing enter.

But not back -- which wasn't my motivation, but easily could be someone else's. So I still think a toggle may be useful.

lervag added a commit that referenced this issue Jan 28, 2022
@vneiger
Copy link

vneiger commented Jan 28, 2022

I'm not sure that it is a good idea to add support for $$ (which is similar to displayed math but not the same, and advised against, see this discussion ).

Note that my proposal never adds $$, it only ever removes it (because it is indeed advised against)!

Yes yes, which sounds better: never offer $$ towards \[ . (I was commenting on @lervag 's earlier suggestion, not yours that appeared in the meantime and I only read after posting mine ;-) )

@lervag
Copy link
Owner

lervag commented Jan 28, 2022

I believe we have multiple threads going now. So let's first finalize the original topic. I believe I've addressed the first feedback on it and that it should now work more or less as expected. Feedback is of course still welcome, though!

Reg. \(...\) and $$...$$, I believe these are handled OK right now. I.e., we can still use cs$ to change to these, but it will not apply any more magic.

The second topic is ts$, which is new. I believe it makes sense to keep it between $...$ and \[...\] as the general toggle, but to allow to use it on other constructs. Something like this:

$$ ... $$                              →   $ ... $   ↔  \[ ... \]
\( ... \)                              →  \[ ... \]  ↔   $ ... $
\begin{equation*} ... \end{equation*}  →   $ ... $   ↔  \[ ... \]

As an alterantive, we could use a three-way toggle, but it could go to unstarred form \begin{equation} instead?

@clason
Copy link
Contributor

clason commented Jan 28, 2022

Sorry for muddying the waters... Feel free to ignore this if it is too far off-topic here.

But I should point out that your "three-way proposal" has a few inconsistencies; I'd prefer

  1. the order "TeX -> LaTeX -> display/inline toggle"
  2. \(...\) is valid; I don't think that should be a one-way street
  3. the critical (i.e., currently not easily done) direction is actually \[ -> \begin{equation*}, which your proposal doesn't allow.

And we already have tse for equation<->equation*; I'd not include that here.

@lervag
Copy link
Owner

lervag commented Jan 28, 2022

You are discussing the ts$ command here, right? Not the cs$? If so, perhaps we could move that discussion to a new thread to make it easier to follow up correctly? (I assume you consider cs$equation* to be "not easily done", which I would partly agree with.)

@clason
Copy link
Contributor

clason commented Jan 28, 2022

I believe so; since the discussion had already touched both, I just thought it would be useful to bring up the additional use case in case it changes the options.

@clason
Copy link
Contributor

clason commented Jan 28, 2022

(I assume you consider cs$equation* to be "not easily done", which I would partly agree with.)

I consider it easily enough done; my point was the other direction: cs$ does not work on \begin{...}...\end{...} math environments. (Of course, a toggle would be even easier, but that's just convenience, not functionality.)

@lervag
Copy link
Owner

lervag commented Jan 28, 2022

Ok, sounds good. Then I would be happy if you could open a new issue and address the current behaviour of ts$ and explain (probably copy your above posts) how you believe it should work. A "map" similar to the ones we've posted would be useful. We'll let this thread now consider the cs$ behaviour as was the original topic.

And yes: I agree that it would be convenient to improve cs$ to also work for math environments. That's perhaps an additional issue - but it's fine to combine with the ts$ because they are very connected.

@lervag lervag closed this as completed Jan 28, 2022
@lervag
Copy link
Owner

lervag commented Jan 28, 2022

I'm closing this issue as resolved, but please don't hesitate to continue the discussion if something does not work as expected! (Or open new issues.)

@vneiger
Copy link

vneiger commented Jan 28, 2022

It looks good now concerning the above discussed issues. However, concerning the change to \(...\), currently when I do cs$\( in a displayed equation \[ ...\], it keeps the formatting of the latter on several lines. If it is not difficult to do, could it rather replicate exactly the behavior for $...$? Both syntaxes $...$ and \(...\) are for inline math and are strictly equivalent (unlike \[...\] and $$...$$ which are not equivalent as highlighted above).

Some people prefer \(...\) to have different opening and closing symbols, e.g. to facilitate search and replace with regexps. It is not necessarily more typing, if you use snippets.

@vneiger
Copy link

vneiger commented Jan 28, 2022

To be maybe more clear, in short, I would expect:

text
\[
  math
\]
text
% ci$\( --->
text \(math\) text

whereas currently the behavior is

text
\[
  math
\]
text
% ci$\( --->
text
\(
  math
\)
text

@clason
Copy link
Contributor

clason commented Jan 28, 2022

To be fair, I've seen the second variant more frequently among those who actually use the asymmetric form.

(I don't, so don't take this as an actual vote for anything.)

@vneiger
Copy link

vneiger commented Jan 28, 2022

Ah, ok. I wouldn't have guessed it this way (I do not know many people who use \(...\), unfortunately?). Then, maybe, we should forget my comment, and keep it as it is.

@lervag
Copy link
Owner

lervag commented Jan 28, 2022

It's unclear to me which is the most frequently used form. But for the sake of experimenting, I'll be glad to just adjust according to @vneiger's suggestion and consider a revert if there are complaints. The change is more or less trivial.

lervag added a commit that referenced this issue Jan 28, 2022
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

4 participants