lervag / vimtex

VimTeX: A modern Vim and neovim filetype plugin for LaTeX files.
MIT License
5.51k stars 389 forks source link

Inconsistent spacing of concealed math symbols #3002

Closed Unturned3 closed 4 weeks ago

Unturned3 commented 4 weeks ago

Description

When concealing the \big command in math mode, the indentation & spacing of the concealment is messed up. Same issue happens for \bigg, \Big, \Bigg.

Steps to reproduce

Run nvim -u minimal.vim minimal.tex.

minimal.vim

set nocompatible
let &runtimepath  = '~/.local/share/nvim/plugged/vimtex,' . &runtimepath
let &runtimepath .= ',~/.local/share/nvim/plugged/vimtex/after'
filetype plugin indent on
syntax enable
set conceallevel=2

minimal.tex

\documentclass{minimal}
\begin{document}
\begin{align}
    \big| x \big|
\end{align}
\end{document}

Expected behavior

Concealed display:

\begin{align*}
        |x|
\end{align*}

Actual behavior

Concealed display:

\begin{align*}
| x|
\end{align*}

Do you use a latexmkrc file?

No

VimtexInfo

System info:
  OS: macOS 12.7.1 (21G920)
  Vim version: NVIM v0.10.1
  Has clientserver: true
  Servername: /var/folders/3d/_tm29bhn48l851qxdsg5w39m0000gn/T/nvim.ut/7TudbN/nvim.23134.0

VimTeX project: minimal
  base: minimal.tex
  root: ~/bug
  tex: ~/bug/minimal.tex
  main parser: current file verified
  document class: minimal
  compiler: latexmk
    engine: -pdf
    options:
      -verbose
      -file-line-error
      -synctex=1
      -interaction=nonstopmode
    callback: 1
    continuous: 1
    executable: latexmk
  viewer: General
  qf method: LaTeX logfile
lervag commented 4 weeks ago

When concealing the \big command in math mode, the indentation & spacing of the concealment is messed up. Same issue happens for \bigg, \Big, \Bigg.

Thanks; I've updated to fix this now.

However, please note: you probably want to use the \bigl and \bigr variants.

Unturned3 commented 4 weeks ago

Thanks! I thought using \bigl and \bigr with the vertical bar | symbol (absolute value) would allow me to jump between matching pairs using the % key, but it seems like that vimtex only recognizes brackets (e.g. \bigl[ ... \bigr]) as valid pairs for % jumping. Is this intentional?

lervag commented 3 weeks ago

Thanks!

No problem!

I thought using \bigl and \bigr with the vertical bar | symbol (absolute value) would allow me to jump between matching pairs using the % key, but it seems like that vimtex only recognizes brackets (e.g. \bigl[ ... \bigr]) as valid pairs for % jumping. Is this intentional?

Yes, or at least, in part. The % motion and similar functionality was built with a restriction that the delimiters was properly identifiable. Proper delimiters like ( and ) are supported, also with the various modifiers applied.

You are right that in this case, the modifiers could be used to properly recognize if | is the left or right hand, e.g. \bigl | is clearly a left-side delimiter.

When I built this, I've built it using the restriction as an assumption. Thus, to fix it, I would need to generalize and improve the logic, and it is not really trivial. And since there is already another plugin that does this and does it much better than VimTeX, I think the proper thing to do here is to instead refer to that plugin: vim-matchup. It is very good, and it provides the improved % and similar for a host of other filetypes as well. I can heartily recommend it!

Unturned3 commented 3 weeks ago

Gotcha, I'll give vim-matchup a try. Also, I just noticed the same issue with the \right command (i.e. collapsing spaces to its left):

Source:

\begin{align}
    \left(
        x
    \right)
\end{align}

Expected concealed display:

\begin{align}
    (
        x
    )
\end{align}

Actual concealed display:

\begin{align}
    (
        x
)
\end{align}
lervag commented 3 weeks ago

Gotcha, I'll give vim-matchup a try.

I don't think you'll be sorry!

Also, I just noticed the same issue with the \right command (i.e. collapsing spaces to its left): …

Ah, yes - the current rules will eat the preceding white space. The idea was to have $\left( y \right)$ display as (y) regardless of the amount of whitespace.

But, to be honest, I'm not sure if I still think this is a good idea. It feels more robust to preserve the whitespace. If people don't want the whitespace, they can simply remove it.

If you agree, then I think I'll just make this change, even though some people might find it "breaks" their workflow.

Unturned3 commented 3 weeks ago

Perhaps a compromise would be to collapse the whitespace if there is some non-whitespace character before it on the same line, and preserve whitespace otherwise (to maintain the indentation)?

I do agree that preserving the whitespace is more robust (and useful). Sometimes I intentionally put whitespace before/after these \left ... \right bracket pairs to clearly delinate equation boundaries, especially for longer ones.

lervag commented 3 weeks ago

Perhaps a compromise would be to collapse the whitespace if there is some non-whitespace character before it on the same line, and preserve whitespace otherwise (to maintain the indentation)?

Nah, this means more conditions and more logic that may be wrong. I think we have two choices:

I think I'll go with the breaking change, because it "feels" right. I'll revert later if I get a lot of complaints. 😅

lervag commented 3 weeks ago

Or - I'm not sure. Given $\left\lvert x\right\rvert$ - I'd want to swallow the mandatory space before the x, else it would look strange: | x| instead of |x|. So, this really is harder than it seems.

lervag commented 3 weeks ago

Perhaps I could reduce this to only swallow a single space?

Or, perhaps I should reconsider the more advanced path: If the right delimiter is the first part of a given line, then it should not swallow the spaces.