Hello! I just stumbled on this discussion and I'm new to this forum, but this plugin is the exact tool I've been looking for. And it's so much better than I could have imagined. I am amazed! It feels as if someone looked into my brain but I guess we're simply not alone with our problems and it seems, you built a solution
I just installed it and will be trying it out during the next few days. I'm super excited! Thank you so much for your effort, @rene !
Hello, @rene!
First, I want to thank you for this brilliant plugin and all the enormous work you've done to develop it! It's incredibly useful and full of wonderful features.
However, I also have a question -- or maybe a feature request. Is there any way to use something other than [#] for tags? The problem is, I have a long-established convention where I use [kw] to denote tags. It started years ago, when I tried to make OneNote my research database -- and OneNote utilizes Windows search, which disregards special symbols. So I chose to use constructed words like kwsociety, kwidentity etc.
By the time I switched to Sublime Text, it became a habit, and I now have over 200 tags starting with [kw]. Before instlling your plugin, I used Sublime auto-completion list to manage them, and I setup [kw] as a trigger for auto-completion. However, sublime_zk overrides the built-in auto-complete feature, so my tag list stopped working. Also, sublime_zk assumes that tags always start with [#].
Now, one of the easiest solutions is, of course, to use the replace command either to add [#] sign before [kw], or to replace [kw] with [#]. I chose the first option, because it would be easy to revert back if needed. So now all my tags start with [#kw].
However, I've also been using [#] sign to format titles in notes. It was never an issue before, because of my [kw] convention for tags. But now, even after adding [#] sign to tags, I have a problem: when I try to use [#][?] or [#][!] options, I get a lot of extra words, which are not tags. For this reason, I hesitate to install Silver Searcher -- even with persistent search results, I'd still have too much noise.
I've been thinking what to do in this situation. Combing through hundreds of notes manually to get rid of the [#] sign in titles is not an option, and I don't know how to automate this process. Hence my question: if it were possible to choose another sign for tags, I could revert to my [kw] convention (or use a [#kw] combination, since I've already renamed my tags).
Anyway, any thoughts or advice on this are welcome!
@Julia said:
Hello, @rene!
First, I want to thank you for this brilliant plugin and all the enormous work you've done to develop it! It's incredibly useful and full of wonderful features.
Glad you like it!
However, I also have a question -- or maybe a feature request. Is there any way to use something other than [#] for tags? The problem is, I have a long-established convention where I use [kw] to denote tags. It started years ago, when I tried to make OneNote my research database -- and OneNote utilizes Windows search, which disregards special symbols. So I chose to use constructed words like kwsociety, kwidentity etc.
By the time I switched to Sublime Text, it became a habit, and I now have over 200 tags starting with [kw]. Before instlling your plugin, I used Sublime auto-completion list to manage them, and I setup [kw] as a trigger for auto-completion. However, sublime_zk overrides the built-in auto-complete feature, so my tag list stopped working. Also, sublime_zk assumes that tags always start with [#].
I can dig into why the plugin doesn't cooperate with the built-in auto completion. And yes, # is assumed, more on that further down.
Now, one of the easiest solutions is, of course, to use the replace command either to add [#] sign before [kw], or to replace [kw] with [#]. I chose the first option, because it would be easy to revert back if needed. So now all my tags start with [#kw].
That is a good idea in theory
However, I've also been using [#] sign to format titles in notes. It was never an issue before, because of my [kw] convention for tags. But now, even after adding [#] sign to tags, I have a problem: when I try to use [#][?] or [#][!] options, I get a lot of extra words, which are not tags. For this reason, I hesitate to install Silver Searcher -- even with persistent search results, I'd still have too much noise.
This is where the theory falls short
But what I don't get is you being afraid of the Silver Searcher. In my opinion you wouldn't get more messy output than you do now. You'd just get it much more quickly.
I've been thinking what to do in this situation. Combing through hundreds of notes manually to get rid of the [#] sign in titles is not an option, and I don't know how to automate this process. Hence my question: if it were possible to choose another sign for tags, I could revert to my [kw] convention (or use a [#kw] combination, since I've already renamed my tags).
I would suggest trying to automate the # cleaning but that probably requires some regexp and sed skills and a lot can go wrong. Think [some local link](#target), just as an example that there's probably many situations where you don't want to get rid of the # even if it's not at the beginning of a line. So I don't recommend it.
Anyway, any thoughts or advice on this are welcome!
Here come the thoughts:
Making the tag identifier configurable is a sensible idea in general. You are the second one asking for it .
Making it so configurable that you can use either kw or #kw will be harder to implement and more difficult to understand by users not comfortable with regular expressions. So my bet would be: get rid of the #kw now, stop doing that, chances are that a single prefix (like kw) will be supported soon.
Syntax highlighting will be a problem: Syntax files are not configurable, AFAIK. You can only have a fixed syntax. So when you configure a different tag prefix, the plugin code will cope - but the syntax highlighter will still want #s. You could, of course, hack the syntax file -- but you would need to re-hack after every update of the package.
Well, there is an option: I can dynamically highlight tags the same way I highlight (underline) the note links. That's a bit more work but it can be done. He said.
I will look into this but I can't promise it will be finished super-quickly.
@rene said:
I will look into this but I can't promise it will be finished super-quickly.
... but quickly
I haven't updated the README yet, but when you update the package:
you can add "tag_prefix": "kw", into the package's user settings
tags are now underined, too
The underlining is necessary because the syntax highlighter cannot be brought to highlight programmatically. But the underlining is set to the tag color, which makes your custom tags stand out almost as well as fully colored tags.
Using default # (syntax coloring kicks in):
Using kw:
Using #? for tag selection, #! for tag list, [ctrl]+[enter] to search for tag referencing notes, and advanced tag search work with kw, too.
After some digging I've found the solution and I share it here. I needed to add the "downloader_precedence" section inside my Package Control.sublime-settings file. Here it is for further reference if someone has the same problem:
After some digging I've found the solution and I share it here. I needed to add the "downloader_precedence" section inside my Package Control.sublime-settings file. Here it is for further reference if someone has the same problem:
It seems there are some problems with GitHub as I can't install the package on Mac OS X.
The console shows the following error:
[...]
@Vagabondo Thanks a lot for sharing this! Many others are facing the same problem! Cool that you have found a workaround!
Judged by the error message it appears that GitHub has an invalid SSL certificate which I find very odd for such a big tech company. I, too, hope they or package control will fix this situation soon. Things like this just shouldn't happen, given it's 2018...
@Jaycel_Adkins well, download this, unzip it, and copy the ag.exe (might show up as ag without .exe, depending on your settings) to a directory that is in your PATH (Google is your friend). Alternatively (to the PATH stuff), use the setting:
// fall-back: location of ag if it cannot be found in the PATH
"path_to_ag": "/usr/local/bin/ag",
and change /usr/local/bin/ag to c:/wherever/you/copied/ag.exe
@rene said: @Jaycel_Adkins well, download this, unzip it, and copy the ag.exe (might show up as ag without .exe, depending on your settings) to a directory that is in your PATH (Google is your friend). Alternatively (to the PATH stuff), use the setting:
// fall-back: location of ag if it cannot be found in the PATH
"path_to_ag": "/usr/local/bin/ag",
and change /usr/local/bin/ag to c:/wherever/you/copied/ag.exe
Inspired by the beautiful screen-shots of The Archive, I tried to create a Solarized (Light) based color scheme for sublime_zk:
I tested it with the following markdown packages:
just Markdown
Markdown and MarkdownExtended
If you want to try it out, update sublime_zk and change your color scheme to Solarized (Light)-ZK.
If you like the most close-to-the-archive aesthetics, download the Ubuntu Mono fonts and install the following 4 by double-clicking them:
UbuntuMono-R.ttf
UbuntuMono-RI.ttf
UbuntuMono-B.ttf
UbuntuMono-BI.ttf
I used the following settings in the screen-shot:
// Solarized inspired by The Archive
"font_face": "Ubuntu Mono", // only if you have them installed
"font_size": 18,
"line_padding_bottom": 4,
"line_padding_top": 4,
"line_numbers": false,
"gutter": true,
"margin": 60,
//"wrap_width": 80,
BTW: Huge kudos to @ctietze (and @Sascha) for creating The Archive!!! It's really a beautiful piece of software!
Haha, thanks! Ironically, friends I talked to about the UI found the color and font setting abysmal. One Cult of Mac comment even awarded The Archive a verdict of "The most ugly UI", so you might want to pedal back on this
@ctietze said:
Haha, thanks! Ironically, friends I talked to about the UI found the color and font setting abysmal. One Cult of Mac comment even awarded The Archive a verdict of "The most ugly UI", so you might want to pedal back on this
Why you ask me? I have no taste
No, seriously. Maybe the ZK method transforms the brain to prefer "ugly UIs"
If any sublime_zk users want a color scheme that attempts to resemble the nvALT scheme (which I am particularly nostalgic for, since it is where all my zettelkasten'ing began ) you might try out the no-frills theme I jury-rigged (that is, reverse engineered) from another similar theme.
It is characterized almost exclusively by a tan background and black font, at all levels of encoding. As basic as can be. Simply set your font_face to "Courier" and you're off to the races.
Example:
NOTE: I am not a programmer, so I cannot vouch for the elegance or stability of this theme. In fact, I can almost certainly guarantee that it is not elegant, and can only say that it has been stable for me.
I just added the C64-ZK color scheme to the package
For a perfect C64 experience, download the best C64 True Type Font, unzip it, and install the C64 Pro Mono.ttf by double clicking it.
I used the following sublime_zk settings for the screen-shot:
"font_face": "C64 Pro Mono", // only if you have them installed
"color_scheme": "Packages/sublime_zk/C64-ZK.tmTheme",
"font_size": 12,
"line_padding_bottom": 4,
"line_padding_top": 4,
"line_numbers": false,
"gutter": true,
"margin": 80,
"wrap_width": 80,
Ok, @rene , I have a request regarding citekeys -- let's see if it's possible.
I use mmd-style citations, and find it slightly (but only slightly) troublesome that the format of the in-text citation is [][#citekey] rather than [#citekey]. The way it is, I have to move the cursor back through the citekey in order to insert the page reference. As in all things, I prefer to move forward rather than backward
If the latter [#citekey] format were standard (with the preceding brackets left out) I could simply type the page reference in brackets before initiating the citation short cut: [, #. (I have gone in to the .py file a few time and altered the format to my preference, but obviously it reverts whenever I upgrade.)
My question is: would it be possible to incorporate the insertion of the page reference into automatic citekey generation? For example, would it be possible to somehow incorporate the page number into the citekey shortcut, such that typing (for example) "48[#", and then selecting the bibref from the dropdown menu would result in the insertion of [48][#Ahrens2017] (again, for example)?
@argonsnorts said:
Ok, @rene , I have a request regarding citekeys -- let's see if it's possible.
...
My question is: would it be possible to incorporate the insertion of the page reference into automatic citekey generation? For example, would it be possible to somehow incorporate the page number into the citekey shortcut, such that typing (for example) "48[#", and then selecting the bibref from the dropdown menu would result in the insertion of [48][#Ahrens2017] (again, for example)?
What do you think?
Good you bring this up. I don't use mmd, so I don't feel the pain
I think I can help you, my suggestions are:
placing the cursor into the first pair of brackets on insertion. So [x][#citekey] would be inserted, where x is the cursor.
if text is selected when running ZK: Insert Citation, then use the text to put it into the first pair of brackets (and don't move the cursor there ) --- of course, this only works, if you:
run the command via the command palette
or assign a non-text-destroying keyboard shortcut
I find this more intuitive than the 48[ approach, would that be OK with you, too?
I also find the order: citekey first, then page ref more intuitive....
Comments
Hello! I just stumbled on this discussion and I'm new to this forum, but this plugin is the exact tool I've been looking for. And it's so much better than I could have imagined. I am amazed! It feels as if someone looked into my brain but I guess we're simply not alone with our problems and it seems, you built a solution
I just installed it and will be trying it out during the next few days. I'm super excited! Thank you so much for your effort, @rene !
Hello, @rene!
It's incredibly useful and full of wonderful features.
First, I want to thank you for this brilliant plugin and all the enormous work you've done to develop it!
However, I also have a question -- or maybe a feature request. Is there any way to use something other than [#] for tags? The problem is, I have a long-established convention where I use [kw] to denote tags. It started years ago, when I tried to make OneNote my research database -- and OneNote utilizes Windows search, which disregards special symbols. So I chose to use constructed words like kwsociety, kwidentity etc.
By the time I switched to Sublime Text, it became a habit, and I now have over 200 tags starting with [kw]. Before instlling your plugin, I used Sublime auto-completion list to manage them, and I setup [kw] as a trigger for auto-completion. However, sublime_zk overrides the built-in auto-complete feature, so my tag list stopped working. Also, sublime_zk assumes that tags always start with [#].
Now, one of the easiest solutions is, of course, to use the replace command either to add [#] sign before [kw], or to replace [kw] with [#]. I chose the first option, because it would be easy to revert back if needed. So now all my tags start with [#kw].
However, I've also been using [#] sign to format titles in notes. It was never an issue before, because of my [kw] convention for tags. But now, even after adding [#] sign to tags, I have a problem: when I try to use [#][?] or [#][!] options, I get a lot of extra words, which are not tags. For this reason, I hesitate to install Silver Searcher -- even with persistent search results, I'd still have too much noise.
I've been thinking what to do in this situation. Combing through hundreds of notes manually to get rid of the [#] sign in titles is not an option, and I don't know how to automate this process. Hence my question: if it were possible to choose another sign for tags, I could revert to my [kw] convention (or use a [#kw] combination, since I've already renamed my tags).
Anyway, any thoughts or advice on this are welcome!
Hi @Julia,
I can dig into why the plugin doesn't cooperate with the built-in auto completion. And yes,
#is assumed, more on that further down.That is a good idea in theory
This is where the theory falls short
But what I don't get is you being afraid of the Silver Searcher. In my opinion you wouldn't get more messy output than you do now. You'd just get it much more quickly.
I would suggest trying to automate the
#cleaning but that probably requires some regexp and sed skills and a lot can go wrong. Think[some local link](#target), just as an example that there's probably many situations where you don't want to get rid of the#even if it's not at the beginning of a line. So I don't recommend it.Here come the thoughts:
Making the tag identifier configurable is a sensible idea in general. You are the second one asking for it
.
Making it so configurable that you can use either
kwor#kwwill be harder to implement and more difficult to understand by users not comfortable with regular expressions. So my bet would be: get rid of the#kwnow, stop doing that, chances are that a single prefix (likekw) will be supported soon.Syntax highlighting will be a problem: Syntax files are not configurable, AFAIK. You can only have a fixed syntax. So when you configure a different tag prefix, the plugin code will cope - but the syntax highlighter will still want
#s. You could, of course, hack the syntax file -- but you would need to re-hack after every update of the package.Well, there is an option: I can dynamically highlight tags the same way I highlight (underline) the note links. That's a bit more work but it can be done. He said.
I will look into this but I can't promise it will be finished super-quickly.
... but quickly
I haven't updated the README yet, but when you update the package:
"tag_prefix": "kw",into the package's user settingsThe underlining is necessary because the syntax highlighter cannot be brought to highlight programmatically. But the underlining is set to the tag color, which makes your custom tags stand out almost as well as fully colored tags.
Using default
#(syntax coloring kicks in):Using
kw:Using
#?for tag selection,#!for tag list,[ctrl]+[enter]to search for tag referencing notes, and advanced tag search work withkw, too.@Julia Oh, and BTW I also made the package not suppress completions anymore.
@Julia: In the long term, the
#ambiguity should be resolvable if you stick to adding a space in titles:(Some Markdown converters won't recognize titles if you omit the space, by the way, though most will.)
You can do this with a regular expression bulk "search & replace" command -- if you get rid of the
#kwfirst, that is.See this demo: https://regexr.com/3mjaa
Author at Zettelkasten.de • https://christiantietze.de/
I guessed her problem was that she used
#within the titles@Julia ?
The plugin never returns titles as tags already, not even if there is no space between
#and rest at the beginning of a line:So from that I concluded she has some "more sophisticated"
#use in her titles...Seems you're famous!
macdrifter.com/2018/03/sublime-zk.html
Yaaayyyyyy!
Congratulations! Seems Gabe really likes it
Author at Zettelkasten.de • https://christiantietze.de/
Hello Rene,
It seems there are some problems with GitHub as I can't install the package on Mac OS X.
The console shows the following error:
**startup, version: 3143 osx x64 channel: stable
...
Package Control: Error downloading repository. HTTP exception InvalidCertificateException (Host api.github.com returned an invalid certificate ([SSL: TLSV1_ALERT_PROTOCOL_VERSION] tlsv1 alert protocol version (_ssl.c:548))) downloading https://api.github.com/repos/renerocksai/sublime_zk.
Package Control: Error downloading repository. HTTP exception InvalidCertificateException (Host api.github.com returned an invalid certificate ([SSL: TLSV1_ALERT_PROTOCOL_VERSION] tlsv1 alert protocol version (_ssl.c:548))) downloading https://api.github.com/repos/renerocksai/sublime_zk.
Package Control: No updated packages
reloading settings Packages/User/Package Control.sublime-settings**
Of course I can install it manually, but I prefer the correct way for easier updates.
Hope the issue will be fixed soon.
Best.
V.
Hello again,
After some digging I've found the solution and I share it here. I needed to add the "downloader_precedence" section inside my Package Control.sublime-settings file. Here it is for further reference if someone has the same problem:
{
"bootstrapped": true,
"debug": true,
"downloader_precedence":
{
"linux":
[
"oscrypto",
"urllib",
"curl",
"wget"
],
"osx":
[
"curl",
"urllib"
],
"windows":
[
"wininet",
"oscrypto"
]
},
"in_process_packages":
[
],
"installed_packages":
[
"AcademicMarkdown",
"Package Control",
"Pandoc Academic",
"sublime_zk"
],
"repositories":
[
"https://github.com/renerocksai/sublime_zk"
]
}
"downloader_precedence": { "linux": [ "oscrypto", "urllib", "curl", "wget" ], "osx": [ "curl", "urllib" ], "windows": [ "wininet", "oscrypto" ] },@Vagabondo Thanks a lot for sharing this! Many others are facing the same problem! Cool that you have found a workaround!
Judged by the error message it appears that GitHub has an invalid SSL certificate which I find very odd for such a big tech company. I, too, hope they or package control will fix this situation soon. Things like this just shouldn't happen, given it's 2018...
Hello,
Downloaded both ST3 and ZK Package to begin my slip box. Completely new to everything.
Is there a good step by step on how to install SILVER SEARCHER plugin on a ST3 Windows machine?
Apologies for the list of very basic questions that likely will be forthcoming in the future.
Thanks for doing this!
Jaycel
The README lists 3 sources about installing ag on Windows. Probably the easiest one is to download a release from GitHub.
Hi Rene,
Thanks for the reply! I saw those, but I'm novice enough that I don't understand what I am looking at there.
Jaycel
@Jaycel_Adkins well, download this, unzip it, and copy the
ag.exe(might show up asagwithout.exe, depending on your settings) to a directory that is in your PATH (Google is your friend). Alternatively (to the PATH stuff), use the setting:// fall-back: location of ag if it cannot be found in the PATH "path_to_ag": "/usr/local/bin/ag",and change
/usr/local/bin/agtoc:/wherever/you/copied/ag.exeThanks! I'll give it a shot.
NEWS!
Inspired by the beautiful screen-shots of The Archive, I tried to create a Solarized (Light) based color scheme for
sublime_zk:I tested it with the following markdown packages:
MarkdownMarkdownandMarkdownExtendedIf you want to try it out, update
sublime_zkand change your color scheme toSolarized (Light)-ZK.If you like the most close-to-the-archive aesthetics, download the Ubuntu Mono fonts and install the following 4 by double-clicking them:
UbuntuMono-R.ttfUbuntuMono-RI.ttfUbuntuMono-B.ttfUbuntuMono-BI.ttfI used the following settings in the screen-shot:
// Solarized inspired by The Archive "font_face": "Ubuntu Mono", // only if you have them installed "font_size": 18, "line_padding_bottom": 4, "line_padding_top": 4, "line_numbers": false, "gutter": true, "margin": 60, //"wrap_width": 80,BTW: Huge kudos to @ctietze (and @Sascha) for creating The Archive!!! It's really a beautiful piece of software!
Haha, thanks!
Ironically, friends I talked to about the UI found the color and font setting abysmal. One Cult of Mac comment even awarded The Archive a verdict of "The most ugly UI", so you might want to pedal back on this 
Author at Zettelkasten.de • https://christiantietze.de/
Why you ask me? I have no taste
No, seriously. Maybe the ZK method transforms the brain to prefer "ugly UIs"
As the guy currently trying to implement ZK in org-mode, I have no idea what you're talking about.
On the heels of Rene's color scheme announcement:
If any sublime_zk users want a color scheme that attempts to resemble the nvALT scheme (which I am particularly nostalgic for, since it is where all my zettelkasten'ing began
) you might try out the no-frills theme I jury-rigged (that is, reverse engineered) from another similar theme.
It's called "Zettel Coffee," and the .tmTheme file can be found here: https://www.dropbox.com/s/3pbkm1tuwhe7ovn/ZettelCoffee.tmTheme?dl=0
It is characterized almost exclusively by a tan background and black font, at all levels of encoding. As basic as can be. Simply set your font_face to "Courier" and you're off to the races.
Example:
NOTE: I am not a programmer, so I cannot vouch for the elegance or stability of this theme. In fact, I can almost certainly guarantee that it is not elegant, and can only say that it has been stable for me.
@argonsnorts
Awesome minimalist theme!!!!
By the look of it, since you don't do anything fancy, this is stable
Speaking of RETRO:
The C64 is back!!!
I just added the
C64-ZKcolor scheme to the packageFor a perfect C64 experience, download the best C64 True Type Font, unzip it, and install the
C64 Pro Mono.ttfby double clicking it.I used the following
sublime_zksettings for the screen-shot:"font_face": "C64 Pro Mono", // only if you have them installed "color_scheme": "Packages/sublime_zk/C64-ZK.tmTheme", "font_size": 12, "line_padding_bottom": 4, "line_padding_top": 4, "line_numbers": false, "gutter": true, "margin": 80, "wrap_width": 80,@argonsnorts, you just received an honorable mention in the README
!
If it's OK with you, I can add your screen-shot, too?
@rene totally cool with me!
____Cool____ with me, too
Ok, @rene , I have a request regarding citekeys -- let's see if it's possible.
I use mmd-style citations, and find it slightly (but only slightly) troublesome that the format of the in-text citation is
[][#citekey]rather than[#citekey]. The way it is, I have to move the cursor back through the citekey in order to insert the page reference. As in all things, I prefer to move forward rather than backwardIf the latter
[#citekey]format were standard (with the preceding brackets left out) I could simply type the page reference in brackets before initiating the citation short cut: [, #. (I have gone in to the .py file a few time and altered the format to my preference, but obviously it reverts whenever I upgrade.)My question is: would it be possible to incorporate the insertion of the page reference into automatic citekey generation? For example, would it be possible to somehow incorporate the page number into the citekey shortcut, such that typing (for example) "48[#", and then selecting the bibref from the dropdown menu would result in the insertion of
[48][#Ahrens2017](again, for example)?What do you think?
Good you bring this up. I don't use mmd, so I don't feel the pain
I think I can help you, my suggestions are:
[x][#citekey]would be inserted, wherexis the cursor.ZK: Insert Citation, then use the text to put it into the first pair of brackets (and don't move the cursor thereI find this more intuitive than the
48[approach, would that be OK with you, too?I also find the order: citekey first, then page ref more intuitive....
But then again, I don't have to live with it