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

Add engine specific delimiters #75

Open
wants to merge 5 commits into
base: master
Choose a base branch
from

Conversation

colinbate
Copy link

This PR does make some changes to the nature of matter.language(), which probably isn't desired. I can remove that and make another method for this if necessary, but I thought I'd get a working version out there for review.

Files parsed with custom delimiters should round-trip via stringify correctly.

@jonschlinkert
Copy link
Owner

This is a great start! Nice work.

This PR does make some changes to the nature of matter.language(), which probably isn't desired.

I'm thinking we should allow users to decide how they want to specify the engine to use:

  • via delimiters
  • by specifying the language after the first "fence"
  • options

The main goals are performance and reliability, as long as it satisfies those two things I'm open to whatever approach you want to take. Although I'd probably favor options versus additional methods.

@colinbate
Copy link
Author

colinbate commented May 1, 2018

Previously, if you specified the language after the fence in the front matter, it would override the language passed into the options. With this change, any recognized custom delimiter will also override the passed in language. After thinking about it seems okay, it is the document which gets to specify the language, and the options are just providing the fallback language. So on that front, all is fine.

The issue with matter.language() is that it now requires the full file contents as its first parameter. Previously it would work with a string which had the initial --- fence trimmed off. Also, the object it returns has an additional property, but that isn't a big deal. What is different about the return value is that the raw property now includes the whole fence: ---coffee vs. just coffee as before. Let me know if this is a concern; I could make the changes fully backward compatible if necessary.

As for performance, the cases where there is front matter with a default delimiter should be unchanged. The only situation which would be affected is if you have a string or file without any front matter, and you have many engines defined.

I've pushed a small tweak to ensure you don't register a custom engine delimiter the same as the default one.

@colinbate
Copy link
Author

I didn't regenerate the README file, but I did update the underlying verb file. I wasn't sure if you normally do that. The output differed in a couple of ways, so I didn't want to presume.

@colinbate
Copy link
Author

@jonschlinkert Just checking in to see if you've had a chance to look at this further. I think it is mergeable, just let me know if you want me to regenerate the README or any other housekeeping.

@robertmassaioli robertmassaioli added the feature request A request for new functionality. label Jan 10, 2019
@colinbate
Copy link
Author

Just revisiting this as I’ve come across another place where I’d like the per-engine delimiters.

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

Successfully merging this pull request may close these issues.

None yet

4 participants