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.

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

Syntax Highlighting Themes for HTML #179

Merged
merged 34 commits into from
Apr 12, 2012
Merged

Syntax Highlighting Themes for HTML #179

merged 34 commits into from
Apr 12, 2012

Conversation

ramnathv
Copy link
Contributor

I made some modifications to the file themes.R so that syntax highlighting themes work for html output as well. I tested it and it works. There is a lot of scope to refactor the code here, but for now I focused on keeping the changes to a minimal.

Let me know when you have a chance to review the code and pull in the changes.

background-color: #fdf6e3;
border-style:solid;
border-width:1px;
border-color: #B0B0B0;
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

these 3 lines can be merged as border: solid 1px #B0B0B0;

@yihui
Copy link
Owner

yihui commented Mar 25, 2012

this looks pretty good; I'll be happy to merge it after you made the small change above

you can also try to refactor the code as you wish; thanks a lot!

@ramnathv
Copy link
Contributor Author

I made the changes. I also reverted the background-color to the light gray that was used as the default before.

@ramnathv
Copy link
Contributor Author

I did not realize that these changes would be added to the pull request as well. I just refactored the code. Let me know if you want to pull these as well, or you will be able to selectively pull the user-visible changes first and pull these after you have had a chance to review.

@yihui
Copy link
Owner

yihui commented Mar 26, 2012

I can wait until you finish the work; at least I have not seen knitr.sty yet.

My original plan for #140 was to write the header into a separate file in the last step in insert_header() in header.R, so I do not actually need to move the text into a file beforehand.

\\makeatother
## COMMIT: move .header.framed to a style file of its own so that it can be ## included or copied directly to the tex file
.knit.sty <- system.file('misc', 'knitr.sty', package = 'knitr')
.header.framed <- paste(readLines(.knit.sty), collapse = "\n")
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm not sure if this really works, because the code will be run before knitr is installed, i.e. there is no knitr.sty at that time.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good point. The alternative would be to move these lines directly inside the functions that use them. That way, they would be invoked only after knitr is installed.

@ramnathv
Copy link
Contributor Author

I like the idea of pulling the headers into a style file in case of latex or a css file in case of html. I think you should provide users two options. Option 1 would be status quo, where the headers are included directly in the document making it standalone. Option 2 would be to put the header in an external file and include it in the parent document.

On a different note, I think it would be useful if you can add an option highlight.theme that would take a theme name as input. This would simplify the code considerably,as you can set the default theme based on the output format (for example default for html and edit-eclipse for latex) and not have to deal with special cases.

Let me know if you think this might be a good idea. If you think it is, and you agree with the two options, I can put together a patch addressing this and send you a pull request. If you think other ways of doing it might be better, do let me know so that we agree on a specification before further work.

}
if (!nzchar(h['highlight'])) {
# header for Latex Syntax Highlighting
.header.hi.tex = paste(theme_to_header_latex('edit-eclipse')$highlight,
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

why is edit-eclipse the default theme for LaTeX output?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is the default that you had used previously. I remember reading a note of yours sometime, where you indicated that you found the colors of the default highlight theme too flashy for pdfs.

Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes I think I mentioned it at some time, but I'm not actually using edit-eclipse. The default theme has a light gray background, and the background of edit-eclipse is white.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In that event, I will create a default.latex.css theme which has the gray background.

Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actually I do not see much gain of moving the two objects .header.framed and .header.hi.tex to two files respectively; I mean they are simply string constants and it is probably not worth it to read and write through extra files. At the end of the day, they will be concatenated in insert_header(), and that will be the time to write the header into a separate file if opts_knit$get('self.contained') == TRUE.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

First, to some extent it is a style issue, since I don't prefer latex and other markups contaminating my R code. Second, these are just defaults. So pulling them inside default files helps keep the code clean without cluttering them up with a lot of if.. else statements. For instance, if we implement highlight.style as an option, you can set it to default and the headers would automatically correspond to them. Just my two cents :-)

Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

OK, .header.hi.tex can go to a file like default.css. For .header.framed, I'd rather leave it as is at the moment.

@yihui
Copy link
Owner

yihui commented Mar 27, 2012

You can add include to opts_knit, but is there a better name? It might be confusing because it is also in opts_chunk.

For highlight.theme, I guess it is not of high priority, so let's put it aside at the moment.

@ramnathv
Copy link
Contributor Author

It might be a bad idea to use include since it is already an option in opts_chunk. I am thinking of mimicking pandoc and using the option self_contained which is TRUE by default implying headers are directly contained in the document. It is the same reason why I think adding highlight_style as an option would be neat.

The use case for these options is that very often I generate multiple versions of my document, and I don't want to be tampering with the base document. I know, I can use knit_theme$set(), but it is an extra function to remember. Is there any reason you think adding highlight_style as a global option is a bad idea?

@yihui
Copy link
Owner

yihui commented Mar 28, 2012

I think self.contained and highlight.style are good to be put in opts_knit.

@ramnathv
Copy link
Contributor Author

ramnathv commented Apr 9, 2012

I have made the changes to get (a) syntax highlighting in html and (b) allowing the header to be written to an external file using opts_knit$set(self.contained = TRUE).

You will notice a few commits involving addition/removal of hooks for reSt files. The reason is that I wanted to do a few more tests before adding them. I was thinking that for the purposes of easier maintenance, it might make sense to write a sister package knitrExtra which can contain user contributed hooks. If you think it is a good idea, I can set up a github repository for knitrExtra. Let me know.

@ramnathv
Copy link
Contributor Author

ramnathv commented Apr 9, 2012

On a different note, I think there might be an opportunity to refactor the overall code of knitr significantly. One idea is to use S3 methods. For instance, if you set the class of a document to its output format, it would be easier to extend knitr by adding generic functions pat, render, make_header, insert_header etc.

Let me know what you think.

@yihui
Copy link
Owner

yihui commented Apr 11, 2012

Oops... I made some changes to header.R and hooks.R, and this pull request cannot be automatically merged now. Is it possible for you to pull my changes and resolve the conflicts? Sorry for the trouble.

Regarding S3 methods, you can experiment with it after this pull request or do it in another branch. Thanks!

@ramnathv
Copy link
Contributor Author

Done! You should be able to pull this now. Let me know if you still find some conflicts.

@yihui
Copy link
Owner

yihui commented Apr 11, 2012

It looks good now. I will take a look tonight. Thanks!

yihui added a commit that referenced this pull request Apr 12, 2012
Syntax Highlighting Themes for HTML
@yihui yihui merged commit 6aa2d1f into yihui:master Apr 12, 2012
@vsbuffalo
Copy link

Is there an option to turn on these HTML themes with knit2html()?

@ramnathv
Copy link
Contributor Author

No. But you can do it by using knit_theme$set('acid') in your document, where acid is the theme name. You can also decide whether you want to keep the stylesheet as a part of the html file, or an external css file.

@yihui
Copy link
Owner

yihui commented May 21, 2012

currently themes only work for LaTeX and HTML output; knit2html() is essentially for markdown, so these themes do not apply

if you want different themes for markdown-->html, you probably need to write your own css depending on which converter you use (sundown, pandoc, ...)

I have seen your own tweak on twitter which looks very nice!

@github-actions github-actions bot locked as resolved and limited conversation to collaborators Nov 10, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants