-
Notifications
You must be signed in to change notification settings - Fork 102
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
Help With Callouts: Any Examples? #99
Comments
If you'd like to submit those changes upstream, feel free to send a PR and I'll make sure it gets merged.
Callouts with source highlighters are a little tricky, but not insurmountable. The secret is to extract the callouts, pass the remaining string to the highlighter, then restore the callouts. You can find that logic in these two places:
What I'd really like to do is make source highlighting an extension point so you get all this logic for free and only have to worry about highlighting the pure source. That's what asciidoctor/asciidoctor#2106 is about. |
Thanks a lot @mojavelinux, the links with code ranges you provided are very helpful and I've managed to start parsing out the callouts (taking my time, though, for I don't know Ruby from Adam and I'm juggling my way through). So far, I've managed to edit the treeprocessor so that all callouts (except escaped ones) are correctly extracted and stored. Now I'll start working on the restore part. I've used the code you linked as a reference to work on. So far, so good. Why Comment Delimiters Are Stored?In the extrac part of (callout_marks[lineno] ||= []) << [$1, $4] Where Autonumbered CalloutsI also have a question about auto-numbered callouts. They are mentioned in # Matches a callout reference inside literal text.
#
# Examples
# <1> (optionally prefixed by //, #, -- or ;; line comment chars)
# <1> <2> (multiple callouts on one line)
# <!--1--> (for XML-based languages)
# <.> (auto-numbered) But I don't recall ever coming across them in the Asciidoctor manual. Are they an undocumented feature? Are they still experimental or they can already be used in documents? In my edited version of the Highlight extension, will I need to make sure that they are being supported correctly? |
Hi @mojavelinux, I wanted to keep you up to date with my efforts toward integrating Highlight in Asciidoctor HTML backend. I've just published inside the Highlight project a folder dedicated to the topic: It contains a copy of the original HighlightTreprocessor extension as well as a modded version which enables subsitutions. That's how far I've manage to get with this. Unfortunately, my knowledge of Ruby is too rudimental. So I've decided that I'll be studying Ruby for the sake of being able to contribute to Asciidoctor. In the meantime, I hope that these assets and documentation on the Highlight repository might help in this direction. After what you mentioned in asciidoctor/asciidoctor#2990, about the new API 2.0 changing the way highligters will be registered in the future, I guess that it would be better to invest in the new API instead of developing the HighlightTreprocessor extension. Still, it might be worth integrating support for substitutions. Also, worth poinitng out, when Furthermore, I suggest that the native Asciidoctor HTML5 template should add the <pre class="highlight" lang="alan">
<code class="language-alan" data-lang="alan"> This extra attribute won't intefere with those who don't use it, but it would allow much more control in terms of styling background color, borders, etc. Look at my example document, which uses a customized Haml template to achieve this and discusses the benefits of having this extra attribute: I really hope that Asciidoctor will soon support Highlight natively, for the number of syntaxes for this highlighter is huge and growing fast and, IMO, it's the easier to work with — standalone binaries, easy to write your own syntaxes, and highly customizable. |
Yes, I absolutely recommend that you immediately switch to using the new SyntaxHighlighter API. This is the key use case for why it was added.
That should already work with the new API.
The new API gives you this control. See https://github.com/asciidoctor/asciidoctor/blob/master/lib/asciidoctor/syntax_highlighter/pygments.rb#L50 to find an example.
this is possible using the new API. See https://github.com/asciidoctor/asciidoctor/blob/master/lib/asciidoctor/syntax_highlighter/pygments.rb#L50 to find an example.
The comment marker in front of the callout number is only dropped when icon-based fonts are in use. Otherwise, it is restored (to preserve copy-paste functionality).
They are new in 1.5.8. They haven't been documented in the user manual yet.
No additional syntax highlighters are going to be added to Asciidoctor core. Instead, the SyntaxHighlighter API was added so these integrations can be developed and published as discrete packages. You now have the ability to integrate any syntax highlighter you want to integrate. |
Btw, if you use the SyntaxHighlighter API, you don't have to worry about callouts at all. They will just work. (Though, if you look low enough, you actually have some control over them as they get passed to the highlight method. See https://github.com/asciidoctor/asciidoctor/blob/master/lib/asciidoctor/substitutors.rb#L942). |
@mojavelinux,
I've started using the
highlight-treeprocessor.rb
extension, and it works really great. I've also managed to tweak it slightly in order to support a different CSS theme for each language being highlighted:What I really miss here is support for callouts. I haven't worked with Ruby before, and I don't know Asciidoctor's internals, so if you could provide me a couple of links to Ruby source files which deal with callouts I could study them and try to have a go at implementing the callouts part myself. But right now, I can't figure out where to start from (did sift through Asciidoctor source files, but couldn't figure out how to relate it to extensions).
Thanks.
The text was updated successfully, but these errors were encountered: