Skip to content
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

Why chose client-side code highlighting over builtin server-side func? #28

Closed
jostyee opened this issue Apr 8, 2018 · 13 comments
Closed
Labels

Comments

@jostyee
Copy link
Contributor

jostyee commented Apr 8, 2018

Hugo does support code highlighting since version 0.28 adopted from Chroma, by which we don't need the highlight javascript library to do the job, I wonder why @xianmin chose not to use it?

Some other themes for comparison:

@xianmin
Copy link
Owner

xianmin commented Apr 8, 2018

Thanks for your feedback!
This project Initial version is olOwOlo/hugo-theme-even. Hugo-theme-even use highlight.js library, and for me, the style of the show is not bad. So I did not modify it.

I haven't tested the Chroma yet. Maybe we can try it? 😄

@jostyee
Copy link
Contributor Author

jostyee commented Apr 8, 2018 via email

@jostyee
Copy link
Contributor Author

jostyee commented Apr 8, 2018

IMHO server-side highlighting pros:

  1. faster loading time
  2. less 3rd-party dependencies, make it easier to maintain
  3. friendly to some readability services(e.g. Instapaper cannot parse highlight.js code block properly)

while client-side highlighting can:

  1. render more language syntaxes for now.

@xianmin
Copy link
Owner

xianmin commented Apr 9, 2018

Yes, less 3rd-party dependencies is better.
If we choose Chroma finally, and if anyone still want use highlight.js , I think he could use custom head and custom.js do it.

The highlight.js works fine for now. If you are interested in switch to Chroma, maybe you could try it first, and I am very supportive. 😄

@jostyee
Copy link
Contributor Author

jostyee commented Apr 9, 2018

@xianmin You've hardcoded highlight invocations in main.js , which cannot be changed by config checks.

@xianmin
Copy link
Owner

xianmin commented Apr 9, 2018

If Chroma works fine, maybe we could remove all highlight.js related code.
Or put it on hold first, wait for me to deal with this later.

@Zebradil
Copy link
Collaborator

I'd like to have this migration done. Tell me if anybody is working on this. If not, I can do it.

@jostyee
Copy link
Contributor Author

jostyee commented Apr 17, 2018

@Zebradil I'm currently busy at my work, please give it a go if you have time, thanks.

@Zebradil
Copy link
Collaborator

@jostyee, I'll go for it this week then.

@Zebradil
Copy link
Collaborator

@xianmin, what is the highlight style used? It looks like solarized-light, but it's not the same.

Current style:
screen shot 2018-04-21 at 14 31 04

Solarized-light from https://github.com/john2x/solarized-pygment/:
screen shot 2018-04-21 at 15 17 40

@xianmin
Copy link
Owner

xianmin commented Apr 22, 2018

@Zebradil This highlight style is good! If anyone wants change the style, I think they could use custom css.

@jostyee
Copy link
Contributor Author

jostyee commented Apr 22, 2018

@Zebradil great work, thanks.
@xianmin Chroma has multiple syntax highlighting presets itself, see: https://help.farbox.com/pygments.html with pygmentsUseClasses = false

@jostyee jostyee closed this as completed Apr 22, 2018
@Zebradil
Copy link
Collaborator

Another way to change style is to use hugo's gen command:

hugo gen chromastyles --style=native > style.css

With this approach it's possible to tune highlight style manually.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

3 participants