Comments (11)
Hi,
I hope I understand your problem. You are trying to access a variable defined in the meta.json from a markdown. Can you write a bit more about your use-case? I just want to make sure I understand
@mixu - Correct me if I'm wrong- I see you changed it in 54682e3 . Maybe it can be resurrected as an optional feature (if it is indeed the intended use-case)
from markdown-styles.
Hi guys; thanks for your feedback
apparently I was not clear enough; I am not trying to use a meta-variable from a markdown but simply from page.html, like I can see {{title}} is being used;
I did succeed to define an additional meta-variable in the markdown header with e.g.
title: my title
tab: tab-to-activate
---
and then to use {{tab}} in page.html
but when I want to define variable 'bar' for all the markdowns, using the meta.json above, I can't get {{bar}} to correctly instantiate in the resulting html
this is the intended use, right ?
from markdown-styles.
Oh, now I understand. You're looking for a variable that can be shared across 'projects' (directories) something similar to a global constant.
The meta.json
definition is specific for each input dir
as you can see in https://github.com/mixu/markdown-styles/blob/master/lib/merge-meta.js#L7 each file is extended with its project (directory) definitions in meta.json
from markdown-styles.
OK, I had that right; but...
If I run
generate-md --input markdown
and I have an input file in markdown/index.md
, what would be projectName key in this case ? As I said, I have tried '.', '', 'markdown', and nothing seems to be working..
thanks !
from markdown-styles.
"index"
projectName: either the file name, or the folder name of this file
it's the file name when its parent dir is the input dir
from markdown-styles.
hi @parmentelat - thanks for filing this issue. I improved the docs a bit around this, hope that helps. I do think that there would be room for improvement, specifically:
- there should be a way to set defaults that apply to all files, perhaps under the
"*"
key - the metadata should cascade rather than being applied on a per-directory / per-file basis (e.g. abc/foo/bar.md should see the composite of "*", "abc", "abc/foo", "abc/foo/bar", and the file metadata rather than just having the metadata defined in "abc/foo").
The current implementation was mostly written to maintain compatibility with the 1.x
version, but I'd be happy to merge an improved version (ideally with integration tests - since otherwise I'll have to write those)
from markdown-styles.
Hi there
My proposal indeed aimed at a cascading scheme
However I am not familiar with past-to-present schemes so I cannot deal with legacy and backward compliance
In a nutshell, I would propose that the dictionary used to deal with file /a/b/c.md would be computed this way (using python style as I am more of a python guy :) :
. Starting with the meta['/'](or {})
. Merging in meta['/a'](or {} etc...)
. Merging in meta['/a/b'] ...
. Merging in meta['/a/b/c'] ...
. Merging in metadata from the file
This should be rather straightforward to write; I am willing to give this a try when I have a chance, but probably not before september or so...
Note that definitions in meta['a/b/c'] are specific to the file; but that these should be overridden by metadata from the file itself IMO, hence this order
That same scheme could apply to files at the root level (i.e. files right under the input directory) with no change at all.
As far as naming, one could also consider using instead - in the same order
. meta['']
. meta['a/']
. meta['a/b/*']
. meta['a/b/c']
. metadata from the file
which might feel a little clearer
Or any variation along these 2, again I guess rhe choice here is more about legacy than anything else.
Any pointer to how integration tests should be written could come in handy and would be greatly appreciated
Thanks for the feedback in any case --- Thierry
Sent from my iPhone
On 12 juil. 2015, at 05:54, Mikito Takada [email protected] wrote:
hi @parmentelat - thanks for filing this issue. I improved the docs a bit around this, hope that helps. I do think that there would be room for improvement, specifically:
there should be a way to set defaults that apply to all files, perhaps under the "" key
the metadata should cascade rather than being applied on a per-directory / per-file basis (e.g. abc/foo/bar.md should see the composite of "", "abc", "abc/foo", "abc/foo/bar", and the file metadata rather than just having the metadata defined in "abc/foo").
The current implementation was mostly written to maintain compatibility with the 1.x version, but I'd be happy to merge an improved version (ideally with integration tests - since otherwise I'll have to write those)β
Reply to this email directly or view it on GitHub.
from markdown-styles.
Sounds good to me - I think its OK to move away from the legacy mechanism (which was somewhat limited) since I think the migration will be fairly straightforward and I'm pretty sure the people who wanted to move to the 2.x releases have done so by now.
I like the second naming convention a bit more, since it's closer to how glob expressions are written. I probably won't have too much time to work on this soonish but it's good to have something specced out.
As for integration tests, this test can probably be extended a bit to cover the new cases https://github.com/mixu/markdown-styles/blob/master/test/integration.test.js#L71
from markdown-styles.
Hi
I have just committed a proposal for implementing this feature in my own fork here
parmentelat@551e344
in essence:
. I have implemented the second naming scheme as per your preference
. I do not have anything test-related yet, but I did test this rather thoroughly on my own input website and am so far happy with what I can see
. I add a 'relative' property to each 'item' object (and do not use projectName in mergeMeta anymore at all)
. then mergeMeta does re-create the input 'item' object starting from an empty {} and adding values going down the file tree; then it adds the original 'item', and finally sets the title property from headings, if it's still missing, like it was done beforehand
I would appreciate a quick review; as I said I am not very fluent in JS so this might be a little awkward or tedious at times
from markdown-styles.
as a final note
at first glance it might very well be that projectName was only used in merge-meta.js (apart from other references in test/) so it would make sense to remove the 8 lines that are about setting this property in set-output-path.js
like here
parmentelat@79479eb
from markdown-styles.
published on npm as v3.0.0
from markdown-styles.
Related Issues (20)
- tables look unreadble in the default mixu-bootstrap-2col layout
- File contents deleted HOT 1
- Markdown files with UTF8 with BOM can lead to incorrect renedering
- Links and special characters
- how to highlight another language
- Add support for maths mode? HOT 2
- Generated HTML has self-closing tags
- Hide render console message?
- github style: Bold not preserved with code
- Change output html filename?
- GitHub style ignores βtextβ code block formatting HOT 1
- `Could not parse metadata from` by adding 3+ dashes
- Current project status HOT 3
- Help please for any feature to highlight some lines of code ?
- When running from a batch file, lines below `generate-md` cannot execute HOT 1
- GitHub dark theme
- hrefs in toc faulty
- Local links are rendered incorrectly
- Feature Request: use globbing for --input
- npm audit vulnerabilities
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
π Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. πππ
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google β€οΈ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from markdown-styles.