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.

Sign up for GitHub

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

Jump to bottom

Choice of language class for fenced code blocks with the highlightjs-lang extension #370

Closed
dkasak opened this issue Sep 17, 2020 · 3 comments · Fixed by #380
Closed

Choice of language class for fenced code blocks with the highlightjs-lang extension #370

dkasak opened this issue Sep 17, 2020 · 3 comments · Fixed by #380

Comments

@dkasak
Copy link
Contributor

dkasak commented Sep 17, 2020

Currently, if the highlightjs-lang extension is enabled, the language of the fenced code block will be added as a HTML class to the code element. E.g. for Python code blocks, a python class will be added to the block.

However, a more common and interoperable technique is to prepend the language name with language-, e.g. language-python. This is mentioned in the WHATWG HTML standard and is expected by a variety of other tools and clients (an example being the Element Matrix client). I personally encountered this issue while trying to use urlwatch (which depends on python-markdown2) to send Markdown reports to Matrix.

Would you consider changing this or adding a configuration option for it?
@dkasak dkasak mentioned this issue Sep 17, 2020
Merged
@nicholasserra
Copy link
Collaborator

Seems sane. Any issues if we kept both? aka class="python language-python" to support this new standard and also in case anyone is depending on the old way? I'm going to peek the current tests to see if this is even checked.

@nicholasserra
Copy link
Collaborator

In current tests it seems whoever implemented it just assumed the input text would include the language- string, as opposed to prepending it in the code.

https://github.com/trentm/python-markdown2/blob/master/test/tm-cases/highlightjs_lang.text#L5-L11

@dkasak
Copy link
Contributor Author

dkasak commented Sep 18, 2020

In current tests it seems whoever implemented it just assumed the input text would include the language- string, as opposed to prepending it in the code.

That's not a very common usage, in my experience. Usually you'd only write the language name there, as in the first example.

Any issues if we kept both?

None that I see. I tested it in a few places and it works great. I think this would probably be the best way forward since it keeps compatibility and also enables the more standard behaviour.

dkasak added a commit to dkasak/python-markdown2 that referenced this issue Dec 16, 2020
@dkasak
When rendering fenced code blocks, add language-LANG class as well.
7f12db6 
This enables better interoperability because other tools usually expect
this class when the language is specified for a code block (see:
https://html.spec.whatwg.org/multipage/text-level-semantics.html#the-code-element).

Fixes trentm#370.
@dkasak dkasak mentioned this issue Dec 16, 2020
Merged
wip-sync pushed a commit to NetBSD/pkgsrc-wip that referenced this issue Dec 24, 2020
@yorickhardy
urlwatch: update to urlwatch-2.22
baba538 
Changelog:

== [2.22] -- 2020-12-19

=== Added

- Added 'wait_until' option to browser jobs to configure how long
  the headless browser will wait for pages to load.
- Jobs now have an optional `treat_new_as_changed` (default `false`)
  key that can be set, and will treat newly-found pages as changed,
  and display a diff from the empty string (useful for `diff_tool`
  or `diff_filter` with side effects)
- New reporters: `discord`, `mattermost`
- New key `user_visible_url` for URL jobs that can be used to show
  a different URL in reports (useful if the watched URL is a REST API
  endpoint, but the report should link to the corresponding web page)
- The Markdown reporter now supports limiting the report length via the
  `max_length` parameter of the `submit` method. The length limiting logic is
  smart in the sense that it will try trimming the details first, followed by
  omitting them completely, followed by omitting the summary. If a part of the
  report is omitted, a note about this is added to the report. (PR#572, by
  Denis Kasak)

=== Changed

- Diff output is now generated more uniformly, independent of whether
  the input data has a trailing newline or not; if this behavior is not
  intended, use an external `diff_tool` (PR#550, by Adam Goldsmith)
- The `--test-diff-filter` output now properly reports timestamps from
  the history entry instead of the current date and time (Fixes #573)
- Unique GUIDs for jobs are now enforced at load time, append "#1",
  "#2", ... to the URLs to make them unique if you have multiple
  different jobs that share the same request URL (Fixes #586)
- When a config, urls file or hooks file does not exist and should be
  edited or inited, its parent folders will be created (previously
  only the urlwatch configuration folder was created; Fixes #594)
- Auto-matched filters now always get `None` supplied as subfilter;
  any custom filters must accept a `subfilter` parameter after the
  existing `data` parameter
- Drop support for Python 3.5

== Fixed

- Make imports thread-safe: This might increase startup times a bit,
  as dependencies are imported on bootup instead of when first used.
  Importing in Python is not (yet) thread-safe, so we cannot import
  new modules from the worker threads reliably (Fixes #559, #601)

- The Matrix reporter was improved in several ways (PR#572, by Denis Kasak):

  - The maximum length of the report was increase from 4096 to 16384.
  - The report length limiting is now implemented via the new length limiting
    functionality of the Markdown reporter. Previously, the report was simply
    trimmed at the end which could break the diff blocks and make them render
    incorrectly.
  - The diff code blocks are now tagged as diffs which will allow the diffs to
    be syntax highlighted as such. This doesn't yet work in Element, pending on
    the resolution of trentm/python-markdown2#370.
tomiprs0x pushed a commit to tomiprs0x/python-markdown2 that referenced this issue Jan 1, 2021
@dkasak @tomiprs0x
When rendering fenced code blocks, add language-LANG class as well.
43fb768 
This enables better interoperability because other tools usually expect
this class when the language is specified for a code block (see:
https://html.spec.whatwg.org/multipage/text-level-semantics.html#the-code-element).

Fixes trentm#370.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

When rendering fenced code blocks, add language-LANG class as well. dkasak/python-markdown2
2 participants
@dkasak @nicholasserra