-
-
Notifications
You must be signed in to change notification settings - Fork 59
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Syntax highlighting does not work #19
Comments
Could you please elaborate? |
Take a look at the highlight.js stylesheets ...
.hljs {
display: block;
overflow-x: auto;
padding: 0.5em;
background: white;
color: black;
}
.hljs-string,
.hljs-variable,
.hljs-template-variable,
.hljs-symbol,
.hljs-bullet,
.hljs-section,
.hljs-addition,
.hljs-attribute,
.hljs-link {
color: #888;
}
... All of the CSS classes have the prefix The highlight.js file does not set the class prefix. It is impossible for any of these styles to work. https://github.com/hexojs/hexo-util/blob/master/lib/highlight.js#L8 hljs.configure({
classPrefix: ''
}); Finally, the root class that applies the syntax background https://github.com/hexojs/hexo-util/blob/master/lib/highlight.js#L41 result += '<figure class="highlight' + (data.language ? ' ' + data.language : '') + '">'; |
Any news about this? I don't get how to use syntax highlighting otherwise. I expect to simply inline one of the packaged styles. npm install -S highlight.js And then in my @import "~highlight.js/styles/default"; Due to the mismatch between the classes of the HTML and classes of the stylesheet, it does not work. While looking at other themes, I cam across some solutions that seem a bit insane to me from a maintenance perspective.
Am I really expected to keep a hard copy of the packaged stylesheet (versioned in my repository) and manually edit it any time highlight.js is updated? |
As stupid as it is I'd say that's the preferable alternative given that there's not a whole lot to update in the stylesheets. Maybe you could use an older version of hljs from before the name scheme change with your mentioned method. As you mentioned, #29 is in the works and should at least solve the naming issues; the failing unit test is however a bit over my level so hopefully @NoahDragon can figure that out. |
Thanks for the reply. |
You could try out hexo-prism as an alternative if you'd like. Overall there's a lot to improve about hexo, but that's kind of what I like about it: nothing is quite set in stone, unlike other static site generators I've tried :) |
The problem is that I do not highlight my code myself. I use use the Markdown plugin which in turn uses this plugin. Of course I love the fact that Hexo is fully configurable, but it should still provide a good out-of-the-box experience. When I come to think about it, I find it a bit odd that code highlighting does not have its own repo. The other main features of this package seem to be about input sanitization and process spawning so separating code highlighting shouldn't have a big impact. After all, it's mostly a façade for |
@Krakob Thanks for poking me about this. I will take a look at #29 now before my procrastination arises. |
After thinking about it a bit more, I believe that part of the issue may caused by |
@demurgos The changes I mentioned should make it possible to drop-in any highlight.js stylesheet and have the theme work properly, since all the themes are now Ideally the hljs defaults should also be the defaults used by hexo-util, but unfortunately making the changes the new default breaks existing themes that use the old non-prefixed themes. I'm not a core maintainer so I didn't want to do that unless the maintainers believe it's the way ahead. For custom themes, it should be possible to have a high-level stylesheet in your preprocessor language of choice with a palette sheet that declares the variables. Your theme could then use that style and you'd get the best of both words. No need to transform the existing styles. One step further would be to have some sort of built-in support ( |
Anyone can give a brief description of the issue? |
In short, newer version of IMHO, since there are already many developed hexo-theme are using |
@SukkaW @curbengh the solution here is:
|
Adapt highlight css to fit the old version of For hexo, we should just deprecate |
@SukkaW I have a site without JS and intend to keep it that way. So I enjoy very much server side rendering :) |
FYI:
|
Atom's highlights is another candidate. The benchmark seems good. There are also many Atom-compatible themes that theme dev can adapt. In regards to #39, it seems to support support jsx. But the overall supported languages are still much less than highlight.js and prism. Most of the lang submodules haven't been updated (to their latest respective commit) for >3 years. Looking through the js highlight module, it seems some ES6+ syntax is not highlighted. I assume other langs are also not updated frequently as well. Anyway, why not support all? highlight.js (old & new syntax), atom highlights and prism in hexo-util would be nice. This way it doesn't break existing theme, while at the same time theme can choose whichever to support. If theme prefers client-side, can always disable server-side (currently it can be disabled). to illustrate: highlight:
enable: false|true #existing option
engine: highlight|atom|prism I concur with @tomap with having server-side rendering, personally I'm willing to sacrifice generation time to minimize the amount of client-side js. |
I suggest add support for prism first, and I love the |
This has been fixed in hexojs/hexo#2901 + #30 To prepend _config.yml
highlight:
+ hljs: true |
Feel free to re-open if the config doesn't work. |
syntax highlighting will definitely not work out of the box for highlight.js. the code does not have the necessary bits in place
The text was updated successfully, but these errors were encountered: