Make it possible to swap out implimentation

[dncnmcdougall]

I use a different ID scheme and would like to make calls to an external program to keep track of my thoughts. For speed and advanced features like similarity search. However this plug-in is great, tidy, simple and minimal. It would be better that my extensions are done as a separate plug-in so I can maintain them independently. One way to do this, the traditional way, is to pass functions into the config. But this clutters the config and increases the complexity of the code. Alternatively, because we are using Lua we can directly overload functions in the loaded table (I think). So I could do something like:

require"zettelkasten".browser.get_notes = function my_custom_notes_function()
-- do something
end

and I think everything should work fine.

So here is a list of the functions I would like to customise:

1. The id scheme.
   • This requires the generate id function. It needs to take at least a parent note as an option (and possible a list of all the notes)
   • An optional nice to have is a custom sort function for the browser view.
2. The get_notes() function to overload the retrieval of note details.
3. The get_tags() function to overload the retrieval of tags. (This is optional as it can be done by parsing the notes, but having it available opens this up to being faster on large sets of data)
4. A function that fills the content of a new note (template function.)
5. Bonus: It would be nice to have a post write callback that could be overloaded. Initially this would just call the get_note(id) function to reparse and update the cache.

How do these requirements sound?

0. First my claim that modules can have parts overwritten on the fly needs to be verified.
1. can be done simply by extracting generate_id into its own module or at least a public function in browse. As to a custom sorter this can just sit next to the id function. Initially it can just pass back the given table (ie. do nothing.)
2. is already done. The follow up question is whether the documentation for this needs to be written.
3. is optional. Even for my case ~250 files the current implementation will be fast, so this is not urgent. However exposing it may be helpful.
4. is definitily a nice to have. Perhaps we can rework ZkNew so that it asks for an id separately from filling in the new file? This would allow the content of the file to be contained in a function that could be overloaded.
5. This is just an auto command to add and a function to call. The trick here will be not calling it for all markdown files, only notes.

[Furkanzmc]

Hello Duncan!

Sorry for getting back to you late.

require"zettelkasten".browser.get_notes = function my_custom_notes_function()
-- do something
end

and I think everything should work fine.

So here is a list of the functions I would like to customise:

1. The id scheme.

   * This requires the generate id function. It needs to take at least a parent note as an option (and possible a list of all the notes)

You've already introduced some options for the IDs and file names. I think it'd be consistent to introduce another one for this purpose. We are just using NOTE_ID_STRFTIME_FORMAT inside zettelkasten.lua for this. This new config option can either be a pattern for a function that is executed to generate the note ID.

   * An optional nice to have is a custom sort function for the browser view.

This doesn't need to be added to the plugin. Take a look at the wiki to see how you can customize this.

2. The get_notes() function to overload the retrieval of note details.

get_notes() is already a public method. I think you can replace that with your implementation to extend what kind of information it returns. It just returns a table with information about each note. Keep in mind that the existing keys in the table would need to stay the same but you can add whatever you'd like there. Also, internally, the note information is cached if the file has not changed since the last time the browser content was created, you may want to do the same for the new information you need.

3. The get_tags() function to overload the retrieval of tags. (This is optional as it can be done by parsing the notes, but having it available opens this up to being faster on large sets of data)

This also already a public method. You can replace it with your own, use the original and extend the data etc...

4. A function that fills the content of a new note (template function.)

You don't need a new function for this. In your ftplugin, you can check if the new Markdown file is a zettelkasten note or not and if it is, use :help skeleton to fill the contents (Or any other method you choose).

5. Bonus: It would be nice to have a post write callback that could be overloaded. Initially this would just call the `get_note(id)` function to reparse and update the cache.

I don't understand what exactly you mean by this.

How do these requirements sound?

0. First my claim that modules can have parts overwritten on the fly needs to be verified.

I don't understand what you mean. Can you elaborate?

1. can be done simply by extracting `generate_id` into its own module or at least a public function in browse.

See my comment above for this.

   As to a custom sorter this can just sit next to the id function. Initially it can just pass back the given table (ie. do nothing.)

See my comment above.

2. is already done. The follow up question is whether the documentation for this needs to be written.

It'd be nice to have a documentation for it so we commit to a certain data structure for the return type.

3. is optional. Even for my case ~250 files the current implementation will be fast, so this is not urgent. However exposing it may be helpful.

See my comment above for it. This can already be customized similar to get_notes() or you could even write your own :help tagfunc and set the option with to your function with your plugin.

4. is definitily a nice to have. Perhaps we can rework ZkNew so that it asks for an id separately from filling in the new file? This would allow the content of the file to be contained in a function that could be overloaded.

I don't think we need to customize the plugin for this. What we can do is maybe add an even for when a new note is created so that user can listen for it and update the buffer.

5. This is just an auto command to add and a function to call. The trick here will be not calling it for all markdown files, only notes.

Since I don't understand what you mean above, I won't be able to respond to this.

[dncnmcdougall]

Hi, I have made the above extensions, finally. They are in pull request #25. It addresses items 1-3 and adds the contains function I had previously added.

In terms of item 5. Currently a file is only [re]passed when get_notes is called. This means that if I change the titile of a file, or add a tag. Those changes are not imediatly updated. But, I suppose, that is not really a problem as any way in which you would view that information causes a reparsing.

But an alternative would be to reparse more eagerly. For example in an autocommand that executes when the file is written. This leads to the inevitable question: how do I only parse a markdown file when it is a note and not generally? And that is the second this I mentioned, the 'trick' as it were.

In terms of item 0. I just had to check that plugin functions can be overwritten in the init.lua. They can be which is great.

An item 6. on the list would be:

6. Only initialise the zettlekasten options for notes.

This could be implemented with the contains function. I have given an example in the documentation. This is what I have in my markdown ftplugin file.

[mills-nick]

I was searching for a way to configure templates for new notes and found this. I tried adding an ftplugin for markdown files, but it doesn't get triggered when doing ZkNew for some reason. Neither does my template plugin 'motosir/skel-nvim'. Both of these are triggered when creating a markdown file via :e my.md