Howdy, Stranger!
Categories
- 3K All Categories
- 152 Research & Reading
- 692 The Zettelkasten Method
- 6 Knowledge Work
- 99 Writing
- 464 Software & Gadgets
- 152 Workflows
- 728 The Archive
- 15 Plug-In Showcase
- 88 Resolved Issues
- 225 Projects Logs and Journals
- 83 Project: Zettelkasten.de
- 53 Critique my Zettel
- 169 Random
- 372 Introduce Yourselves!
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