Open westonruter opened 5 years ago
18 months later, is this likely to happen, or what's the currently known biggest obstacle?
I would also look to use this block as a syntax highlighting capable code editor to replace core HTML block, which still (approaching WP 5.6) has various annoying limitations.
It's not a high priority for me, personally. It can still happen though. The value is diminished by not being able to have the syntax highlighting while writing, since this is not the purpose of highlight.js.
I don't understand what you mean about this relates to the Custom HTML block in core. It seems like you're wanting syntax highlighting while editing the code? For that, the answer is CodeMirror which is already in core but not currently used in the editor due to its weight.
I know that this is just minor important, but it would be damn-cool ;-)
I just saw a brilliant way to achieve this: https://github.com/WebReflection/highlighted-code
Demo: https://javascriptweekly.com/link/124430/4968b3d1fc
(H/t JavaScript Weekly)
It works by having the text in the textarea
be color:transparent
and then for there to be an overlay with pointer-events:none
which actually contains the highlighted text which is constantly re-rendered with highlighting as typing is done. So smart. Plus this specific package is using highlight.js so it should have the same styling as we have on the frontend with highlight.php. Nevertheless, since the Code block in the Editor is not using textarea
it may not be able to be used directly, although the general approach should work. In fact, we already have this text overlay in the editor in order to implement the highlighted lines. So all we need to do is add the syntax highlighting to that overlay, and then make the actual edited text color:transparent
. This could be tackled as part of fixing https://github.com/westonruter/syntax-highlighting-code-block/issues/629.
One complication here I just realized: auto-detection of the language won't work in the editor since it is a feature of highlight.php not highlight.js. One possibility would be to create a new REST API endpoint to do the language detection, and the editor can use this for picking the language for highlighting in the editor when auto is selected.
Can't you auto detect at post publish time?
Not if the point is to have WYSIWYG syntax highlighting inside the editor. After entering code, you'd want to see how it would look syntax-highlighted without having to preview it on the frontend.
Since there wouldn't be any code to do the detection when the block is first inserted, the detection should perhaps happen once the block is initially unfocused. Otherwise, the detection could be re-calculated after X seconds debouncing.
Just noting I once pulled this off in a custom WordPress block essentially with this technique: https://css-tricks.com/creating-an-editable-textarea-that-supports-syntax-highlighted-code/
I probably have a copy of it laying around if helpful.
@chriscoyier Thanks! Looking at the Pen it does seem quite similar: text in the editable field be transparent, with that field overlaying another element that continuously updates with a mirror of the edited text with syntax-highlighting applied. What's different now in the WordPress Code block is that it's no longer using a textarea
but rather a pre > code[contenteditable=true]
.
(TIL: caret-color
!)
We could include support for previewing the syntax highlighting for a Code block by loading highlight.js into the editor, and using it to colorize the Code blocks.
In contrast to the Custom HTML block which has HTML and Preview tabs, we could have colorized text shown when the block is not selected, and then automatically colorize when de-selecting. Or perhaps the colorization should always be done when de-selected but then also provide a way to preview with tabs while it is selected.