Skip to content

include-code-files: inclusion of code from source files (as pandoc-include-code hs filter) #130

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

Merged
merged 1 commit into from
Nov 10, 2020

Conversation

b3
Copy link
Contributor

@b3 b3 commented Oct 26, 2020

In order to facilitate an eventual inclusion of code as commented in PR #126 I modified my fork and created distincts PR.

This one includes a new filter called include-code-files which mimic almost every feature of pandoc-include-code which offer inclusion of source code files which some specific options (ranges, dedent).

@b3 b3 changed the title include-code-files: Initial import include-code-files: new filter to include code from source files (inspired by pandoc-include-code hs filter) Oct 26, 2020
@b3 b3 changed the title include-code-files: new filter to include code from source files (inspired by pandoc-include-code hs filter) include-code-files: inclusion of code from source files (as pandoc-include-code hs filter) Oct 26, 2020
Copy link
Member

@tarleb tarleb left a comment

Choose a reason for hiding this comment

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

Thank you, this is great. I left a short inline comment, but I'll go ahead and merge now.

One possible enhancement would be to support hyphenated names like start-line as alternatives to the startLine pascalCase names. Pandoc uses hyphenated names in many places, so that might make this more natural to use.

local content = ""
local fh = io.open(cb.attributes.include)
if not fh then
io.stderr:write("Cannot open file " .. cb.attributes.include .. " | Skipping includes\n")
Copy link
Member

Choose a reason for hiding this comment

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

Would it make sense to just return nil from the function at this point? This would allow us to remove the else clause and thereby reduce nesting.

Copy link
Contributor Author

@b3 b3 Nov 11, 2020

Choose a reason for hiding this comment

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

As far as pandoc.CodeBlock("") returns nil and that no other filters use the attributes placed in the code this is of course a nice idea for simplifying the code.
As I said I, however, did not understand pandoc lua filter process enough to be confident when I wrote that piece of code.
Can't we imagine that another filter on CodeBlock may be used after this one? That was my assumption and the reason for cleaning specific attributes used only by this filter.

Copy link
Member

Choose a reason for hiding this comment

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

I guess that's reasonable. I usually follow the principle that if an element cannot be processed the way we'd like, then it won't be touched at all. Whether or not that applies here is open to interpretation. I'm fine with the way it is now.


--- Dedent a line
local function dedent (line, n)
return line:sub(1,n):gsub(" ","") .. line:sub(n+1)
Copy link
Member

Choose a reason for hiding this comment

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

I love this line. <3


Filter to include code from source files.

The filter is largely inspired by [pandoc-include-code](https://github.com/owickstrom/pandoc-include-code).
Copy link
Member

Choose a reason for hiding this comment

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

Overlong line.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Correction proposed in PR #136.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Fixed in PR #141 instead of #136 (I cleaned my fork)

@b3
Copy link
Contributor Author

b3 commented Nov 11, 2020

I created a PR #137 to add support for start-line and end-line alternatives attributes replying to your above comment.
I first used PascalCase versions because it is what is proposed in current pandoc version (as in numberLines or startFrom for instance).

@tarleb
Copy link
Member

tarleb commented Nov 13, 2020

Thanks. Good point about numberLines, I hadn't considered that.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants