Option to turn off downlit?

[njtierney]

Could md_document gain an argument to not apply downlit ?

There was previously an option with hugo_document to switch on downlit

However it looks like that option has been removed now in md_document.

While I think that downlit is awesome, and I love the idea, at the moment I don't want to generate links to functions, as it seems to change the colours I get. Here's an example of what I meant:

Compare using downlit (from md_document) in this post

To not downlit (from hugo_document) in this post

I think that this issue with syntax highlight maybe has to do with downlit being used?

I have tried to follow the config guidelines as close as I could, but perhaps I've missed something in my blog set.

[hadley]

I'd rather fixing the underlying problem than giving you the ability to turn it off (although it's probably worth doing that eventually, I'd prefer to force myself to confront highlight issues at the moment).

Also in the second post, I see:

So there may be other issues.

Have you added the chroma classes to your css?

[njtierney]

Fair enough! Syntax highlighting is hard, thanks for taking this on.

It looks like I may have introduced some issues, perhaps. Between now and then I have updated config.toml to add pygmentsUseClasses = true.

I ran hugo gen chromastyles --style=monokai on the command line and wasn't really paying attention - it generated some nice css for me, but I guess I was kind of half expecting that it would add this to my repo in the right spot automagically (too many expectations from how usethis works perhaps!)

So perhaps I'm just missing all the CSS? If so, is it expecting a special name of the CSS file and where should it live?

