-
Notifications
You must be signed in to change notification settings - Fork 858
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
CodeHilite: expand option support #334
Comments
@mingos777, thanks for the report. I wasn't aware of Pygments behavior here. I suppose Pygments is expecting (X)HTML with My recollection is that in the past Pygments had multiple lexers for PHP, one which was for PHP only and another for PHP embedded in (X)HTML. That way, you could just specify the different lexer - no need to configure it. But is has been awhile. Is that no longer the case? I hate to add a confiig option that is only useful for a single lexer, but I can see how this could be useful. What does the PHP lexer do if And for the record, I just checked and the behavior is the same with the fenced code extension as it is with CodeHilite on indented code blocks. |
@waylan The PHP lexer is not the only Pygments lexer that supports configs, most other lexers do. Some time ago I have written a patch for Docutils to add configs support, you can probably reuse that code |
@waylan As far as I'm aware, only the (pure) PHP lexer uses this option. Options shared by all lexers are So no, setting You are right about other PHP lexers - there are four or five more for mixing PHP with other languages, such as JavaScript or XML. I'm talking about the one for PHP only. |
Wait, so the PHP-only Lexer requires either So let me try this again: What does the PHP lexer do if The point is, I'm very averse to adding more bloat. I'm already unsure that we should have added anything except the lexer name to begin with. It is apparent that doing to has created a slippery slope. That said, if we really much allow the user to pass in lexer options, an adaptation of @mitya57's Docutils patch seems like the way to go. However, we should never raise an error if a document author types a bad option key, as that could bring down the whole server in some common server setups. Not sure how that should work. After catching the error. do we run the same lexer without the options, or fall back to the |
When using I do agree that more bloat is an unwanted addition. However, if using Pygments from within CodeHilite only allows a subset of functionalities of Pygments, feature request such as mine are pretty much inevitable. Raising errors when bad lexer options are passed in is indeed a no-go. My personal preference would be to fall back to |
I'm still very resistant to adding any option support to the lexers. My knee-jerk reaction is to say this is a problem upstream... But I understand why Pygments is doing it that way. What if we special-cased the PHP lexer so that when it is detected, we check for
And to be clear, this would only apply when the language is explicitly defined - so it won't work when I realize that this could guess wrong if |
@waylan This is not the way I imagined it, but I must admit that your solution not only solves the problem with the PHP lexer, but also introduces no new syntax to learn. I believe this is the best approach. |
I guess we can't force people to use the 'html+php' lexer. Perhaps they want the PHP code to stand out from the HTML and therefore do not want the HTML to be highlighted. Never mind it could break existing documents. For example the following code sample (which may or may not be valid PHP -- it's been a while) would trigger
The only options appear to be (1) offer general support to lexer options (as per @mitya57's Docutils patch), or (2) do nothing and require all PHP one-liners to include This is one of many reasons why I favor JavaScript highlighting libraries (see this, this and this - Warning! they are all a little outdated). |
I can see your point (1), and I'm glad to see you understand mine (2). Maybe it's possible to create an extended plugin for Python Markdown, based on CodeHilite, but with the addition of lexer options support? This way people already using the original plugin will not have an extra (unwanted/potentially dangerous?) feature enabled, but if they need it, they can switch to the new plugin ( If you decide against adding any features, my best option will indeed be to use a JS highlighter. Not that I'm against it, but I've yet to see a code highlighter as good as Pygments :). |
For the record, I have assigned this to the 3.0 milestone (see the roadmap in #391) and am using this as a general issue for CodehHlite. The intention is to expand/refactor the extension to accept any present/future config options of Pygments and simply pass them through. I'm not sure how that will look just yet, but suggests are certainly welcome. I've also updated the title to better reflect this change. |
I'm looking for a workaround for this. Is there a way to change the PHP lexer's default options? |
@anlutro at this time the only workaround would be to fork/hack the existing Extension to meet your needs. |
Bummer :( |
This was a lot of work! I basically gave up on trying to extend existing classes and just copy-pasted the existing extension modules. https://github.com/autarky/docs/blob/master/generate.py#L10-L13 |
I would like to use Python Markdown in conjunction with CodeHilite plugin + Pygments to highlight some PHP code snippets, often one-liners. Currently, CodeHilite doesn't allow any lexer configuration (only some formatter configuration).
Pygments' default PHP lexer has the option
startinline
, which is set toFalse
by default. This means that if I want any PHP code highlighted, I must start it with<?php
. This is not very pretty (again: think about one-liners) and I would rather have Pygments instructed to switch this setting toTrue
.Currently it is not possible to pass in any lexer options to CodeHilite. It would be nice to be able to add lexer configuration to the lexer name, e.g.:
The text was updated successfully, but these errors were encountered: