Vision for the project, reasons for forking and next steps

[guspix]

Hey everyone!

I wanted to open up a discussion here about the future of the project, why we forked it under this organization, and where we could go from here.

The reasons for the fork are probably pretty clear: the original project hasn’t been actively maintained for a while, and there are a lot of open issues and PRs waiting for attention. I know a lot of us still rely on this plugin, and personally, I’d really like to see it stay alive and healthy. @epwalsh built a great foundation which a lot of people still find very useful.

Personally, I’d like to keep things as close to the original project as possible. I think the structure, the general workflow, and the way the plugin works all make sense, so I don’t see a need for any big rewrites or shifts in direction. The main goal, for me at least, is just to make sure bugs get fixed, useful improvements get merged, and the project stays compatible with new Neovim versions.

One thing I do think becomes more important now is testing. The original test suite is solid, but with more contributors (and reviewers) getting involved, and not everyone being super familiar with all the code, I think having reliable tests is going to be key to making sure we don’t accidentally break things, especially at the beginning.

I also think it makes sense to stick with semver. It’s what the original project used, and it gives users a clear sense of what to expect when upgrading, especially when it comes to breaking changes. This would mean not changing existing behavior or defaults on minor versions (and maybe not releasing a major version every month?)

As for next steps, my personal thought is that it would be good to:

• Start by going through some of the open PRs from the original repo — there’s already a lot of good work there, and some of it might be easy wins.
• After that, maybe focus on the most upvoted issues, since those are the ones affecting the most people.

That’s just my view though — definitely open to hearing what others think. I also want to figure out how to handle roles and responsibilities going forward. A couple of people like @neo451 and @TheMeaningfulEngineer have already offered to help, which is great, but I’d also love to hear from anyone else who’s interested, whether it’s reviewing PRs, triaging issues, or contributing directly. Also, if anyone disagrees with the general direction of the project I'm all ears.

Would love to hear your thoughts!

[guspix]

A couple more things: I took the liberty of bringing over two of the biggest recent PRs from upstream, which are blink.cmp support and snacks.picker support. I think just merging these two to start is already a big value add to the project while we get comfortable. On the other hand, anyone that just wants to contribute just to fix that specific bug that annoys them or whatever is 100% welcome! The contribution guidelines for the original project, available on the README stand for now.

[TheMeaningfulEngineer]

Like your vision for the project and the release process.
Having stable backwards compatibility is definitely important and I support the prioritization of that.

Thanks for porting the PRs.
So far sounds like too big a chunk for me to take.

I guess I'll just go through the README and actually understand what obsidian.nvim actually does :)
I've been using only a subset for note taking and never really went as far as to understand the whole feature set.
Might go as far as to make some more demo gifs, we'll see.

[adamtajti]

It's nice to read that you forked the repo. I'm not a lua guy, in fact that PR was one of my first larger contribution in the language, so I don't feel that comfortable about that change. I guess it's better than having no support for blink, but I think there will be a couple of bugs to fix in that and maybe in the original nvimcmp sources as well. I'll point my config to your repo for now and I might contribute later on.

[neo451]

I think we can just merge the 2 PRs now? To me they all looks and works good. Maybe we can merge it and make a reddit post or something and start knowing the codebase by having more user reports for these features.

Following are some of my initial ideas:

Ideas for long term robustness

Better user troubleshooting:

• a minimal reproduce script for users to avoid plugin conflicts, refer to https://github.com/olimorris/codecompanion.nvim?tab=readme-ov-file#toolbox-troubleshooting
• there's already a nice debug info function, but checkhealth is a more idiomatic place for it to live.

Packaging the plugin:

• rocks.nvim support, someone have already uploaded the repo to luarocks, so we just have to add install instructions to the README: Rocks install obsidian.nvim.
• add a lazy.lua file, see https://lazy.folke.io/packages, so that installation would be simplified to { "obsidian-nvim/obsidian.nvim", opts = {} }

Native impl for completion and picking

• omnifunc completion + quickfix list to show links/backlinks
• working as fallback if user don't use the next shinny completion engine or fuzzy finder, also ease the need for supporting every integration.

Some less "stable" and up to discussion ideas

"namespacing" the usercommands

• having one Obsidian commands helps lazy loaders like lazy.nvim or lz.n, because users can just lazy load the one command. And for now if user follow the install instructions and don't put anything in lazy's cmd field, they can not do something like a quick new note unless they have already been in a markdown buffer and triggered the plugin to load.
• So basically ObsdianNew becomes Obsidian new
• see discussion here: https://github.com/nvim-neorocks/nvim-best-practices?tab=readme-ov-file#speaking_head-user-commands

Have our own async library

• so as to have no required dependency
• very ambitious and very long term
• see discussion here: Are there any plans to remove plenary.nvim as a dependency. NeogitOrg/neogit#1648 (reply in thread)

[ffricken]

I think getting this onto reddit is a good idea, especially to get more people involved.

We also might want to overhaul the ReadMe.

[guspix]

I agree about the Reddit post, I was going to wait a bit until we have something more to show than just merging a couple of open PRs, but it could also be a way to attract more people and get the ball rolling 🤔

[ffricken]

I think we don't really need to have a lot to show, but we should definitely have a little more going on.
Here's what i believe would be beneficial to have:

Readme

• Adjust Documentation to point to our version
• Short list of stuff we are aiming for with the fork
  --> + what's already merged
• Maybe have a maintainer list at the bottom
  --> + remove the donation link
• Maybe include one or two 'works out of the box'-examples with different configurations
  --> The main goal here is to have more people use it, as this will probably kickstart a somehwat natural flow.

Issues

We could already 'port' some issues from before the fork and add some that are important to us. This might give people a good hook to start off of and also shows the direction we're heading (maybe even include some that we do not want and close them with proper reasoning)

If this is something we decide on doing, i might find some time tonight or tomorrow to get this started.

[guspix]

Perfect, that's kind of what I had in mind! I'll add you to the org so you can help with the issues as mentioned. I'm not sure what your timezone is, I'm in Europe so it's getting pretty late, I'll give you access now and tomorrow I'll look more closely at the roles and stuff. Thanks!

[guspix]

Yeah, I hadn't merged the PRs yet just to make sure that they work for other people, but I haven't had any problems so far. The only detail I'd probably like fixed at some point in the future is making choosing completion plugins more like choosing the pickers, where the config would have something like completion = 'blink', instead of having a separate boolean for each source, since then having both as true could be confusing. It would also be cool if it automatically detected which completion plugin you have installed, just like the pickers, defaulting to nvim-cmp if both are configured so as to not change default behaviors. This being said I'll be merging it as it currently is, and these could be future improvements.

@neo451 I love your vision for the project, I completely agree with adding checkhealth, a minimal reproduce script and the lazy.lua file, which could make the whole installation and debugging processes better for users. On the luarocks side, from what I see the uploaded package points to epwalsh's repo. Would we need to upload a separate package pointing to this repo, or is there a way to change the source repo? Could it be an update to the existing package?

With regards to the omnifunc completion + quickfix list to show links/backlinks, it sounds great but I'm not sure what it would entail. Would this mean that a user with a bare neovim install + this plugin could get vault file completions with the default neovim ctrl-n completion? If so that sounds great!

The command namespacing does sound more like current idiomatic neovim, maybe we could brainstorm some ways of approaching this without affecting users too much. I'd guess we would have to start by adding the command and getting feature parity with current commands, and then we could start guiding users toward this command and deprecating the old, until we eventually remove them on a major version change.

@neo451 I added you to the org so I can make you a maintainer, let me know when you accept so I can give you all the permissions you need!

[neo451]

I accepted it! and by the way the omnifunc and quickfix list thing should entail a bare install gets completion and list

[neo451]

I also asked the neorocks developers about moving the rock to our repo: https://github.com/nvim-neorocks/rocks.nvim/discussions/636

[LazyStability]

One issue that needs special attention is this one: epwalsh/obsidian.nvim#779

If there is a security risk in the original repo, how do we go about it? If we get the researcher to share the vulnerability do we publish the fix and leave the original repo open?

[guspix]

Honestly I'm not sure what other option we have, since they already tried getting in contact on the original repo and got no response. My feeling is that it depends on the severity of the vulnerability, we should probably get in contact with the person that opened the issue and see. If it's severe we should probably solve it on our side but also try to contact epwalsh again.

[guspix]

Looking a bit further, epwalsh does have his Twitter link on his profile. We could talk with the person that reported the vulnerability and if it's serious contribute the PR solving it upstream and contact epwalsh through there.

[ffricken]

What's everyone thinking about when to post to reddit and how to go about that? I think we are generally in a solid state, especially with blink and snacks supported.

Also, should we go for the neovim and the obsidian subreddit? Or only one of them?

[neo451]

I think both subreddit is ok.
maybe @guspix would like to do the post? I think we can just expand on what we mentioned in the readme, and make sure to mention and respect the original author is enough.
Needing more maintainers should be mentioned as well.

[neumachen]

