Migrate keymap and settings + edit predictions rename

[0xtimsb]

• snake case keymap properties
• flatten actions
• keymap migration + notfication
• inline completions -> edit predictions
• settings migration + notification

bugs

• json edit function doesn't preserve comments if array
• json edit function doesn't remove key-value if removed from new json, instead replaces value with null

future:

• keymap notification doesn't show up on start up, only on keymap save. this is existing bug in zed, will be addressed in seperate PR.

Release Notes:

• Added a notification for deprecated settings and keymaps, allowing you to migrate them with a single click. A backup of your existing keymap and settings will be created in your home directory.
• Modified some keymap actions and settings for consistency.

[SomeoneToIgnore]

That is a rabbit hole I had lured you in, sorry for such a large scope.

Looking at this PR growing, I think we need to consider one thing (not needed to be done now, but might be needed before the PR is merged): a keymap migration tool.

We do not collect users' keymaps in any form, so it's not clear how many people will suffer from this — presumably, some amount of Vim users?
But we have an error detection, and can think of one-off keymap.json update (and backing up the previous version) for such case.

This are all ideas though, at this stage, thank you for providing more food for thought.

[0xtimsb]

I think the work for this PR is done. I'll open another PR to show a button in the keymap error dialog, but only if we detect it's a casing error.

The button could say something like "Backup and Migrate Keymap" to make it clear what happened. I think the script for this should be fairly simple - at least, that’s what it seems like for now.

[mikayla-maki]

Could we just automatically and silently migrate keymaps, while backing them up? If it's a simple find-and-replace job, it doesn't seem like something we have to bother users with.

[SomeoneToIgnore]

2 small concerns against that:

• there could be errors in current keymaps (no migration is possible then)
• people may use different Zed versions (e.g. developers, bisecting or checking both Preview, Stable and Dev simultaneously)

IMO, it's worth to indicate that migration had happened and show where the backup file is placed.

[SomeoneToIgnore]

A bit sad that we have to do this — seems that many our code has such conversions already, but I personally see no harm in having the existing, single words in whatever case they are: this way, it will be less breakage to the keymap.

Not insisting though, as it seems not very uniform and we're breaking things anyway.

[0xtimsb]

I've thought about this a lot, and initially, I preferred not to break too many things. However, if we keep single words in camelCase, it will affect other enums that might have data like Object in below case:

"i": ["vim::PushOperator", { "Object": { "around": false } }],

So, again inconsistency with keys. Hence, I made this difficult decision.

[mikayla-maki]

there could be errors in current keymaps (no migration is possible then)

I don't think this is blocking, as find and replace doesn't care about errors.

people may use different Zed versions
IMO, it's worth to indicate that migration had happened and show where the backup file is placed.

I agree on both counts, and as a general rule asking before doing things is polite.

[0xtimsb]

Let me figure if simple find and replace will suffice. I strongly think it might be, just checking if there are no edge case doing so.

[ConradIrwin]

If we're going to break these...

For things where there are a small number of options like workspace::ActivatePaneInDirection, I think we should make it workspace::ActivatePaneLeft etc.

I added these actions before I knew that actions with arguments didn't show up in the command palette; and think it'd be better to not use that pattern going forward. Sorry!

Probably similar for the ResizePane ones.

For vim::PushOpeator etc. I could go either way - there's a lot of boilerplate already to create a new operator, and it wouldn't be the end of the world to flatten these out.

[0xtimsb]

@ConradIrwin

Apart from flattening you suggested, I also end up doing same for PushOperator:

      "y": ["vim::PushOperator", "yank"], // from
      "y": "vim::PushYank", // to

and

      "f": ["vim::PushOperator", { "find_forward": { "before": false } }], // from
      "f": ["vim::PushFindForward", { "before": false }], // to

I also wonder, now that we are doing that, we should also:

      "escape": ["vim::SwitchMode", "normal"], // from
      "escape": "vim::SwitchToNormalMode", // to

to follow similar convention. What do you think?

[0xtimsb]

I changed it. Felt sensible.

[maxdeviant]

@0xtimsb Could you add release notes to the PR description?

[0xtimsb]

Added release notes and moved it to seperate crate.