/* Background */ .chroma { color: #f8f8f2; background-color: #272822 }
/* Other */ .chroma .x {  }
/* Error */ .chroma .err { color: #960050; background-color: #1e0010 }
/* LineTableTD */ .chroma .lntd { vertical-align: top; padding: 0; margin: 0; border: 0; }
/* LineTable */ .chroma .lntable { border-spacing: 0; padding: 0; margin: 0; border: 0; width: auto; overflow: auto; display: block; }
/* LineHighlight */ .chroma .hl { display: block; width: 100%;background-color: #ffffcc }
/* LineNumbersTable */ .chroma .lnt { margin-right: 0.4em; padding: 0 0.4em 0 0.4em;color: #7f7f7f }
/* LineNumbers */ .chroma .ln { margin-right: 0.4em; padding: 0 0.4em 0 0.4em;color: #7f7f7f }
/* Keyword */ .chroma .k { color: #66d9ef }
/* KeywordConstant */ .chroma .kc { color: #66d9ef }
/* KeywordDeclaration */ .chroma .kd { color: #66d9ef }
/* KeywordNamespace */ .chroma .kn { color: #f92672 }
/* KeywordPseudo */ .chroma .kp { color: #66d9ef }
/* KeywordReserved */ .chroma .kr { color: #66d9ef }
/* KeywordType */ .chroma .kt { color: #66d9ef }
/* Name */ .chroma .n {  }
/* NameAttribute */ .chroma .na { color: #a6e22e }
/* NameBuiltin */ .chroma .nb {  }
/* NameBuiltinPseudo */ .chroma .bp {  }
/* NameClass */ .chroma .nc { color: #a6e22e }
/* NameConstant */ .chroma .no { color: #66d9ef }
/* NameDecorator */ .chroma .nd { color: #a6e22e }
/* NameEntity */ .chroma .ni {  }
/* NameException */ .chroma .ne { color: #a6e22e }
/* NameFunction */ .chroma .nf { color: #a6e22e }
/* NameFunctionMagic */ .chroma .fm {  }
/* NameLabel */ .chroma .nl {  }
/* NameNamespace */ .chroma .nn {  }
/* NameOther */ .chroma .nx { color: #a6e22e }
/* NameProperty */ .chroma .py {  }
/* NameTag */ .chroma .nt { color: #f92672 }
/* NameVariable */ .chroma .nv {  }
/* NameVariableClass */ .chroma .vc {  }
/* NameVariableGlobal */ .chroma .vg {  }
/* NameVariableInstance */ .chroma .vi {  }
/* NameVariableMagic */ .chroma .vm {  }
/* Literal */ .chroma .l { color: #ae81ff }
/* LiteralDate */ .chroma .ld { color: #e6db74 }
/* LiteralString */ .chroma .s { color: #e6db74 }
/* LiteralStringAffix */ .chroma .sa { color: #e6db74 }
/* LiteralStringBacktick */ .chroma .sb { color: #e6db74 }
/* LiteralStringChar */ .chroma .sc { color: #e6db74 }
/* LiteralStringDelimiter */ .chroma .dl { color: #e6db74 }
/* LiteralStringDoc */ .chroma .sd { color: #e6db74 }
/* LiteralStringDouble */ .chroma .s2 { color: #e6db74 }
/* LiteralStringEscape */ .chroma .se { color: #ae81ff }
/* LiteralStringHeredoc */ .chroma .sh { color: #e6db74 }
/* LiteralStringInterpol */ .chroma .si { color: #e6db74 }
/* LiteralStringOther */ .chroma .sx { color: #e6db74 }
/* LiteralStringRegex */ .chroma .sr { color: #e6db74 }
/* LiteralStringSingle */ .chroma .s1 { color: #e6db74 }
/* LiteralStringSymbol */ .chroma .ss { color: #e6db74 }
/* LiteralNumber */ .chroma .m { color: #ae81ff }
/* LiteralNumberBin */ .chroma .mb { color: #ae81ff }
/* LiteralNumberFloat */ .chroma .mf { color: #ae81ff }
/* LiteralNumberHex */ .chroma .mh { color: #ae81ff }
/* LiteralNumberInteger */ .chroma .mi { color: #ae81ff }
/* LiteralNumberIntegerLong */ .chroma .il { color: #ae81ff }
/* LiteralNumberOct */ .chroma .mo { color: #ae81ff }
/* Operator */ .chroma .o { color: #f92672 }
/* OperatorWord */ .chroma .ow { color: #f92672 }
/* Punctuation */ .chroma .p {  }
/* Comment */ .chroma .c { color: #75715e }
/* CommentHashbang */ .chroma .ch { color: #75715e }
/* CommentMultiline */ .chroma .cm { color: #75715e }
/* CommentSingle */ .chroma .c1 { color: #75715e }
/* CommentSpecial */ .chroma .cs { color: #75715e }
/* CommentPreproc */ .chroma .cp { color: #75715e }
/* CommentPreprocFile */ .chroma .cpf { color: #75715e }
/* Generic */ .chroma .g {  }
/* GenericDeleted */ .chroma .gd { color: #f92672 }
/* GenericEmph */ .chroma .ge { font-style: italic }
/* GenericError */ .chroma .gr {  }
/* GenericHeading */ .chroma .gh {  }
/* GenericInserted */ .chroma .gi { color: #a6e22e }
/* GenericOutput */ .chroma .go {  }
/* GenericPrompt */ .chroma .gp {  }
/* GenericStrong */ .chroma .gs { font-weight: bold }
/* GenericSubheading */ .chroma .gu { color: #75715e }
/* GenericTraceback */ .chroma .gt {  }
/* GenericUnderline */ .chroma .gl {  }
/* TextWhitespace */ .chroma .w {  }

[hadley]

Yeah, you'll need to put them somewhere in static. What hugo theme are you using?

[jemus42]

@njtierney Where that CSS goes and how you include it depends on your theme, some themes like hugo-coder have a parameter for that.
In that case you'll need to set it to a path (relative to your static folder), so e.g. if you put the css in /static/css/syntax.css you'd set custom_css = ["css/syntax.css"] -- but please note that this is only the way to go for this particular theme, and the way how (if at all) additional CSS files are included in the theme can vary greatly theme by theme.

Worst case scenario would be you'd have to override a template file in /layouts/, but I doubt that's necessary with most themes.

[njtierney]

I'm using a modified version of hugo/xmin.

OK, I got this to work!

Thanks for the advice, @jemus42 and @hadley

Here is what I did.

• added CSS into static/css/syntax.css. (I actually just copied the one from tidyverse, after tinkering with a few themes I just decided I'd go with one I knew I liked).
• Added a reference to the CSS in layouts/partials

I actually tried to write some R code to capture the css generated with

hugo gen chromastyles --style=colorful

As recommended in hugodown congif vignette

But I couldn't capture the outputted CSS to clipboard or with sink/readlines. I'm probably missing something. But I was imagining that it would be pretty neat to have a function like:

generate_highlight_css(flavour = "colorful", path = "static/css/syntax.css")

And then some potential instructions regarding where you could refer the CSS (e.g., layouts/partials/ or something?)

Anywho, we've gotten a bit off track now, but there it is.

[njtierney]

One quick thought I have is whether the ligatures are somehow controlled via downlit, or is that a CSS thing? For example, pre, and post:

I guess it is the difference between:

#> ── Attaching packages ─────────────────────────────────────── tidyverse 1.3.0 ──

and

#> -- Attaching packages ------------------------------------------------- tidyverse 1.3.0 --

One is a nice straight line, and the other is a series of dashes, not sure if that is something that downlit is changing.

[jemus42]

I don't think this is a CSS thing, my hypothesis is that --- gets converted to a box drawing character either on the knitr- or pandoc-level? I copypasted the "solid line" characters into google and that came up first ¯\_(ツ)_/¯ .

Anyway, this is at the HTML, not CSS level (even though attached CSS classes differ as well), see example HTML output here:

• Hugodown: https://github.com/jemus42/hugodown-testing/blob/master/public/hugodown-rmarkdown/index.html#L207 — solid ─'s
• Blogdown .Rmarkdown: https://github.com/jemus42/hugodown-testing/blob/master/public/blogdown-rmarkdown/index.html#L284 — all -'s

It might be that this is related to the knitr print method that gets called there when library(tidyverse) tries to figure out whether it can print fancy characters or if it should stick to - for maximum compatibility, but I'm out of my depth there.

EDIT: Oh, and the "fancier" output also uses proper tick-marks instead of the v, so I think that also indicates that in one case a fancy Unicode-ready print method is used and in the other a safer, ASCII-only print method is used – which is a long way to say "maybe downlit can change this".

[hadley]

This is from cli::is_utf8_output(), so hugo_document() just needs to set options(cli.unicode = TRUE).

[njtierney]

Hi @hadley, thanks for that!

This thread sort of turned into an issue about many things, so I can understand why you closed it. I was wondering if you were still considering adding an option to turn off/on downlit? Or perhaps the takeaway is that downlit is baked into hugodown.

[hadley]

I might eventually add it, but I don't want to give people an easy opt out at this point.