Count me in. I was wondering why that repo was no longer active. It's quite useful too.

[ottersome]

Any update on this ? I am really excited to start using it for blink compatibility.

[adamtajti]

ae, the blink changes were merged into main already. If you use the latest blink version, it'll show up a deprecation warning though, so I suggest to checkout the branch from this pull request instead, until that gets merged in: #30

[sotte]

I've contributed to obsidian.nvim in the past, I'm happy to see this fork and that things are moving.

I'm suggesting to to add a bit more information about the structure of the fork (who can merge, what is important, etc) in the README and/or maybe pin an issue that describes the process and gives updates.
Ppl are adding issues and PRs, that is great. It would be sad to lose the momentum! I had a little issue that I wanted to fix but I was not sure if it would just sit in the merge queue for ages.

[TheMeaningfulEngineer]

@guspix and @neo451 are set as maintainers at the moment.
That probably means they can merge PR.
Afaic, that's good enough for now until proven otherwise :)

I plan on doing manual QA as a start and focus on defining the core functionality of the tool.
I'd like to have a stable base and worry about the extensions later (telescope integration, blink etc...).

Practically, that means I'll gladly test buxfix PRs related to the core functionality and confirm the fix.
Just recently set up a way hot to test that in a sandbox.

I've checked the current PR list, and it all new features.
The only bugfix is related to the blink integration.
Don't plan on getting involved with those at this point in time.

Also would like to clear up the docs a bit by defining steps for a quick eval.
But would like to know more on your flows before going that direction.

@sotte
You mention wanting to submit a bug fix.
If you do it I'll take a look.
For now I can only see you adding feat PR

[neo451]

Hi, there, thank you for your ideas, I had to deal with some school stuff and a broken laptop the past few weeks so unfortunately things are piling up. I would start to look at issues and PRs!

[sotte]

Thanks for getting back to me.

@TheMeaningfulEngineer, the fix still has some rough edges that I have to iron out.

The other PR was already merged, thanks to @neo451.

[sotte]

After adding another little fix, I think having the above information and contribution guidelines in a CONTRIBUTING.md file would be quite helpful.

[sotte]

See https://github.com/obsidian-nvim/obsidian.nvim/blob/main/CONTRIBUTING.md

[neo451]

I mention this here some that maybe more people will see, I did a little prototype of running a builtin LSP here
#52
I explain the advantage and motives in the PR.

[neo451]

made the reddit post 🎊 https://www.reddit.com/r/neovim/comments/1k0etww/announcement_community_fork_of_obsidiannvim/

[ffricken]

Thank you! Really excited for more folks coming in. Maybe someone's able to crosspost it to the obsidian subreddit as well?

[neo451]

thank you for reminding me, just did it, https://www.reddit.com/r/ObsidianMD/comments/1k0iwbf/announcement_community_fork_of_obsidiannvim/

[gjermundgaraba]

Very happy to see this project get some attention and love!

I think the current plan sounds very good.

I'll add a couple of thoughts as someone who is considering trying to get involved (and as a user):

• Minor: Clearly pointing to where conversations about the project will be taking place (in Discussions (i.e. here)?)
• I would love to see the project get a core contributors group that doesn't depend on a single person so we can avoid further forks in the future :)
• Perhaps after a core group has somewhat stablized, a more in-dept vision, long-term plans and roadmap could be published somewhere.
• As this plugin is quite opinionated (especially when it comes to the default config having zettlekasten-style note creation), I wonder if it might be useful for further expansion to consider some things around onboarding UX:
  1. Clearly state in the README the default config sets things up like this (might make onboarding a little less surprising for those not familiar)
  2. Document (and possibly create some presets) how to set up for different styles
  3. Long-term I personally think it would be better for the default config to behave as similar as possible to the default Obsidian behaviour - although this would likely be a breaking change, so would have to be handled carefully. This is also possible to circumvent to a large extent by having the documented install snippet use a preset or something that sets it to a specific "style".

[sotte]

I totally agree with all the points.

[neo451]

@gjermundgaraba thank you for your input!

On that note @sotte should I also add you as maintainer? since you are spending a lot of time on this project

[sotte]

Oh, I missed this. Not a good sign 🙈
I work on things sporadically (and mostly on the weekend), but I'm happy to review and merge smaller things. So if it helps you @neo451 I'm in.

[TheMeaningfulEngineer]

Shall we close this one?
We have a conclusion and the new project seems to be running nice.
Keeping the discussions tidy (closing stale talks) leaves a good impression to newcomers :)

[neo451]

great point :)