Textpattern CMS support forum
You are not logged in. Register | Login | Help
- Topics: Active | Unanswered
Re: Prism for html preview in write tab
philwareham wrote #298062:
The reason it doesn’t render on the plugin install page is because of the PHP built-in highlighter which is already used there.
Yeah but even after removing that, it still didn’t render properly in the help block. The code block looked great… aside from the fact it showed every line so you had to endlessly scroll past it to reach the install button.
that whole install process is horrible UX anyway.
I quite like it, as it gives me a chance to:
- Copy plugin source code without installing it. For example, if I have a newer version of a plugin installed already on my dev box but need to check the current official release due to a regression, it saves me hoping the author is using git and has tagged a release for that version.
- Read docs. Some authors don’t put docs on their site so I can see if the plugin fits the bill without committing to installing it first.
- Nose around the code first to check it’s not doing anything untoward or likely to clash with something I already have installed.
If our plugin template format wasn’t obfuscated, I agree none of the above steps would be necessary. But as a coder, they’re damn handy.
It makes no sense to provide an automatic fallback for code highlighting
Yes and no. Without a fallback, adding PrismJS now is only of benefit for future plugin releases if textile can be beaten into submission or code blocks are rendered manually by plugin authors. But if we can safely assume that the majority of code blocks in help docs are going to include xml-style markup to assist people using new tags that the plugin introduces, then having a fallback at least gives some immediate benefit to existing plugins right now.
Guess it depends what would happen to a PHP block or a CSS block if the fallback was “markup”. Would it break horribly? If so, then I agree that a fallback is a useless feature, and I question why the designers of PrismJS added it at all.
The real issue here is Textile’s inability to allow a class on the inner
<code>tag of a<pre><code>pairing. That should be fixed.
As discussed on that Textile issue, if we could assume that [lang] for a bc. meant a programming language hint instead of a natural language, then yeah. It would mean unpicking the code that handles [lang] glyphs though, as it’s been factorised into a separate function. Or we’d need to come up with some other tag for it. e.g. bchi. for highlighted code blocks whereby the classes get applied to the <code> not the <pre> wrapper.
If we go with the [lang] route though, I think the language- prefix should be implied, since it’s in the spec. Textile is all about trying to shorten syntax and typing. Forcing people to type [language-php] is annoying, even if it’s more flexible. My take is that if the spec says a syntax-highlighting language hint class name begins with language- then highlighting tools should respect that, not invent their own. PrismJS does it right.
The smd plugin menagerie — for when you need one more gribble of power from Textpattern. Bleeding-edge code available on GitHub.
Txp Builders – finely-crafted code, design and Txp
Offline
Re: Prism for html preview in write tab
Prism assumes that this language definition is inherited. Therefore, if multiple <code> elements have the same language, you can add the language-xxxx class on one of their common ancestors.
So, in theory, because of this fallback behaviour, a wrapper <pre> block is a “common ancestor” of the <code> tag it contains, therefore gets the language assigned to the <pre>. I admit it didn’t work well when I tried it, but I might have used the wrong language tag.
EDIT: I tried language-html which doesn’t appear in the list of supported languages. But then one of their own highlighted examples on the same page uses language-svg which also doesn’t appear in the supported list at the bottom of the page… go figure.
Last edited by Bloke (2016-02-29 13:19:16)
The smd plugin menagerie — for when you need one more gribble of power from Textpattern. Bleeding-edge code available on GitHub.
Txp Builders – finely-crafted code, design and Txp
Offline
Re: Prism for html preview in write tab
Yes, Prism is compatible with Textile Markup :
I use it since 2013 in my website
See my test :
memento.sacripant.fr/testPrism/
Prism select [class*="language-"] code too
See prism-core line 159
Last edited by sacripant (2016-02-29 13:34:55)
Offline
Re: Prism for html preview in write tab
Offline
Re: Prism for html preview in write tab
sacripant wrote #298070:
See prism-core
Ooooh, we can also use lang-* as shorthand. Neat, thanks for the hint.
And as for language-markup, I’ll give it another go sometime when I’m not not distracted.
The smd plugin menagerie — for when you need one more gribble of power from Textpattern. Bleeding-edge code available on GitHub.
Txp Builders – finely-crafted code, design and Txp
Offline
Re: Prism for html preview in write tab
Might this simple prism-based syntax-highlighted textarea be a good match for syntax highlighting textile / markdown fields in the Write panel?
Micro Code Editor codepen sample
Related project by the same author: Codeflask
The advantages:- Would make use of the existing prism resources
- Minimal, no line numbering etc.
- Very lightweight compared with other full-blown solutions
- Potentially stylable via prism
TXP Builders – finely-crafted code, design and txp
Offline
Re: Prism for html preview in write tab
Meanwhile, it’s a good idea to make your first plugin for txp 4.6 :)
Offline
Re: Prism for html preview in write tab
Still think Txp should adopt Markdown as core and make Textile the alternate filter. Especially as it seems Textile development is on it’s last leg.
Offline
Re: Prism for html preview in write tab
Destry wrote #298228:
Still think Txp should adopt Markdown as core and make Textile the alternate filter. Especially as it seems Textile development is on it’s last leg.
If it’s feature complete and bug free, there really isn’t a need for further development.
Offline
Re: Prism for html preview in write tab
Well, feature complete and bug-free are debatable sooner or later.
I’d like to see definition lists changed to something more Textile obvious, similar in idea to how tables can be notated. For example:
dl(class).
; Title
: DataAnd I’d like to see hard rules added:
hr(class).So wether Textile is bug-free as is, what does that say about making it better?
But the real point I was making is that Textile isn’t as popular as Markdown, not even fractionally close. It just doesn’t make sense to cling to it as a default filter anymore, sentimental reasons aside. Make it an alternate filter instead of the core default and you still get the best of both worlds (plus active Markdown development).
Offline
Re: Prism for html preview in write tab
But the real point I was making is that Textile isn’t as popular as Markdown, not even fractionally close. It just doesn’t make sense to cling to it as a default filter anymore, sentimental reasons aside.
I disagree with this reasoning.
War of PHP CMS is over! Textpattern is an alternative. He continues to exist because he is different. And theses differences allowed him to retain users.
Textpattern must cultivate its difference. this is not a story of sentimental reasons
Do as global thinking may, however, be fatal to Txp.
Yes, markdown must be an option, Textile must be an option, Wysiwyg must be an option. But want to make the same choice as the other is not necessarily a good idea.
Offline
Re: Prism for html preview in write tab
sacripant,
Switching the default role of Markdown and Textile has nothing to do with any “CMS war”, whatever that is, nor does it influence anything about the functional integrity of core Txp.
What it does enable, however, is the likelihood that more people in the world will try Textpattern, and especially as it would more easily accommodate the content produced in other editing tools that typically support Markdown but not Textile (iA Writer, Ulysses, Draft, GitHub Pages, GatherContent, etc, etc, etc). That’s a very practical and sensible reason to make the reversal.
As an editor that routinely works with contributing authors, I can tell you that many are beginning to know Markdown though use of their other writing tools, while none have ever heard of Textile.
Stubbornly refusing to accommodate other leading tools on the market because of favoritism for an abandoned language is very much an expression of sentimentalism, and more likely to be the demise, you suggest, of a CMS.
Don’t get me wrong, I prefer Textile too, for personal use, and I can keep using it either way. But I’m not so sentimental as to be blind to the practical value otherwise — for the project itself.
Last edited by Destry (2016-03-14 12:07:38)
Offline