Forem: hedy

Setting up syntax highlighting for Hugo

hedy — Sun, 22 Aug 2021 00:00:00 +0000

Cross-posted from: https://hedy.tilde.cafe/posts/hugo-syntax-highlighting/

Hugo uses chroma as its syntax highlighter, and it’s mostly compatible with pygments. All you basically need for having your code highlighted is to let chroma put the syntax classes in the generated HTML, for the correct language, and then make sure you have corresponding CSS for those classes.

Let’s start by enabling syntax highlighting in your configuration file.

In your configuration file, config.toml for example, add these settings so you can have your code highlighted and have it recognize Fenced Code Blocks for markdown:

pygmentsUseClasses = true
pygmentsCodeFences = true

Next you have to include the styles. There are two ways to go about this, one is to choose a style from the list of available styles (more on that below), and the second method is to use your own syntax theme.

You can have your own CSS styles, but there are a lot of classes, so if you’re just starting out and want to have it working quickly, you should choose an existing style.

Browse the gallery of available styles and use that style name to save the CSS file into your assets directory:

mkdir -p assets/syntax
hugo gen chromastyles --style=friendly > assets/syntax/main.css

If you’d like to use different styles for dark mode and light mode (like me), then you can change “main.css” to “light.css”, and save the dark mode style to “dark.css”. It doesn’t matter where you put the file, but just remember to use that file name with referencing it later.

You don’t have to put it under the directory “syntax” too, if you don’t want to.

Apply the styles

You have to link to your CSS file that you’ve just created in your <head>. There are several ways you can do so.

Use a <link> tag and link to the URL of your CSS file, or
directly put the content of your file into a <style> tag.

Here’s how you can do the second method.

{{- $syntaxCSS := resources.Get "syntax/main.css" | minify -}}
<style>
    {{ $syntaxCSS.Content | safeCSS }}
</style>

Assuming your CSS file is at assets/syntax/main.css.

All set for the styling part! Now you can write some content and try it out.

Remember to include the file type when putting code in markdown.

This is not sh


```sh
# this is sh
echo "hi"
```

Dark mode and light mode

You can have different styles of syntax highlighting for dark mode and light mode.

First you have to export or save your CSS for dark mode and light mode in separate files . Then, change the part in your <head> where you’ve included the styles:

{{- $syntaxlight := resources.Get "syntax/light.css" | minify -}}
{{- $syntaxdark := resources.Get "syntax/dark.css" | minify -}}
<style>
    {{ $syntaxlight.Content | safeCSS }}
    @media (prefers-color-scheme: dark) {
        {{ $syntaxdark.Content | safeCSS }}
    }
</style>

This assumes you have your light styles and dark mode styles stored inassets/syntax/light.css and assets/syntax/dark.css respectively.

Instead of doing the above, you could have just put both in a single file and include the @media (prefers-color-scheme: dark) line in there directly, and this won’t require you to change your <head> at all. And of course you could have just used CSS variables and store the theme’s colors into different variables, use var(--variable-name) for each class in the styles, and finally have a different set up variable values for @media (prefers-color-scheme: dark) {}. But using the method of separating dark and light styles has the advantage of changing the themes for light or dark mode in the future with thechroma command and pipe it to the file directly, without having to edit the CSS file by hand.

Applying syntax highlight CSS file only when it’s needed

Fetching syntax highlighting theme and putting it in your <head> means that every single page would have the syntax highlighting CSS code in the page, regardless of whether the page actually uses it. If you’d like to only include the syntax CSS files for pages that needs syntax highlighting, you can use a page parameter named something like highlight.

Here’s how it would work.

Set a highlight param in your global config file that is set to false by default
For each post or page in your content/ that needs syntax highlighting, include highlight: truein the frontmatter (assuming you’re using YAML).
In <head>, check whether the page’s highlight param is set to true, and only if it’s true, the CSS resource is loaded.

In your <head>, include this before fetching the CSS resource, and put{{ end }} after </style>:

{{- if .Params.highlight -}}
<!--Put the code that fetches your syntax highlight CSS here-->
{{- end -}}

This tells hugo to only load the resource and put the CSS in <style> if the page parameterhighlight is set to true.

There are many configuration options for syntax highlighting, read this page on Hugo docs for more information: gohugo.io/getting-started/configuration-markup#highlight

If you’d like to highlight specific lines in code snippets, you can read about how to do that here: gohugo.io/content-management/syntax-highlighting/#example-highlight-shortcode

There is also a highlight shortcode shipped with Hugo that lets you manually highlight code with chroma: gohugo.io/content-management/shortcodes/#highlight.

Managing multiple emails for git across different computers

hedy — Wed, 16 Jun 2021 23:50:00 +0000

Cross-posted from: https://hedy.tilde.cafe/posts/multiple-emails-git/

—

As someone who code on multiple machines to work on different projects, I like to commit with different emails.

I don’t know how everyone else handle different emails in .gitconfig and track dotfiles in a git repo at the same time, but here’s the solution I’ve come up with.

First, I have a global ~/.gitconfig with the default user email and some other global settings (by global I mean same cross different computers I work on).

# ~/.gitconfig
[user]
name = Default Name
email = me@default.email

Then for each machine I have a ~/.gitconfig-local file which can override some settings just for that machine, such as email, signing key, editor, etc.

# ~/.gitconfig-local
[user]
email = me@special.email

Back in the global ~/.gitconfig, I have this snippet that tells git to also look for configuration in my ~/.gitconfig-local:

# ~/.gitconfig
[include]
path = ~/.gitconfig-local

Here, I can have ~/.gitconfig tracked in my dotfiles repo, but I do not have ~/.gitconfig-local tracked. This way, I can put anything I like specific to a particular machine in the ~/.gitconfig-local, as well as SMTP settings such as password, which you wouldn’t want to end up in a public git repo.

As to setting it up on a new machine, I have a setup script in my dotfiles repo that creates an empty ~/.gitconfig-local. I use this same method with fish configs – global config and a local config, you can have a look at them in my dotfiles repo.

Control the Probability of This GitHub Action from Passing/Failing

hedy — Sat, 22 Aug 2020 04:47:48 +0000

Just give it a percentage, say 50, and it will have a 50/50 chance of passing! Which means if you give it 0 or 10, it will fail all the time and most of the times respectively. 😏 Pretty cool right?

GitHub repo

hedyhli / passibility

✅ Control the probability of this Github action from passing/failing!

How to use this

name: "Will I Pass..."
on: push

jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: hedythedev/passibility@main
        with:
          percentage: 100

Example Workflow: This workflow will pass all the time!

Option Inputs

percentage

Percentage of passing - (without the %) 0, for always fail, 100 for always pass and so on.

Additional info

This is my first GitHub action, and it’s written in JavaScript.
Generated from the JavaScript Action Template
Unit tests using Jest
This isn’t a submission to the Actions Hackathon because I’m not old enough (18+ only), but I made this to experiment with GitHub Actions
Feel free to try it out and give me some feedback
Contributions welcome - like having another input called fail_percentage so you can instead provide the fail probability? 🤔
Remember to ⭐ star the project if you liked it ;)