Closed Gnossos closed 3 weeks ago
Hi @Gnossos, I don't use Zettlr so I'm afraid I won't have time to develop/test for it. Feel free to open a PR for it though! The only constraint for accepting PRs is that they remain editor-agnostic, if you add any editor-specific features they should be optional.
That being said, I believe the upcoming release with a custom format should allow you to do that (or most of it). I'd recommend waiting until v0.1.0 before starting on a PR.
Sorry, I learned about Mdnotes on the Zettlr forum, and the individual who posted about it seemed to be its author. It was presumptuous of me to assume you used Zettlr.
But with this aside, the option of using pandoc YAML syntax instead of the double brackets would still be useful. Since bibliographic information in a markdown document is frequently rendered with pandoc, formatting the metadata this way would save an extra step.
I believe Zettlr uses a subset of the pandoc YAML, which probably just means the Zettlr documentation only covers some of the allowable fields. The pandoc User's Guide describes them on p. 40ff.
Not to worry, that's the nice thing about markdown, the editor shouldn't matter much!
I don't use pandoc very often with markdown files (I tend to use LaTeX for final form writing), but whenever I need to use pandoc with bibliography, I tend to do it through the CLI, e.g. pandoc -s --bibliography biblio.bib --citeproc CITATIONS -o example24a.pdf
. I'm afraid I don't have time right now to go through the allowed fields in pandoc's YAML, but I did in part decide to work on the custom format to make use of the YAML frontmatter, so maybe the next release will take care of this! If it doesn't, maybe I'll revisit, but I can't promise I'll be able to add it myself.
Hi @Gnossos, I've added an xpi
in #35 for those that want to test the upcoming release beforehand. I haven't had a chance to look at into bibliography definitions in the YAML frontmatter, could you add a couple of examples/screenshots here?
My suspicion is that the templates, custom format and wildcards could get you 90% there, but at the expense of being able to use them somewhere else. Let me know if/how that works for you.
Hi @Gnossos, I don't use Zettlr so I'm afraid I won't have time to develop/test for it.
I could do some testing/developing, as I stumbled upon the plugin myself and this fits pretty well into workflows with regard to Zettlr. Plus, I'm also a huge fan of keeping everything editor-agnostic and using options for those stuff.
Hey @nathanlesage, thanks for offering! I'm preparing the release right now, let me know if you have any questions about it or if there's anything I can do to help!
Hey @argenos Thanks! I've tested the current develop branch, which works like a charm for me (with the additions of #38 even more so); and with regard to the YAML frontmatter: I think there's plenty of options to explore here, and I would love to help developing the plugin further!
Hi, I am just doing this and it seems to work very well. I am doing it to share my zotero items to a hugo blog but I think this is extremely versatile. A person like me who knows jack about s..t can easily export the zotero items into practically any text-based file format just by creating a dummy file. I tried using pandoc
/citeproc
previously but couldn't figure out how to get it smooth and reliable.
The way I did it was to go through every hidden preference in about:config that I would be interested and also add those which are missing. In most cases remove everything except the basic value.
So for example if you want the below to be your yaml
frontmatter. Make a custom template for Zotero Metadata Template.md
like this. I used this option because as far as I can see it always exports for every file.
---
title: "{{title}}"
tags:
- {{tags}}
slug: "{{citekey}}"
lang: "{{language}}"
date: {{accessDate}}
draft: true
---
here is what you need to change/add in the about:config
:
bullet
first I just deleted this. find extensions.mdnotes.bullet
and delete the value
. Maybe there is some other kind of work it could be doing.. but not for me. I will define everything in my template or the individual strings. Maybe it's not really necessary since I removed all references to it.
title
You could also use shortTitle
if you preferred.
create preference extensions.mdnotes.placeholder.shortTitle
with value:
{"content":"{{field_contents}}", "link_style": "none", "list_separator": ", "}
tags
change extensions.mdnotes.placeholder.tags
to:
{"content":"{{field_contents}}", "field_contents": "{{content}}", "link_style": "no-links", "list_separator": "\n - ", "remove_spaces": "true"}
this will make the tags be a dashed list like this
tags:
- apples
- hotdogs
- friday
"list_separator": "\n - "
defines this with the value \n
being a new line, then -
(space dash space) to make the list. You could replace with comma if you wanted just make sure to also edit the yaml
frontmatter because it starts the list.
citekey
/slug
make sure the citekey
format is compatible with this use if you want it.
change extensions.mdnotes.placeholder.citekey
to:
{"content":"{{field_contents}}", "field_contents": "{{content}}", "link_style": "no-links"}
language
create preference extensions.mdnotes.placeholder.language
with value:
{"content":"{{field_contents}}", "link_style": "itemType", "list_separator": ", "}
accessDate
(this would probably be inappropriate in a lot of cases so you'd neede another way to set the date)
create preference extensions.mdnotes.placeholder.accessDate
with value:
{"content":"{{field_contents}}", "link_style": "itemType", "list_separator": ", "}
Questions and unresolved
So the above works the way I expect on the files I have tested it on.
I kept notes of all the things I changed and also made a template that have a lot of the values so you can test the results. I would be happy to share this if wanted, but it was pretty tedious to enter them all by hand.
about:config
editor? I can't seem to find where zotero is storing this (on a mac). Was hoping for a ~/.zotero
but no dice. It is probably in ~/Library
somewhere but I have not searched. The chances are also not great to be able to edit a file in there but not sure if it's actually impossible in all cases. It could also be in the actual .app
itself. makefile
one level up so I am guessing those are the 4 files to create the extension? Maybe my english is good enough to read javascript and xml.. unless someone who can actually read javascript and xml gets to this first. url (external url)
pdfAttachments
(zotero url) - even with "Internal links" set to "no links" extra
/
in the filename to move to a directory as would be required by my use case but the files did not appear anywhere that I could find. Is this expected or is there a way to do it? If expected then I can work around it as well with mv
, but if possible then better because it eliminates 1 step. :)Even exactly as-is this is a massive improvement over my workflow as it existed 12 hours ago so THANK YOU. <3
edit: on further experimentation I found changes needed and I adjusted the above:
tags
was a mess for a bunch of reasons but it works now.yaml
: a space is needed at the end of each line. if there is no space and the value is empty, the line break is skipped and the key for the next line becomes the empty line's value... it's a mess. idk if this is against yaml
specs but hugo doesn't mind.yaml
: added double quotes in case of badly formatted values. in my case I had a title like title : subtitle
; because there is a space on either side of the colon it becomes a mess. wrapping the text in quotes protects from all kind of havoc, I am hoping.
Thanks for the very useful tool. These may be good ideas for enhancements. Since they're related, I'm putting them in one issue.
Instead of exporting each field in brackets, e.g. [[Title]], give the option of using YAML format, e.g., title: and enclosing the fields in a YAML header (---/...).
Export the fields as it's done now, but also enter information in corresponding YAML fields defined by Zettlr or pandoc. E.g., still export [[Title]], but also initialize a YAML header with title:
Modify the exported MD file so it starts with a generic YAML header (with or without appropriate fields initialized, as in 2); this would eliminate one step in initializing a literature zettel.