-
-
Notifications
You must be signed in to change notification settings - Fork 271
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
Support Rouge Formatters with other method signatures #759
Comments
You can use the |
@gettalong Thanks for your prompt response! I am actually aware of the formatter configuration options and that part of the code. In fact that is what I am trying to deal with in this patch. The challenge is that from what I can tell you can only really pass in general configuration options to your formatter which is fine in most cases but for this newish line highlighting feature you need to pass in the Ideally it would be possible to merge some of the call_opts here into the opts when appropriately needed by the formatter. Does that make sense to you? |
I see, thanks for the explanation. The How would you represent the to-be-highlighted lines in a kramdown document? |
I am trying to port over the markdown blog from our website to Bridgetown and we are currently using Gatsby and this plugin to handle the line highlighting so I am trying to support the same line representation (i.e. ```ruby{1,3-5}) used there. I actually have a rough parser for that working in the same PR I shared above. It converts the line numbers into an array which is what the formatter expects. Of course we are happy to have this be supported from within Kramdown but did not want to make assumptions about what was possible. Is that what you were asking? |
Yes, exactly. So in this case I would suggest you write a syntax highlighter that can parse that line representation and then delegate the rest to the rouge syntax highlighter. You should, however, insert a question mark after the language name so that kramdown extracts the language correctly into the class attribute:
The full string is available in |
@gettalong I am not sure what you are suggesting. I apologize if I am misunderstanding you but are you saying that we should write our own version of Kramdown::Converter::SyntaxHighlighter::Rouge ? |
@jonsgreen No, I suggested you write a syntax highlighter that uses the built-in rouge highlighter to do the highlighting. But the parsing of the highlighting numbers and instantiating the necessary formatter would be the job of your highlighter. |
Just jumping in here as @jonsgreen and I am working on this together. So…if I can reiterate what you're saying @gettalong to make sure we understand: we can write some code to parse the |
@gettalong So it doesn't seem like the value of
So we'd need to write a new syntax highlighter which in turn calls That seems like a rather complex custom solution to have to maintain outside of Kramdown. 😕 Is this something you can envision supporting within Kramdown core? |
@jaredcwhite were you able to find solution for this issue? Even I am facing problems in parsing. |
@sudeeptarlekar Not yet unfortunately. I'm essentially working on a third-party plugin system for Kramdown at this point (to better support things like GFM, mark tags, and other additions). Hopefully the line highlighting functionality makes its way in there soon. |
While working on a plugin for Bridgetown I realized that it was not possible to use some of the newer Rouge Formatters like
Rouge::Formatters::HTMLLineHighlighter.new(formatter, highlight_lines: [3, 5])
for at least two reasons. First of all the first argument is a delegate for another formatter. Secondly, there is no way to pass the highlight_lines option through to the Formatter without doing some monkey patching.Is there any interest in supporting these other Formatters from within Kramdown (rather than resorting to external patches)? Are you open to PRs on this and is there the bandwidth from someone with a deeper knowledge of the codebase to advise?
The text was updated successfully, but these errors were encountered: