A series of tools independent of this but complements this plugin in our org

[neo451]

I would say this is close to the idea of community plugins for the app.

• calendar.nvim for opening dailies, inserting dates, changing dates.
• bulltes.nvim not maintained, inserts list markers and renumbers
• kanban.nvim author is happy to work with us.
• quickadd.nvim

[marcocofano]

Hi,

Some self promotion but also a proposition...

I have a plugin to manage a folder of excalidraw files and templates to be opened with the Excalidraw app (if you use the PWA version)

it's excalidraw.nvim

I would be happy to integrate it in some form in the org's ecosystem.

If you dig into the code you can see that it has the same architecture of obsidian.nvim (I shamelessly too inspiration fro it) which I guess might be goo for the integration and configuration, like it could be made aware of the obsidian vault for its own configuration.

As you wish I do not know which methods of integration are available in case you are interested.

Some features

• store and open excalidraw scenes in a unified folder
• manage templates basically draw some things and save for repeated use, or keep the same background color.
• Pickers (only Telescope for now) for scenes and templates
• puts a link to the excalidraw new scene just created in the location where you are.

some improvements wish list:

• be able to export a png / svg and use image.nvim to get thumbnails
• be able to use it with the browser Excalidraw app.
• extend it to other tools, drawio for example
• improve handling of the json file definition
• more tests :)
• ???

well let me know if you are interested...

[neo451]

wow, nice plugin!

fun fact I actually is not really fond of the client api, just because we only ever spawn one client per editor session, and the client just holds some config options if you look at it.

A better practice I have seen from other plugins is our api should contain:

1. one api function per command.
2. some objects that we will spawn again and again (in obsidian.nvim's case: Note object).
3. and some helpers, like parsing note links and etc.

function per command means like you can either call :Obsidian tags <tag> or :lua require"obsidian".tags(<tag>), or :lua require"obsidian".tags({tag=<tag>}), and latter could provide more flexibility. Having a client is just a barrier for user scripting for me. All the big and popular plugins like telescope, mini and sncaks do this.

Also config options can just stay in require"plugin.config", and safely cached by lua, other requires will read from the result of the setup.

These are just suggestion and thinking out loud, because I want to refactor the api before 4.0.0 as well.

On the point of integration

1. I plan to have a README/wiki section for well integrated plugins, definite this would count as one.

2. Configuration, there's https://lazy.folke.io/spec#spec-advanced, but I don't like it very much. A good practice could be just you read the configuration from require"obsidian".get_client().opts.excalidraw, later from require"obsidian.config".excalidraw if there's one.

3. Also I would prefer you stay close to the design of the excalidraw plugin from the app, like the default folder name for store things and other options that could make sense. There's also Features requests from the og repo #72 where we could just read the json settings from the plugins, so staying close to that is good.

4. Then there can be a Obsidian excalidraw command that is auto generated if we detect your plugins is present. and calls your api.

[marcocofano]

Marvelous!!!

I can work on all that and maybe get back when the integration is easier. I agree with the client architecture being more of a hindrance. In the end it looks to me that it is there just as a singleton for the configuration to be available everywhere.

Your example for the configuration loading of course still uses the get_client() which is what we have now.. maybe we do this first and then when the refactoring of the main API is ready we think about the plugins integration holistically.

good point on staying close to original APP plugin.. I will review the specs and do the changes.

thanks a lot for the feedback!

P.S. this is not the only goody I wanted to propose, stay tuned :)

[neo451]

@marcocofano
See the wiki here when you want to build the integration:
https://github.com/obsidian-nvim/obsidian.nvim/wiki/Extensions