Rene's SublimeText for Zettelkasten - Package, Talk and more

toolboxen

@rene said:
@toolboxen just a quick question if you don't mind: a fellow Windows SublimeText user reported that [[ doesn't work for him.

We traced it back to:

command: insert_snippet {"contents": "[$0]"}

in the console.

Did you also encounter this problem? I am thinking of adding some ALT+[ or something to the Windows keymap if this is a Sublime-Windows problem.

Scary stuff at https://github.com/SublimeTextIssues/Core/issues/392

No I've never had this problem. Win8.1, latest Sublime Text, English keyboard. [[ worked fine for me in previous builds and when I default to vanilla Sublime installation all the auto-completion works great for me.

On a default installation < shouldn't trigger anything. If you are in source scope or in HTML and keep typing after < then you'll see some auto-complete options, for example typing <a offers me the option to choose from inserting all sorts of HTML tags, the first one being <a href=""></a>. But the trigger only happens when I have typed a character after typing the < symbol.

For me, on default installation: just typing < does nothing. It should not be triggering the files completion list.This leads me to believe that either the syntax might not be properly applied to the current buffer, or there's some kind of bug with the way auto-completion is implemented in the plugin.

I don't think this is related to the github issue you linked. The way to determine if it is or not: nuke completely your Sublime text install, install from scratch no packages, and test < in both HTML and Markdown syntax to determine the baseline behaviour on your system.

UPDATE:

After installing the latest build, typing [[ triggers the overlay, to allow me to select from the notes as usual. All is well. But typing < triggers the auto-complete popup showing me a list of notes. This is abnormal, and changed from the default functionality I mentioned above. So the plugin is somehow triggering the auto-complete popup on <. Somehow typing < has been linked to ctrl+space functionality.

rene

@toolboxen said:
No I've never had this problem. Win8.1, latest Sublime Text, English keyboard.

Aaah, it's probably an issue with the German keyboard then. This might be related to the issue mentioned in my post. I personally only use English keyboards so I didn't notice.

[[ worked fine for me in previous builds (although it is broken in current build I'll add an error issue for you), and when I default to vanilla Sublime installation all the auto-completion works great for me.

Yeah, I broke it but it's fixed again. I had renamed the commands to have a zk_ prefix and forgot to update some lines of code that are issuing commands.

On a default installation < shouldn't trigger anything. If you are in source scope or in HTML and keep typing after < then you'll see some auto-complete options, for example typing <a offers me the option to choose from inserting all sorts of HTML tags, the first one being <a href=""></a>. But the trigger only happens when I have typed a character after typing the < symbol.

This is interesting. On Linux (I have two Linux laptos I use, one is pretty default install) completion gets triggered via <. [ctrl]+[space] has no effect. That link to the sublime documentation also mentions < for completion (in HTML & code)

For me, on default installation: just typing < does nothing. It should not be triggering the files completion list.This leads me to believe that either the syntax might not be properly applied to the current buffer, or there's some kind of bug with the way auto-completion is implemented in the plugin.

Again, on Linux it seems < is the completion key, and when the syntax is applied, it triggers the plugin's on_query_completions. This method exits if it's not in text.html.markdown just to be sure. If it is in markdown, it offers the completion list. The plugin does not choose how completion is triggered. It only responds to the event.

I don't think this is related to the github issue you linked. The way to determine if it is or not: nuke completely your Sublime text install, install from scratch no packages, and test < in both HTML and Markdown syntax to determine the baseline behaviour on your system.

The mentioned issue suggests that some key mappings don't behave well on non-(US)-English keyboards. That's why I mentioned it.

toolboxen

@rene sorry, I updated my previous post, please see update.

rene

@toolboxen said:
But typing < triggers the auto-complete popup showing me a list of notes. This is abnormal, and changed from the default functionality I mentioned above. So the plugin is somehow triggering the auto-complete popup on <. Somehow typing < has been linked to ctrl+space functionality.

Interesting that it seems to work with < and [ctrl]+[space] on your system. On my Mac (pretty non-default Sublime install grown over years) only [ctrl]+[space] triggers. Maybe there is a side-effect caused by the plugin / its syntax, I agree. But it's definitely not something obvious. It does not provide anything that's actively triggering code completion afaict.

toolboxen

Again, on Linux it seems < is the completion key

Not quite.

By default < and [ctrl]+[space] are slightly different functionality on any platform/OS. For a vanilla install of Sublime on any OS < doesn't trigger the popup, it only shows the popup after you start typing a second character. [ctrl]+[space] force triggers the popup manually.

After installing the plugin, now the functionality of both have merged somehow, so that < force triggers the popup just like [ctrl]+[space]

rene

@toolboxen said:

Again, on Linux it seems < is the completion key

Not quite.

By default < and [ctrl]+[space] are slightly different functionality on any platform/OS. < doesn't trigger the popup, it only shows the popup after you start typing a second character. [ctrl]+[space] force triggers the popup manually.

After installing the plugin, now the functionality of both have merged somehow, so that < force triggers the popup just like [ctrl]+[space]

I found it!

In my defaullt preferences (I did not put this in, it's maybe a recent addition that affects recent versions of SublimeText):

/ Additional situations to trigger auto complete
    "auto_complete_triggers": [ {"selector": "text.html", "characters": "<"} ],

As our scope is text.html.markdown we get triggered! You might have a similar setting?

toolboxen

That setting has been there since Sublime Text 2, it's a special case to allow HTML tag completion to be present in text scope, whereas normally HTML tag completion would only be present in source scope.

So maybe the plugin is being too greedy to see this trigger as being the same type of trigger as ctrl+space?

rene

And just for the sake of completeness I mention it here: [ctrl]+[space] does not work on Linux's SublimeText default install for triggering completion. That has been disabled on purpose. See https://github.com/SublimeTextIssues/Core/issues/1251

toolboxen

Sure, but that doesn't solve the problem of default < functionality changing when the plugin is installed. and after removing plugin, the < functionality reverts back to default.

rene

@toolboxen said:
That setting has been there since Sublime Text 2, it's a special case to allow HTML tag completion to be present in text scope, whereas normally HTML tag completion would only be present in source scope.

So maybe the plugin is being too greedy to see this trigger as being the same type of trigger as ctrl+space?

1. The plugin has no control over triggering completion. It gets asked if it can contribute to the completion list when sublime triggers the completion
2. See my previous post: text.html in combination with < triggers completion. Since we use standard markdown, our scope is text.html.markdown which is a subset of text.html so sublime triggers autocomplete. Has nothing to do with greediness of the plugin.
3. The plugin is not told what key triggered the call to on query_completions

rene

@toolboxen the reason why you might not get completions in markdown docs when you type < is: there is no plugin responding to it. Our plugin, however, does respond. Again, the plugin cannot see what triggered it.

toolboxen

See my previous post: text.html in combination with < triggers completion.

It doesn't by default. I am uploading some GIFs on github for you to see what I'm seeing from vanilla Sublime install and then after installing the plugin.

@toolboxen the reason why you might not get completions in markdown docs when you type < is: there is no plugin responding to it. Our plugin, however, does respond. Again, the plugin cannot see what triggered it.

I see. Well, I'm assuming it shouldn't be responding. And it didn't used to until recently. When I first test the plugin, I tested < completion versus file completion and they were two separate functions but now < is triggering file completions as well as HTML tag completion.

I should have mentioned that sooner, sorry I forgot to mention I noticed a difference over course of plugin development.

rene

@toolboxen said:

See my previous post: text.html in combination with < triggers completion.

It doesn't by default. I am uploading some GIFs on github for you to see what I'm seeing from vanilla Sublime install and then after installing the plugin.

It does by default. Sorry. But it's in Preferences.sublime-settings --- (Default) then I consider it by default. The setting clearly mentions the < key and the text.html scope.

I see. Well, I'm assuming it shouldn't be responding. And it didn't used to until recently. When I first test the plugin, I tested < completion versus file completion and they were two separate functions but now < is triggering file completions as well as HTML tag completion.

I think it should respond because: When we say we want to support auto_complete to bring up a note picker, then we have to live with it that Sublime triggers on the < key because it treats markdown as HTML, as defined by the syntax.

I understand that you mean you didn't see this in previous versions of the plugin. But I am doubting my memories here. Maybe you/we assumed it didn't trigger and we never saw it trigger because we never pressed < in a text.html.markdown scope?
Only way to find out is to use, like, the first commit that introduced the completion and test it again

toolboxen

It does by default.

To clarify: by default just pressing < doesn't trigger the auto-complete popup. Only after pressing < then some letter.

Maybe you/we assumed it didn't trigger and we never saw it trigger because we never pressed < in a text.html.markdown scope?

I'm a heavy user of Sublime and so pressed it a multitude of times

Only way to find out is to use, like, the first commit that introduced the completion and test it again

Sure, also perhaps you might test the default < functionality on LInux just to get a Linux baseline. I got one in Windows here: https://github.com/renerocksai/sublime_zk/issues/21#issuecomment-344531018

rene

@toolboxen said:

It does by default.

To clarify: by default just pressing < doesn't trigger the auto-complete popup. Only after pressing < then some letter.

Sorry. I see it differently. The DEFAULT setting clearly states:

• scope: text.html
• character to trigger auto-completion: <

So it does get triggered, nowhere does it say: and wait for 1 more character. In my point of view: other/default plugins just choose to not bring up the popup immediately but rather wait.

toolboxen

@rene said:
In my point of view: other/default plugins just choose to not bring up the popup immediately but rather wait.

That's the problem. I have no other plugins installed. So we're comparing Sublime text vanilla functionality to the functionality I immediately get when installing the plugin. And that was the original issue as reported by @wangeleile on Github. < should not be triggering any action by itself, it is not actually a keybind.

toolboxen

Sorry. I see it differently. The DEFAULT setting clearly states...

So when I set everything back to default, and when that default setting is applying to my vanilla install I get this functionality:

by default just pressing < doesn't trigger the auto-complete popup. Only after pressing < then some letter.

So at least on my system of Windows with a default vanilla install the default setting expresses itself in that functionality.

toolboxen

If you don't think this is an issue, then no problem with me. I just try to provide whatever information or context I can to help solve the problem. But if not a problem, then no problem!

rene

Ah, OK, our terminology. For me trigger was: triggering the event. for everybody else it was: triggering the popup as a consequence of the handled and not ignored event.

Of course I am trying to fix this, especially after all this discussion

toolboxen

Aha! I see now. > @rene said:

Ah, OK, our terminology. For me trigger was: triggering the event. for everybody else it was: triggering the popup as a consequence of the handled and not ignored event.

That makes sense! I understand now.

Of course I am trying to fix this, especially after all this discussion

Thank you!!

rene

done

(phew )

uh, body was 5 characters short so here comes some more text. My favourite character is <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<,

toolboxen

@rene said:
done

(phew )

uh, body was 5 characters short so here comes some more text. My favourite character is <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<,

Nice. Just tested, and works great now. Thanks again!

rene

You're welcome and thx for being persistent

mediapathic

Bumping this because I think it got lost when I ps'd it at the end of something more interesting:

@mediapathic said:

Question: I would like to change the template for the header that is output when a new file is created. Can you tell me where to find that?

rene

@mediapathic good you bumped this!

Currently it isn't a template but it is hardcoded in sublime_zk.py at line 182:

f.write(u'# {}\ntags = \n\n'.format(title))

Currently the function create_note() receives only 2 parameters: title and file name (which also contains the note id). I can work on some template function. Should be fairly easy to do with python format strings. Will let you know.

mediapathic

@rene said:
Currently the function create_note() receives only 2 parameters: title and file name (which also contains the note id). I can work on some template function. Should be fairly easy to do with python format strings. Will let you know.

Ah ok. So you know what I'm looking for, my files currently have the format

---
uid: 201711150402
tags: #foo, #bar
---

This is, as far as I know, standard formatting for YAML metadata. The --- helps some markdown parsers differentiate metadata, and the keyword: value format is more standardized than keyword = value that yours produces now.

It might be useful to be able to add additional keywords. For a while I had an author: myname field. That became redundant, but if we do figure out a good methodology for sharing and publishing, I suspect people will want to add that in. Several other examples, of course, leap to mind.

rene

@mediapathic said:
Ah ok. So you know what I'm looking for, my files currently have the format

---
uid: 201711150402
tags: #foo, #bar
---

That's easy enough to do. I think I'll make it a setting.

It might be useful to be able to add additional keywords. For a while I had an author: myname field. That became redundant, but if we do figure out a good methodology for sharing and publishing, I suspect people will want to add that in. Several other examples, of course, leap to mind.

That will be trickier because how is the plugin supposed to know what myname is? Would probably need to be configured. But if it's fixed, it can be put in the template directly

Will let you know when it's finished.

mediapathic

@rene said:

That will be trickier because how is the plugin supposed to know what myname is? Would probably need to be configured. But if it's fixed, it can be put in the template directly

Oh, yeah, no, I was thinking the template would just allow you to have more keyword:s created automatically. Filling them in would be manual, like tags are now.

Will let you know when it's finished.

Great! Thanks!

rene

@mediapathic

New note templates are here. In your package's settings (user) just put in a line like this:

    "new_note_template": "---\nuid: {id}\ntags: \n---\n",

• You probably know that \n creates a new line.
• The plugin can insert parameters:
• {id} : the note id like 201712241830
• {title} : note title like Why we should celebrate Christmas
• {file} : the filename of the note like 201712241830 Why we should celebrate Christmas.md
• {path} : the path of the note like /home/reschal/Dropbox/Zettelkasten

Hope this is useful

mediapathic

@rene said:
@mediapathic

New note templates are here. In your package's settings (user) just put in a line like this:

Hope this is useful

Do you... do you ever sleep?