[Feature Request] Interpolation Expression in code block (Allow no v-pre at code block)

[fago]

I'm using vue press 0.8.4 for technical docs and generally works great, thanks a lot for the great project!

However, we'd like to use variable expansion in markdown code. Example, a code block like

```
cd ~/projects/{{ $project }}/vcs/
```

would show cd ~/projects/{{ $project }}/vcs/ although the variable $project is registered. It works correctly when markdown code formatting is not used.
Is there a way to make variable expansion / vue processing of markdown processed html work?

This feature would allow the technical docs to use replacement patterns where meaningful, so any changes to those docs can be done easily by changing the variables.

[meteorlxy]

Good point.

Currently, the <pre> tag that parsed from markdown has a v-pre on it by default.

We could add some extra config to disable it

[ulivz]

Can you provide the component <code> you mentaioned or reproduced repo?

[meteorlxy]

@ulivz He means the ```
i.e

```
cd ~/projects/{{ $project }}/vcs/
```

[meteorlxy]

@fago Currently, you can use <pre><code>cd ~/projects/{{ project }}/vcs/</code></pre> in your makrdown file. That means:

// from
```
cd ~/projects/{{ $project }}/vcs/
```

// to
<pre><code>cd ~/projects/{{ project }}/vcs/</code></pre>

---update

After d0ef06f, you have to use it like:

<div class="language-text"><pre><code>cd ~/projects/{{ project }}/vcs/</code></pre></div>

See #422

[ulivz]

@meteorlxy

Please don't measure a problem as I think it is. and please give a solution after the problem is clear, otherwise it will bring a lot of noise.

[meteorlxy]

@ulivz Alright, alright. I'll notice my words. I removed that "I think". What he said is:

markdown code formatting

So that is ```

[fago]

sry for the delay here. As discussed, yes I've been referring to markdown code formatting, thus

 ``` 

I was not aware of the <pre><code> trick to make github print ``` - I fixed my original post now. Hope it's clear now.

[MartinMuzatko]

@meteorlxy this does not get the job done.

<div class="language-text"><pre><code>cd ~/projects/{{ project }}/vcs/</code></pre></div>

I would like to have syntax highlighting. How do I perform that then? :/

Having the option to remove v-pre from code blocks would be nice.

Currently, the <pre> tag that parsed from markdown has a v-pre on it by default.
We could add some extra config to disable it

[hustjiangtao]

I recommend a better choice:

::: pre
cd ~/projects/{{ $project }}/vcs/
:::

[meteorlxy]

@MartinMuzatko

I haven't worked on vuepress for about two months, maybe there are some new features that make the workaround fails.

Syntax highlighting currently conflicts with vue's interpolation, because of the markdown parsing workflow of vuepress. See https://github.com/vuejs/vuepress/pull/415/files#diff-9780d43a67a5ff4083a22bab7ae331a8R107.

[MartinMuzatko]

I see. Keep on with the good work anyway @meteorlxy :) You are a great contributor :D

[ulivz]

Sorry for the delay, there are some reasons for shelving #415:

1. The syntax v: isn't very semantic, it just created a new syntax but didn't consider the integration with hignlightLines,

   My suggestion is to name as {no-v-pre}.

2. As docs in feat: allow no v-pre on code blocks (#413) #415 said:

   For some language identifiers, the highlighter will add extra <span> tag around { and }, in which cases :v won't work. Suggest to use :v after text, md, vue, html or use it alone.

   That is, if you write {{ xx }} at .js file, the {{ would be corrupted by prism at the build time. for common users, this is quite counterintuitive —— Why are there such restrictions?

3. Since the birth of vuepress, highlighting was always finished at build time, so any content inserted by interpolation will not be highlighted —— since we never highlight code at any runtime. this would be a requirement from some users, like @MartinMuzatko

Conclusion

Thus, the reasonable workaround at the moment is that when user uses interpolation in a language code block where the interpolation expression would be corrupted by highlighting, our build process should not highlight its code by default, or user might receive strange errors.

And for highlighting code at runtime, I suggest to create a plugin for it since most of users will not have the requirement of highlighting dynamic code.