I’m using api.decorateCooked() for this, but since the content is already cooked all “redundant” space has been removed, e.g. the space before printf in the example above.
How can I get access the “uncooked” text as the user entered it?
To be clear; what I want to support with my theme component is to allow the user to write something like:
Sadly our free, standard and business tiers do not allow for custom plugins. We use a cluster that hosts many different customers we have no mechanism of running a plugin just for one customer.
Supporting the ability to inject a markdown extension via a theme component is something I have thought about in the past, but we have no concrete plans to add it. It would be extremely hard to add.
What about double wrapping? This will certainly keep all indentation.
[wrap=test]
```
1
1
3
```
[/wrap]
Maybe even just using something like this will work, you will have a distinct element to work with:
Extremely hard also for you or just for someone like me without prior knowledge of the implementation? I what lies the hardness? Would it be easier to do something simpler than a full markdown extension such as read-only access to raw?
The front end does not get the raw post content. It only gets the cooked version. This means that payloads to the client are smaller. On top of that the server is ultimately responsible for the markdown → html conversion. If we did this all at runtime on the browser we would be adding a lot of extra costs and have complicated security vectors to worry about.
Just to be clear, you do know that if what you really want is coffee blocks you can wrap code blocks with three back ticks, right? I can’t tell to what degree your example is a metaphor.
@pfaffman I don’t know what you mean by coffee blocks, but yes, I do know that three backticks generate a code block.
I don’t know why my example should be a metaphor. For what? The image I posted is a screenshot to show what my theme component generates for the given code.
Yes, I guess so. I haven’t seen the math plugin, but it sounds similar in concept. It’s the same basic function as the Graphviz Plugin, but this one can do much more advanced stuff, like animated transitions between graphs and has a whole bunch of options to control and style it.
Here is the GitHub repo if you’re interested. It’s not officially deployed anywhere yet because I need to write detailed documentation on how to use it first.
Then it works seem, and perhaps I’m missing something, that the solution would be so submit your changes as a PR and then our would be available on business plans.
Sorry, I don’t understand what you mean. It’s a theme component and it can be installed into any discourse instance through the web interface by it’s administrator regardless of which plan they’re on.
I likely don’t understand. But it seemed that what you want to do is to extend the graphviz-plugin to support more graphviz features and that they would make more sense integrated into that plugin.
But I don’t really understand what you’re after, so I could be way off base.
Now I understand what you meant. No, since we’re on a free plan, we couldn’t use that plugin and therefore I developed a theme component instead. The extra features was a kind of bonus that were easily added because it’s based on another library than the existing plugin.
Plugins and theme components are very different so I don’t think it’s possible to reuse code between them, but I guess it would be possible for someone to add the same functionality to the existing plugin should they be interested.