Conditional indent (`\if`, `\fi`, `\else`)

[mrajner]

Indenting of conditional

Currently block between \if and \endif is not indented by default. As it is matter of taste vimtex could support optional indention of that syntax.

Introduction of g:vimtex_indent_delims (c146852) allows to mimic this behaviour with settings like

let g:vimtex_indent_delims = {
    \ 'open' : ['\\if'],
    \ 'close' : ['\\fi'],
\}

However it will give the result

\ifnum=1
    Hello world!
   \else
   Bye world!
\fi

The problem is with single line \else which should have temporary decreased indent (only for that line) and restored immediately. To keep the consistency, flexibility of user choice, I would suggest adding another entry in g:vimtex_indent_delims.

let g:vimtex_indent_delims = {
    \ 'open' : ['\\if'],
    \ 'close' : ['\\fi'],
    \'hanging':['\\else']
\}

So in the same manner one could provide a list of regex for hanging lines.

PS Be aware that it should be also regular expression to give full customization.
Also the example with '\\if' and '\\fi' are very simple ilustration.
Actually this expression should be like
'\(\\newif\)\@<!\\if\(field\|name\)\@!' to avoid indenting commands without ending \fi
like defining \newif\ifmyconditional or \iffieldundef or \ifnameundef from biblatex/biber commands, where action for true and false are just given in arguments without ending \fi.
Also closing should be changed to '\\fi\>' so it want parse for instance \field.
But the correct regex is up to user.

[lervag]

I'm not very accustomed to \if type of commands in LaTeX. I would like to have a sort of sane default, e.g. something like:

let g:vimtex_indent_conditionals = {
    \ 'open': '\\if\%(num\|false\)\?\>',
    \ 'else': '\\else'
    \ 'close': '\\fi',
\}

I would suspect it suffices with a single regex here, no need for a list. I'll look into this a little bit now. I think I want to keep this separate from delimiters and use a different option.

[lervag]

Ok, first version of this is added. It is probably not perfect. As an example of this, the current version assumes that all conditionals are written linewise, e.g., there are never two clauses on a single line, such as \if...\else. We can probably improve this, but let's start simple.

The first thing is to find a good default setting for the regexes.

[mrajner]

Good job. I agree that simple regex should suffice (until one encounter very specific case, which I do not foresee now).
Everything works well with your test case. However I would change the initial value for open,
yours inclusive list

'open': '\v\\if%(num|false)?>'

allows only \if, \ifnum and \iffalse (why not \iftrue also?). But inclusive list is impossible to define.
You can define any conditional name with syntax as below

\newif\ifenglish % define new conditional

\ifenglish
  \usepackage[english]{babel}
\else
  \usepackage[polish]{babel}
\fi

So the list of possible \if... is open. I set just opening regex to

'open' : '\(\\newif\)\@<!\\if\(field\|name\|numequal\)\@!'

so it will properly indent this example with \ifenglish but will not start on defining \newif, and there are few \if starting word which I already figured out to be not closed by \fi.
You could leave your defaults, as this is customizable, and one can always adapt it for his needs. But if you would like to support also users without knowledge of regexps, you may want to use more sophisticated initial setting (I will of course notify you if I found other exceptions).
The else and close dictionary entries seems to be fine. Some very localized situation could require change it a little (package algorithmicx adds among others \EndIf and \Elsif). But this is very localized problem.

PS If I try to set only one dictionary entry

let g:vimtex_indent_conditionals = {
 \ 'open' : '\(\\newif\)\@<!\\if\(field\|name\|numequal\)\@!'
\ }

then it does not work. Is that on purpose?

[mrajner]

And about linewise. If you see some TeX mastery there could be many mixing conditionals statements in one line. And here vimtex failed (I just checked). But that should be no problem, as the package developer will do not want any indenting of this condensed statements.
The checking of undefined variables if often, but it works for example like

\ifdefined\myvar\else
  hello world!
\fi
So I will not bother nested if in one line.

[mrajner]

and another exception (\ifthenelse)

'open' : '\(\\newif\)\@<!\\if\(field\|name\|numequal\|thenelse\)\@!'

[lervag]

I've updated the default values per your suggestion, and I've also updated so you can set only a single key without affecting the other defaults.

Regarding linewise: I think it can be possible to implement support for more complex constructs. But I don't know how "necessary" it is. How often do people write such expressions without structuring it "logically"?

Please don't hesitate to open a new issue if you want me to look into supporting more complex constructs where the current implementation breaks.

[mrajner]

Yes, all works good. I do not really know why you prefer introducing another key 'disabled' instead of using empty dictionary to disable indenting of conditionals, but that is as I understand part of design (I think that this is not uniform within different settings in vimtex, thought).
I do not also think that more complex structures are really needed. Fortunately when \if\else are compound in one line, all works. Much more complicated nested, compacted conditionals are not likely in tex files (might be in classes and packages), and in my opinion are not worth of considering in advance.
Great solutions as for now.

[lervag]

A moment of confusion from my part. I think checking for an empty dictionary is still better, so I'll revert that part. Thanks for raising the issue and for the useful comments!

[mrajner]

Yes, that is better idea, I did not want to suggest you that directly, as it is your right to decide on user interface, but now I admit it is better. And just information: it still works if you set only one of open|close|else regex (the other are then assumed default) -- I think this is correct and expected behavior.