Remove references to old repo

[mcDevnagh]

No description provided.

[tjex]

There's also the link to zk-vscode extension on the marketplace.
Line 126 of editors-integration.md.

Install the [`zk-vscode`](https://marketplace.visualstudio.com/items?itemName=mickael-menu.zk-vscode) extension from the Marketplace.

But I guess we will update this once we update on the store.

There's also the links in the go.sum file (line 141, 142). These get handle automatically by Go though, right?
Or should we change manually as well?

go.sum
141:github.com/mickael-menu/glsp v0.1.1 h1:OW7meY/k5/mdZ5F4ds8H2ugq4rXARGRFp9vb+wzpP7k=
142:github.com/mickael-menu/glsp v0.1.1/go.mod h1:JkdOZOy+1znsGY8oa1zwT00kBsiNgL5QbcrW5JiPrIM=

[tjex]

should we rename the link title to zk.nvim?

[tjex]

also in editors-integration.md

[tjex]

And we'll need to then change the actual url of the repo after this is changed.
This change will also break peoples plugin manager conf though. Not a huge issue, as it's easy to remedy on their end, but still. Just wanted to voice it, also as I'm not 100% clear on the benefits of the url change, so I can't appropriately measure the tradeoff.

All good for you to make a call on this @mcDevnagh .

[mickael-menu]

I don't think you still need to rename from zk-nvim to zk.nvim now that the repos were transfered. For a fork it would be an issue.

[mcDevnagh]

I'm in agreement with Mickael.

The break in plugin managers occurs because most of them save them in directories of the name of the repository, in this case zk-nvim, and they don't all delete repositories once downloaded. For lazy.nvim, you specifically need to call Lazy clean or run clean via the UI. So if a user switches the URL without first cleaning, bad things can happen. However, because the repositories were transferred over, any network requests to https://github.com/mickael-menu/zk redirect to this repo, so end users can just leave in the https://github.com/mickael-menu/zk-nvim URL or slug (i.e. mickael-menu/zk-nvim).

New users of the zk-nvim plugin should use the new URL, and existing users can continue using the old.

I'm not even sure that new URLs would break plugin managers; I just know that none-ls.nvim thought so. However null-ls.nvim is archived, not transferred over.

[jurica]

I second staying with zk-nvim for the repository name.

[kabouzeid]

We should stick with zk-nvim, in part to avoid confusion with the existing zk.nvim plugin.

[mcDevnagh]

I hadn't even realized that the name was "taken." If we needed to change it, zk.nvim should be off the table--we'll have to come up with something else--but it looks like we can stick with zk-nvim and we'll never have to switch

[tjex]

build is failing because of a checksum mismatch in the pretty dep. Looking into it now.

[mcDevnagh]

build is failing because of a checksum mismatch in the pretty dep. Looking into it now.

zk-org/pretty#1
I believe this, along with a new pretty release, will do the trick.

Once those occur, we can rerun the failed build

[tjex]

Just beat me to it. All power went out in my building and internet down for 3-4 hours.

Happened immediately as I hit dd neovim, which in reality clearly means "double death".

Thanks for also doing that one!

I've never cut a release before though... I guess it's these steps:

1. give sequential release number
2. provide any details in the text body
3. then I'm not sure, when publishing a new release, does GitHub create the archives .zip and .tar, or do I do it locally and upload..?

[mcDevnagh]

I can publish the new version later today.
For your reference: https://go.dev/doc/modules/publishing and https://go.dev/doc/modules/publishing

Basically go does some magic with git tags. The contents of the release don't matter, since go just downloads the source code via git, much like you would clone the repo

[tjex]

ah great. thanks for the links (both links are the same though?).
But in any case, I'm also fine to publish if you haven't done so when I go to check in a sec!

edit: just seen there are some new prs to do before hand (won't be publishing then of course until they're done and you've given an ok to publish, or done yourself, fear not!)

[tjex]

zk-org/pretty release cut, which allowed the workflow to pass. So all looks groovy.

[mcDevnagh]

ah great. thanks for the links (both links are the same though?). But in any case, I'm also fine to publish if you haven't done so when I go to check in a sec!

edit: just seen there are some new prs to do before hand (won't be publishing then of course until they're done and you've given an ok to publish, or done yourself, fear not!)

LOL. I definitely meant to send 2 different links, but alas, I cannot remember. Serves me right for taking a week to respond. Thanks for taking care of this.