Support code snippets highlight in various listings

[XVilka]

Is your feature request related to a problem? Please describe it. If you have a construction like

\lstset{language=rust,numbers=none}
\begin{lstlisting}
fn main() {
    println!("Hello World!");
}
\end{lstlisting}

It would be amazing to enable the syntax highlight for this piece of code,

Describe the solution you'd like The best example of handling such things is the vim-markdown plugin, it has the method to handle this: https://github.com/plasticboy/vim-markdown#fenced-code-block-languages

This is how the highlighting implemented: https://github.com/plasticboy/vim-markdown/blob/master/ftplugin/markdown.vim#L700

And this is how it looks in my setup:

[lervag]

The feature already exists for many cases, see :help vimtex-syntax. I'll see if I can add it for this example as well, but it is harder then others because the environment commands are separated from the specification command \lstset. I think I would need to restrict to cases where the command and environment is "coupled", i.e., the command must come just before the environment. Do you think this is OK?

[XVilka]

@lervag yes, this solution would work, thank you!

[kiryph]

What about supporting following placement of the language specification:

\documentclass{article}
\usepackage{listings}

\begin{document}

\begin{lstlisting}[language=C]
#include<stdio.h>
main() {
  int i = 0;
  printf("Hello World");
}
\end{lstlisting}

\end{document}

[lervag]

Thanks, @kiryph! @XVilka, would this form be acceptable to you? It is much easier to implement, since I can rely on previous implementations.

[XVilka]

@lervag yes, that would work.

[XVilka]

Just the explanation, where you can meet the construct I posted initially. It is generated by the Emacs from the org mode, e.g. if you have this in the *.org file:

#+NAME: hello world
#+BEGIN_SRC rust  :export none :comments link
fn main() {
    println!("Hello World!");
}
#+END_SRC

it will generate the following TeX output:

\lstset{language=rust,label=org99998e,caption= ,captionpos=b,numbers=none}
\begin{lstlisting}
fn main() {
    println!("Hello World!");
}
\end{lstlisting}

See their documentation: https://orgmode.org/manual/Source-blocks-in-LaTeX-export.html#Source-blocks-in-LaTeX-export

[kiryph]

I cannot resist: this is not emacs 😈 😃 .

[XVilka]

@kiryph well, Vim understands orgmode too: https://github.com/jceb/vim-orgmode

[kiryph]

My comment was mainly a joke. Sorry for the noise.

Back to the issue:

Now, I've read the readme of vim-orgmode and noticed that export to other formats is indeed delegated to Emacs-orgmode.

So I guess you still would like to have syntax highlighting for listings as exported by emacs-orgmode.

However, I would find the better solution to change the export of emacs-orgmode.

Lervags proposal

I think I would need to restrict to cases where the command and environment is "coupled", i.e., the command must come just before the environment.

can be broken who does not know that the lines have to be coupled. IMHO this fulfills emacs-orgmode but does not handle the general case from someone who writes his/her own latex files. I can also easily imagine that someone cleans up redundant \lstset{language=rust,label=org99998e,caption= ,captionpos=b,numbers=none} lines and breaks syntax highlighting in vim with vimtex.

Proper support of \lstset{} would avoid those issues, which btw might end up here on the issue tracker, but requires tracking them in latex files.

Syntax highlighting is performance critical which means I would not put too much burden on it.

IMHO support of a global and a local setting should be good enough. Switches can be distributed over the whole project which can mean several files and therefore are computationally more expensive.

[XVilka]

I think it makes sense to allow to set the lstset once per buffer, indeed.

[lervag]

I've just pushed initial support for nested highlighting of lstlisting environments. Currently, only the "simple" form is allowed where [language=...] is used to specify the language. I think it is well documented, but let me know what you think!

[XVilka]

Thanks! I tested it, seems to work fine 👍 I see you match the ending ] of [language=... construction. What about dropping it? Or adding also , match? So constructions like this one would work fine:

\begin{lstlisting}[language=C++,
                   directivestyle={\color{black}}
                   emph={int,char,double,float,unsigned},
                   emphstyle={\color{blue}}
                  ]
% ...
\end{lstlisting}

[lervag]

Done. I also added support for the \lstset variant, as long as the \lstset command appears just before the \begin{lstlisting} command (i.e. separated only by whitespace and/or newlines). It should work on all of your current examples.

[XVilka]

Thank you very much! Amazing job.

[lervag]

No problem, and thanks. I'm currently working on further improvements that I hope may make everything more automatic. I.e., that you don't need to specify the vimtex_syntax_minted and ..._listings options to allow different nested languages.

[lervag]

Please note that recent updates has generalized/abstracted some code. This is in preparation for doing what I mentioned above. A consequence is that I've introduced the new option g:vimtex_syntax_nested_ignored where one can set the ignored groups for an included language. The goal is to keep this at a sensible default so that most people do not need to modify it.

Thus, people who have used the g:vimtex_syntax_minted (and the new listings variant) with the ignored keys need to update their configuration.

[lervag]

Update: Things should now work quite seamlessly for listings package. There should be close to no need for setting any options for it.

Note: The latest commit changes how g:vimtex_syntax_minted is configured. I am sorry for breaking backwards compatibility, but I am heading for (hopefully) a configuration-independent solution.

[lervag]

Update: Things should now work seamlessly also for the minted package. The option g:vimtex_syntax_minted has been deprecated and will have no effect.