This is fabulous. Exactly what I had in mind. This also allows me to experiment a bit more easily with other template elements that might be useful. My current string is "new_note_template": "---\nuid: {id}\ntags: \n---\n\n# {title}"
Which gets me
---
uid: 201711150435
tags:
---
# 201711150435 Black Line Ride
This is fabulous. Exactly what I had in mind. This also allows me to experiment a bit more easily with other template elements that might be useful. My current string is "new_note_template": "---\nuid: {id}\ntags: \n---\n\n# {title}"
Damn cool feature. I think another way to handle this is with Snippets (I think plugins can provide their own snippets?) -- maybe someone should setup a Zettel Snippet Library.
Due to popular demand (by wangeleile from Github) note templates can make use of one more field: {origin} which will hold the id of the note that was (last) active when creating a new note ([shift]+[enter] or [[implicit note creation via title]]).
Example:
You are in note 201701010101
you hit [shift]+[enter]
you enter the title for the new note
new note might become eg note 201702020202.
The new note then has {id} = 201702020202 and {origin} = 201701010101.
@toolboxen said:
Damn cool feature. I think another way to handle this is with Snippets (I think plugins can provide their own snippets?) -- maybe someone should setup a Zettel Snippet Library.
Not so much a snippet type myself, never found a pressing need for them so I can't even tell how powerful they might be. That said, I bet the {origin} field would be tricky for them
@rene said:
Due to popular demand (by wangeleile from Github) note templates can make use of one more field: {origin} which will hold the id of the note that was (last) active when creating a new note ([shift]+[enter] or [[implicit note creation via title]]).
now this is fancy... good improvement to the plugin.
The setting insert_links_with_titles (true or false, false by default) will alter the way links to notes are inserted by the plugin (by [[ or autocomplete or [[implicit creation via title link]]):
`insert_links_with_titles` is `true`:
[[199901012359]] and note title
`insert_links_with_titles` is `false`:
[[199901012359]]
Side-note: He originally wanted note title insertion after the [[201710281838]] link when finishing auto-complete with [alt]+[enter] instead of [enter]. However, SublimeTexts's auto-complete does not support this: instead it queries the plugin for auto-completion suggestions and handles the rest itself, so we cannot distinguish whether a selection was made by pressing enter or any other key. (apart from pressing alt will make the suggestions go away anyway). So as a compromise, this setting was created. I am banking on the assumption that people who want titles after links prefer them in pretty much all circumstances and are happy to delete them where they don't fit.
And for text-producers, here is another awesome feature
Manual note link expansion: When you're inside a [[201710281638]] link, just press [ctrl]+[.] (my way of saying "...") or use ZK: Expand Link inline from the command palette and the linked-to note will be inserted into your note just as it would be with overview note expansion. [but the line containing the link will be preserved]
Example from the README:
Let's start with our first note:
# The rise of the machines
tags = #AI #world-domination
Machines are becoming more and more intelligent and powerful.
This might reach a point where they might develop a consciensce of their own.
As a consequence, they might turn evil and try to kill us all ........... [[201710282118]]
Now if you put your cursor inside the [[201710282118]] link and press [ctrl]+[.], the text will change into this:
# The rise of the machines
tags = #AI #world-domination
Machines are becoming more and more intelligent and powerful.
This might reach a point where they might develop a consciensce of their own.
As a consequence, they might turn evil and try to kill us all ........... [[201710282118]]
<!-- ! [[201710282118]] AI is going to kill us all -->
# AI is going to kill us all
tags =
<!-- (End of note 201710282118) -->
(We've never actually written anything into the linked note. Usually there would be lots of text)
Also, first bug report! (I am maybe refreshing this page more often than is necessary)
I'm getting some cases where it's not returning any results. I don't have time to do extensive testing right now, but at first blush it looks like it's only returning results if there is at least one ! involved. E.g.:
I have
#clocks
#clocksnotes
#clockstxt
("Clocks" is the project name for a novel. I have some fragments of the novel itself in my zettel as #clockstxt and the book bible as #clocksnotes)
If I do #clocks !#clockstxt I get the expected results, which is everything #clocksnotes. However, if I just search for #clocks I get nothing. Like, the search results window doesn't even update.
Let me know if there's any more testing I can do when I'm not running off to a meeting.
Also, first bug report! (I am maybe refreshing this page more often than is necessary)
I'm getting some cases where it's not returning any results. I don't have time to do extensive testing right now, but at first blush it looks like it's only returning results if there is at least one ! involved. E.g.:
I have
#clocks
#clocksnotes
#clockstxt
("Clocks" is the project name for a novel. I have some fragments of the novel itself in my zettel as #clockstxt and the book bible as #clocksnotes)
If I do #clocks !#clockstxt I get the expected results, which is everything #clocksnotes. However, if I just search for #clocks I get nothing. Like, the search results window doesn't even update.
Thanks! Good catch! I could re-produce it: If there is at least one markdown file that cannot be recognized as a note (not starting with a 12-digit note id) it broke the search. It worked when having a ! involved because then these files got ignored. It is fixed now -- tell me if it works for you now, too.
Just a little one but maybe relevant for text production. We now support highlighting for [@pandoc] and [ref. @pandoc] references.
I switched from placing [^citekey] footnotes to pandoc [@citekey] and [see @citekey], [vgl. @citekey], etc.
The footnotes were handy for:
.bib-file-less citations
markdown preview (alt-m)
I don't find the handy footnote approach flexible enough anymore, especially when producing text, because then I need "real" citations.
Markdown preview doesn't support bibtex citations, so for preview I now use a simple build command triggered with [cmd]+[b] that performs a pandoc conversion from markdown to html into a temp folder and opens a browser (if not already running) with the resulting file. Because pandoc puts in references itself, I had to comment out my references in the notes.
So my notes changed from:
# title
tags = #tag1 #tag2
Text referencing a great article[^citekey].
<!-- References -->
[^citekey]: Reference
To
# title
tags = #tag1 #tag2
This is a great concept [see @citekey].
<!-- References
[@citekey]: Reference
-->
I don't mind the side-effect of having references in comment-color, distracts less from the main text.
Note that @citekey itself does not trigger highlighting. Only when the citekey is inside a pair of square brackets, optionally preceded by some letters, colons and dots.
Just so that nobody is left in the dark: @wangeleile suggested an upgrade to the {origin} field in new note templates. Not following his suggestion exactly, origin has now been split into {origin_id} and {origin_title} to fill in the ID and title of the original note respectively. The old {origin} is still valid and equivalent to {origin_id}
This awesome feature was suggested by @wangeleile as well
We have auto-completion for cite-keys!
Automatic Bibliographies
It is common practice to keep local bibliographies in your notes. This makes each note self-contained and independent of .bib files. Manually maintaining a list of all your cited sources can be tedious and error-prone, especially in the case of long notes with many citations. Provided you have configured ["bibfile": "/path/to/zotero.bib",] a .bib file, then this plugin can take care of all your citations for you.
In any note with citations:
just bring up the command palette with [ctrl]+[shift]+[p] (or [cmd]+[shift]+[p] on macOS)
type zk to see all the Zettelkasten commands
and select ZK: Auto-Bib
This will add a long comment to your note in the following format (line wrapping added for github manually):
<!-- references (auto)
[@AhrensHowTakeSmart2017]: Ahrens, Sönke. 2017. _How to Take Smart Notes: One Simple Technique
to Boost Writing, Learning and Thinking for Students, Academics and Nonfiction Book Writers_. 1st ed.
CreateSpace Independent Publishing Platform.
[@FastZettelkastenmethodeKontrollieredein2015]: Fast, Sascha, and Christian Tietze. 2015.
_Die Zettelkastenmethode: Kontrolliere dein Wissen_. CreateSpace Independent Publishing Platform.
-->
The animation below shows how handy this is
Note: You don't have to cite in the [@pandoc] notation. If a cite-key is in your text, it will get picked up. However, the generated references section will use the [@pandoc] notation.
WARNING: Do not write below the generated bibliography. Everything after <!-- references (auto) will be replaced when you re-run the command!
Note: This will only work if pandoc is installed and on your path.
@Sascha said:
Wow. I am impressed. Looking forward to put it to the acid test.
Be careful when handling harmful substances.
Eg I found that auto-completing a cite-key does not work when typing the @ symbol. It's decorative anyway - but still: SublimeText behaves a bit weird in that case: It just auto-completes with the top-most suggestion; most often a note-link.
Also, @wangeleile had/has an issue with the auto-bib feature and it appears he has pandoc but not pandoc-citeproc installed / in the PATH.
If you thought text editors are just for text - think again
News from the README
Inline Local Image Display
Markdown notes are great! Especially because they are text-based. Sometimes, though, they contain images. Well, links to images: you only see them when you convert your note into a format that supports images.
Thanks to this plugin, you can now even view your local images directly in SublimeText:
just bring up the command palette with [ctrl]+[shift]+[p] (or [cmd]+[shift]+[p] on macOS)
type show
select ZK: Show Images
Note: This only works with images stored in your note archive folder (or a subfolder thereof).
You can configure a size limit for images to make sure big ones don't cover all your screen: Larger images will always be scaled to not exceed the maximum width.
The default setting limits images to be 320 pixels wide:
"img_maxwidth": 320,
To hide them:
bring up the command palette with [ctrl]+[shift]+[p] (or [cmd]+[shift]+[p] on macOS)
@rene said:
Can you try to test another image to verify this? But most often it's silly little other things...
I made a test file that links to every image I have in there (about 10), and none worked.
Do you get anything in the sublime console?
Why yes in fact:
Traceback (most recent call last):
File "/Applications/Sublime Text.app/Contents/MacOS/sublime_plugin.py", line 818, in run_
return self.run(edit)
File "/Users/mediapathic/Library/Application Support/Sublime Text 3/Packages/sublime_zk/sublime_zk.py", line 1309, in run
ImageHandler.show_images(self.view, max_width)
File "/Users/mediapathic/Library/Application Support/Sublime Text 3/Packages/sublime_zk/sublime_zk.py", line 61, in show_images
size = get_image_size(img)
NameError: global name 'get_image_size' is not defined
I was going to make a joke like "can you please develop all my software because you are so responsive" but I realized that I'm basically using nothing but ST with your plugin for 80% of my work, so that's more or less already the case.
By which I mean to say; it works great now! Thanks!
@mediapathic said:
I was going to make a joke like "can you please develop all my software because you are so responsive" but I realized that I'm basically using nothing but ST with your plugin for 80% of my work, so that's more or less already the case.
Wow, that's great to hear! Glad it is so useful to you! I'm not the only one really using it a lot . I'm honored
By which I mean to say; it works great now! Thanks!
Minor thing: It doesn't work with images with spaces in the filename. Not sure if that's a limitation you can overcome or not, Marked has the same issue. I'm not upset about this, just fyi.
@mediapathic said:
Minor thing: It doesn't work with images with spaces in the filename. Not sure if that's a limitation you can overcome or not, Marked has the same issue. I'm not upset about this, just fyi.
I don't like spaces in filenames . The plugin relies on SublimeText's Markdown syntax to recognize the  as link to an image. With spaces in the filename, ST doesn't treat the filename as a filename anymore so the plugin can't find it. You will also notice that the text between the [brackets] will change its color as soon as you put a space into the filename. Theoretically, this could be overcome by defining my own search expression - but who knows how many edge other cases that will bring up .
Since Marked doesn't support it either and eg commonmark explicitly states:
[...] a sequence of zero or more characters between an opening < and a closing > that contains no spaces, line breaks, or unescaped < or > characters, or [...]
I tend to conclude that markdown isn't meant to support spaces in filenames.
In a way it makes sense, as links in markdown were
seemingly meant for URLs mainly
The markdown spec allows for links with titles, where the title is separated from the filename by a space: This is [an example](http://example.com/ "Title") inline link.
So having a space in there and no quotes would be information enough to assume there is no title - so the whole could be treated as a filename... But to be honest: I would really recommend, if at all possible, to just get rid of the spaces in the filenames - makes life so much easier
Comments
Yes
, when nobody's looking 
This is fabulous. Exactly what I had in mind. This also allows me to experiment a bit more easily with other template elements that might be useful. My current string is
"new_note_template": "---\nuid: {id}\ntags: \n---\n\n# {title}"Which gets me
Thanks again so much!
Damn cool feature. I think another way to handle this is with Snippets (I think plugins can provide their own snippets?) -- maybe someone should setup a Zettel Snippet Library.
The question is: do you dream of python sheep?
Due to popular demand (by wangeleile from Github)
note templates can make use of one more field:
{origin}which will hold the id of the note that was (last) active when creating a new note ([shift]+[enter]or[[implicit note creation via title]]).Example:
[shift]+[enter]The new note then has {id} = 201702020202 and {origin} = 201701010101.
wangeleile's example was to use:
"new_note_template": "---\nuid: {id}\ntags: \n# Verknüpfungen\n - [[{origin}]]\n---\n",which would produce note headers like this:
Not so much a snippet type myself, never found a pressing need for them so I can't even tell how powerful they might be. That said, I bet the
{origin}field would be tricky for themNo, but I do count them just before
now this is fancy... good improvement to the plugin.
Another one inspired by wangeleile from Github:
The setting
insert_links_with_titles(true or false, false by default) will alter the way links to notes are inserted by the plugin (by[[or autocomplete or[[implicit creation via title link]]):Side-note: He originally wanted note title insertion after the
[[201710281838]]link when finishing auto-complete with[alt]+[enter]instead of[enter]. However, SublimeTexts's auto-complete does not support this: instead it queries the plugin for auto-completion suggestions and handles the rest itself, so we cannot distinguish whether a selection was made by pressing enter or any other key. (apart from pressing alt will make the suggestions go away anyway). So as a compromise, this setting was created. I am banking on the assumption that people who want titles after links prefer them in pretty much all circumstances and are happy to delete them where they don't fit.And for text-producers, here is another awesome feature
Manual note link expansion: When you're inside a
[[201710281638]]link, just press[ctrl]+[.](my way of saying "...") or useZK: Expand Link inlinefrom the command palette and the linked-to note will be inserted into your note just as it would be with overview note expansion. [but the line containing the link will be preserved]Example from the README:
Let's start with our first note:
Now if you put your cursor inside the
[[201710282118]]link and press[ctrl]+[.], the text will change into this:(We've never actually written anything into the linked note. Usually there would be lots of text)
btw: can be un-done with
[ctrl/cmd]+[z]Innit cute?
Dang, this is moving very fast! Amazing job. This is super useful for cross-platform app recommendations. Go Rene!
Author at Zettelkasten.de • https://christiantietze.de/
Hey Rene, wow this addon is really growing fast and it helps me very well with my still small Zettelkasten.
Yeah, thanks, that's what it is here for. To help both you and your Zettelkasten grow. The addon evolves with us and our Zettelkästen
Advanced Tag Search is here
I still have to update the README but in short:
The new command palette command
ZK: Search for tag combinationwill prompt for tag combinations to search for.The syntax is:
As usual,
Output will look like this:
Photographic proof
click to enlarge
Woooooah. Nice!
Also, first bug report! (I am maybe refreshing this page more often than is necessary)
I'm getting some cases where it's not returning any results. I don't have time to do extensive testing right now, but at first blush it looks like it's only returning results if there is at least one ! involved. E.g.:
I have
("Clocks" is the project name for a novel. I have some fragments of the novel itself in my zettel as
#clockstxtand the book bible as#clocksnotes)If I do
#clocks !#clockstxtI get the expected results, which is everything#clocksnotes. However, if I just search for#clocksI get nothing. Like, the search results window doesn't even update.Let me know if there's any more testing I can do when I'm not running off to a meeting.
Thanks! Good catch!
I could re-produce it: If there is at least one markdown file that cannot be recognized as a note (not starting with a 12-digit note id) it broke the search. It worked when having a ! involved because then these files got ignored. It is fixed now 
-- tell me if it works for you now, too.
Just a little one but maybe relevant for text production. We now support highlighting for
[@pandoc]and[ref. @pandoc]references.I switched from placing
[^citekey]footnotes to pandoc[@citekey]and[see @citekey],[vgl. @citekey], etc.The footnotes were handy for:
I don't find the handy footnote approach flexible enough anymore, especially when producing text, because then I need "real" citations.
Markdown preview doesn't support bibtex citations, so for preview I now use a simple build command triggered with
[cmd]+[b]that performs a pandoc conversion from markdown to html into a temp folder and opens a browser (if not already running) with the resulting file. Because pandoc puts in references itself, I had to comment out my references in the notes.So my notes changed from:
To
I don't mind the side-effect of having references in comment-color, distracts less from the main text.
Note that
@citekeyitself does not trigger highlighting. Only when the citekey is inside a pair of square brackets, optionally preceded by some letters, colons and dots.Just so that nobody is left in the dark: @wangeleile suggested an upgrade to the
{origin}field in new note templates. Not following his suggestion exactly, origin has now been split into{origin_id}and{origin_title}to fill in the ID and title of the original note respectively. The old{origin}is still valid and equivalent to{origin_id}News from the README
This awesome feature was suggested by @wangeleile as well
We have auto-completion for cite-keys!
Automatic Bibliographies
It is common practice to keep local bibliographies in your notes. This makes each note self-contained and independent of
.bibfiles. Manually maintaining a list of all your cited sources can be tedious and error-prone, especially in the case of long notes with many citations. Provided you have configured ["bibfile": "/path/to/zotero.bib",] a.bibfile, then this plugin can take care of all your citations for you.In any note with citations:
[ctrl]+[shift]+[p](or[cmd]+[shift]+[p]on macOS)zkto see all the Zettelkasten commandsZK: Auto-BibThis will add a long comment to your note in the following format (line wrapping added for github manually):
The animation below shows how handy this is
Note: You don't have to cite in the
[@pandoc]notation. If a cite-key is in your text, it will get picked up. However, the generated references section will use the[@pandoc]notation.WARNING: Do not write below the generated bibliography. Everything after
<!-- references (auto)will be replaced when you re-run the command!Note: This will only work if
pandocis installed and on your path.Wow. I am impressed. Looking forward to put it to the acid test.
I am a Zettler
Be careful when handling harmful substances.
Eg I found that auto-completing a cite-key does not work when typing the
@symbol. It's decorative anyway - but still: SublimeText behaves a bit weird in that case: It just auto-completes with the top-most suggestion; most often a note-link.Also, @wangeleile had/has an issue with the auto-bib feature and it appears he has
pandocbut notpandoc-citeprocinstalled / in the PATH.Unlikely to occur on a Mac though
@ctietze suggested an improvement to the
.bibfile lookup which is now implemented in this way:.bibfile in your note archive, it will be used automatically -- no configuration needed.bibfile is found and one is configured in the settings, the.bibfile in the archive will always take precedenceThat can come in handy when you have some archives with dedicated
.bibfiles and a general.bibfor not-so-special archivesThanks to @ctietze for this thoughtful suggestion!
To rehabilitate @wangeleile : His pandoc environment was perfectly fine. The pandoc code in the plugin was just not Windows friendly.
If you thought text editors are just for text - think again
News from the README
Inline Local Image Display
Markdown notes are great! Especially because they are text-based. Sometimes, though, they contain images. Well, links to images: you only see them when you convert your note into a format that supports images.
Thanks to this plugin, you can now even view your local images directly in SublimeText:
[ctrl]+[shift]+[p](or[cmd]+[shift]+[p]on macOS)showZK: Show ImagesNote: This only works with images stored in your note archive folder (or a subfolder thereof).
You can configure a size limit for images to make sure big ones don't cover all your screen: Larger images will always be scaled to not exceed the maximum width.
The default setting limits images to be 320 pixels wide:
To hide them:
[ctrl]+[shift]+[p](or[cmd]+[shift]+[p]on macOS)showZK: Hide ImagesHeyyyy guess what? The image thing isn't working for me. I get no change in the file at all. The file I'm trying looks like this:
And previews correctly in Marked2. Is there maybe another package that needs to be installed for ST to display images inline?
Interesting. Maybe the code I use for determining the image size does not recognize your image. The plugin does not depend on other plugins.
Can you try to test another image to verify this? But most often it's silly little other things...
Do you get anything in the sublime console?
I made a test file that links to every image I have in there (about 10), and none worked.
Why yes in fact:
Traceback (most recent call last): File "/Applications/Sublime Text.app/Contents/MacOS/sublime_plugin.py", line 818, in run_ return self.run(edit) File "/Users/mediapathic/Library/Application Support/Sublime Text 3/Packages/sublime_zk/sublime_zk.py", line 1309, in run ImageHandler.show_images(self.view, max_width) File "/Users/mediapathic/Library/Application Support/Sublime Text 3/Packages/sublime_zk/sublime_zk.py", line 61, in show_images size = get_image_size(img) NameError: global name 'get_image_size' is not definedsorry , my bad. please load again. i had been working with a cached function that has since moved and I didn't notice.
it should be fine now
@rene said
@mediapathic it is defined now
I was going to make a joke like "can you please develop all my software because you are so responsive" but I realized that I'm basically using nothing but ST with your plugin for 80% of my work, so that's more or less already the case.
By which I mean to say; it works great now! Thanks!
Awesome
Minor thing: It doesn't work with images with spaces in the filename. Not sure if that's a limitation you can overcome or not, Marked has the same issue. I'm not upset about this, just fyi.
I don't like spaces in filenames
. The plugin relies on SublimeText's Markdown syntax to recognize the 
.
as link to an image. With spaces in the filename, ST doesn't treat the filename as a filename anymore so the plugin can't find it. You will also notice that the text between the[brackets]will change its color as soon as you put a space into the filename. Theoretically, this could be overcome by defining my own search expression - but who knows how many edge other cases that will bring upSince Marked doesn't support it either and eg commonmark explicitly states:
I tend to conclude that markdown isn't meant to support spaces in filenames.
In a way it makes sense, as links in markdown were
This is [an example](http://example.com/ "Title") inline link.So having a space in there and no quotes would be information enough to assume there is no title - so the whole could be treated as a filename... But to be honest: I would really recommend, if at all possible, to just get rid of the spaces in the filenames - makes life so much easier