# Cooking with C++
**URL:** https://meta.discourse.org/t/cooking-with-c/187974
**Category:** Development
**Created:** [April 24, 2021, 8:45am UTC](https://meta.discourse.org/t/cooking-with-c/187974 "2021-04-24T08:45:19Z")
**Posts on this page:** 8
**Page:** 1
### Author:  [@Hubbe](https://meta.discourse.org/u/Hubbe)
#### Post date: [April 24, 2021, 8:45am UTC](https://meta.discourse.org/t/cooking-with-c/187974/1 "2021-04-24T08:45:19Z")
(First post, so bear with me…)
I recently set up my own Discourse forum: [https://crucible.hubbe.net/](https://crucible.hubbe.net/) for the most part I’ve been very happy with it. The community is for an arduino-type board used mostly for prop makers. As such, we end up using a lot of templated C++ code. In particular, we use this thing called a “style” which configures how lights show up. Styles can be complicated, so I wrote an online previewer/editor, then I used the discourse-linkify theme component to make it so that styles are automatically linked to the editor. I had to make some minor changes to the discorse-linkify theme component to make it quote URL characters and stuff, which was easy enough, and I can create a PR for those changes if there is interest.
The result can be seen here: [StylePtr links - The Crucible - The Crucible](https://crucible.hubbe.net/t/styleptr-links/286)
However, there is a problem…
Some of the templated code ends up looking a bit like HTML because of all the \< and \> characters, and at some point Discourse removes some of those “tags”. Basically, it seems like any unknown word encased in \< \> gets removed. The next line in this post will be \< foo \> but without the spaces:
\< - the foo is here
At first I thought it was the linkfy component that was doing something wrong, but after some digging, it seems that the missing stuff is already gone by the time linkify runs. So I guess the extra tags evaporated somewhere in the cooking process?
I noticed that in code blocks (triple-backtick and similar) the tags do survive, but for my purposes it would be better if they _always_ survived.
For a while I thought that it would be sufficient to modify discourse/lib/utilities.cs:CODE\_BLOCKS\_REGEXP to make this work, but inCodeBlock isn’t used from a lot of places, so maybe that’s wrong? Also, I have not figured out how to actually modify CODE\_BLOCKS\_REGEXP from a plugin or theme component yet.
What code is actually responsible for removing these tags?
What is the best (most supported) way to disable it?
---
### Author:  [@Hubbe](https://meta.discourse.org/u/Hubbe)
#### Post date: [April 24, 2021, 10:55pm UTC](https://meta.discourse.org/t/cooking-with-c/187974/2 "2021-04-24T22:55:34Z")
I should also point out that because people sometimes paste big blocks of code, it can be very difficult to tell that some parts in the middle went missing. At the very least, it would be better if unknown tags were turned into blinking warning signs or something that lets the user know that something unexpected happened.
---
### Author:  [@TheBestPessimist](https://meta.discourse.org/u/TheBestPessimist)
#### Post date: [April 25, 2021, 6:32am UTC](https://meta.discourse.org/t/cooking-with-c/187974/3 "2021-04-25T06:32:01Z")
Question: why not try to use markdown code blocks?
Just surround your code in triple backticks: ` character.
Like this
```plaintext
here
is
```
An this is the actual raw markdown of my post: [https://meta.discourse.org/raw/187974/3](https://meta.discourse.org/raw/187974/3)
* * *
You will have to educate your users, but this is your job as a moderator, plus it will help every user who has to deal with markdown later down the line.
You could do this by adding a new global pinned topic, something like “How to embed code on this site” or “How to type on this site”.
You can also direct them to this link: [Markdown Reference (commonmark.org)](https://commonmark.org/help/)
---
### Author:  [@spirobel](https://meta.discourse.org/u/spirobel)
#### Post date: [April 25, 2021, 7:09am UTC](https://meta.discourse.org/t/cooking-with-c/187974/4 "2021-04-25T07:09:34Z")
Okay I just wanted to drop this link here as well in case anyone else has the same problem.
> [@(Superseded) Plugin Tutorial #1 - How to manipulate the text in the composer?](https://meta.discourse.org/t/plugin-tutorial-1-how-to-manipulate-the-text-in-the-composer/10925):
>
> information_source This topic has been superseded by [Developing Discourse Plugins - Part 1 - Create a basic plugin](https://meta.discourse.org/t/developing-discourse-plugins-part-1-create-a-basic-plugin/30515) So, you want to manipulate the text in the composer but have no idea how? Let met guide you through the creation of a basic plugin that will turn the text into [Pirate Speak](http://en.wikipedia.org/wiki/International_Talk_Like_a_Pirate_Day). tada Update August 2018: you can create a complete discourse plugin skeleton in your plugins directory with [Rails plugin generator](https://meta.discourse.org/t/rails-plugin-generator/95907) tada First of all, you need to create a plugin.rb file that will b…
It seems like adding backticks and a link using the same pattern that the piratize plugin uses, would solve the challenge.
---
### Author:  [@Hubbe](https://meta.discourse.org/u/Hubbe)
#### Post date: [April 25, 2021, 8:26am UTC](https://meta.discourse.org/t/cooking-with-c/187974/5 "2021-04-25T08:26:16Z")
> [@TheBestPessimist](#):
>
> why not try to use markdown code blocks?
Because I have better things to do than to hurd cats?
If there is an easy way and a right way to do things, people will _always_ pick the easy way. I suppose if I could actually prevent people from putting StylePtr\<\> templates outside of pre-formatted text, then people would be forced to do the right thing, but how do I do that? (Also, it feels like a very heavy-handed solution, as it could also prevent perfectly valid ways to talk about StylePtr\<\> templates.)
My current solution for linking StylePtr\<\> templates using linkify also doesn’t work on pre-formatted text because the DOM is very different, but that’s a minor problem that I can probably fix with a little coding.
> [@spirobel](#):
>
> It seems like adding backticks and a link using the same pattern that the piratize plugin uses, would solve the challenge.
Maybe. I think what I would do is to use this pattern to automatically add the backticks if they aren’t there, and then use a post-cooking callback for linking. Unless I’m mistaken, there is no way to add a link in the middle of some pre-formatted text otherwise.
---
### Author:  [@gerhard](https://meta.discourse.org/u/gerhard)
#### Post date: [April 25, 2021, 9:47am UTC](https://meta.discourse.org/t/cooking-with-c/187974/6 "2021-04-25T09:47:53Z")
Encouraging users to use backticks for inline code and 3 backticks for code blocks is the best solution. Maybe create a pinned topic about that in your forum?
In addition to that you could give [Unformatted Code Detector](https://meta.discourse.org/t/unformatted-code-detector-theme-component/112773) a try.
---
### Author:  [@Hubbe](https://meta.discourse.org/u/Hubbe)
#### Post date: [April 26, 2021, 6:51pm UTC](https://meta.discourse.org/t/cooking-with-c/187974/7 "2021-04-26T18:51:46Z")
The unformatted code detector theme component seems promising.
Then I just have to make a theme component that handles the linking inside preformatted code, which I was planning to do anyways. I will definitely give this a try.
---
### Author:  [@Hubbe](https://meta.discourse.org/u/Hubbe)
#### Post date: [April 27, 2021, 6:11am UTC](https://meta.discourse.org/t/cooking-with-c/187974/8 "2021-04-27T06:11:55Z")
Turns out that all I had to do was to enable multiline regexp support in the linkify module to make it work more like I wanted to. So I think I’m good, assuming people actually pay attention to the unformatted code detector.