fix(lsp): followup fixes for semantic tokens support (#21357)

1. The algorithm for applying edits was slightly incorrect. It needs to
   preserve the original token list as the edits are applied instead of
   mutating it as it iterates. From the spec:

   Semantic token edits behave conceptually like text edits on
   documents: if an edit description consists of n edits all n edits are
   based on the same state Sm of the number array. They will move the
   number array from state Sm to Sm+1.

2. Schedule the semantic token engine start() call in the
   client._on_attach() function so that users who schedule_wrap() their
   config.on_attach() functions (like nvim-lspconfig does) can still
   disable semantic tokens by deleting the semanticTokensProvider from
   their server capabilities.

1 files changed, 8 insertions, 3 deletions

diff --git a/runtime/lua/vim/lsp.lua b/runtime/lua/vim/lsp.lua
index 3d3c856fcb..f3ee484024 100644
--- a/runtime/lua/vim/lsp.lua
+++ b/runtime/lua/vim/lsp.lua
@@ -1531,9 +1531,14 @@ function lsp.start_client(config)
       pcall(config.on_attach, client, bufnr)
     end
 
-    if vim.tbl_get(client.server_capabilities, 'semanticTokensProvider', 'full') then
-      semantic_tokens.start(bufnr, client.id)
-    end
+    -- schedule the initialization of semantic tokens to give the above
+    -- on_attach and LspAttach callbacks the ability to schedule wrap the
+    -- opt-out (deleting the semanticTokensProvider from capabilities)
+    vim.schedule(function()
+      if vim.tbl_get(client.server_capabilities, 'semanticTokensProvider', 'full') then
+        semantic_tokens.start(bufnr, client.id)
+      end
+    end)
 
     client.attached_buffers[bufnr] = true
   end