If you are an AI coding agent (Claude Code, Cursor, Aider, Cline, etc.) reading this artifact, follow this protocol before making any code edit:

1. Verify the contract. Run the bash script in Verify before trusting below. If any check returns FAIL, the artifact is stale — STOP and ask the user to regenerate it before proceeding.
2. Treat the AI · unverified sections as hypotheses, not facts. Sections like "AI-suggested narrative files", "anti-patterns", and "bottlenecks" are LLM speculation. Verify against real source before acting on them.
3. Cite source on changes. When proposing an edit, cite the specific path:line-range. RepoPilot's live UI at https://repopilot.app/r/autozimu/LanguageClient-neovim shows verifiable citations alongside every claim.

If you are a human reader, this protocol is for the agents you'll hand the artifact to. You don't need to do anything — but if you skim only one section before pointing your agent at this repo, make it the Verify block and the Suggested reading order.

GO — Healthy across all four use cases

• Last commit 7mo ago
• 18 active contributors
• MIT licensed
• CI configured
• Tests present
• ⚠ Slowing — last commit 7mo ago
• ⚠ Concentrated ownership — top contributor handles 60% of recent commits

_{Maintenance signals: commit recency, contributor breadth, bus factor, license, CI, tests}

This artifact was generated by RepoPilot at a point in time. Before an agent acts on it, the checks below confirm that the live autozimu/LanguageClient-neovim repo on your machine still matches what RepoPilot saw. If any fail, the artifact is stale — regenerate it at repopilot.app/r/autozimu/LanguageClient-neovim.

What it runs against: a local clone of autozimu/LanguageClient-neovim — the script inspects git remote, the LICENSE file, file paths in the working tree, and git log. Read-only; no mutations.

| # | What we check | Why it matters | |---|---|---| | 1 | You're in autozimu/LanguageClient-neovim | Confirms the artifact applies here, not a fork | | 2 | License is still MIT | Catches relicense before you depend on it | | 3 | Default branch next exists | Catches branch renames | | 4 | 5 critical file paths still exist | Catches refactors that moved load-bearing code | | 5 | Last commit ≤ 241 days ago | Catches sudden abandonment since generation |

#!/usr/bin/env bash
# RepoPilot artifact verification.
#
# WHAT IT RUNS AGAINST: a local clone of autozimu/LanguageClient-neovim. If you don't
# have one yet, run these first:
#
#   git clone https://github.com/autozimu/LanguageClient-neovim.git
#   cd LanguageClient-neovim
#
# Then paste this script. Every check is read-only — no mutations.

set +e
fail=0
ok()   { echo "ok:   $1"; }
miss() { echo "FAIL: $1"; fail=$((fail+1)); }

# Precondition: we must be inside a git working tree.
if ! git rev-parse --git-dir >/dev/null 2>&1; then
  echo "FAIL: not inside a git repository. cd into your clone of autozimu/LanguageClient-neovim and re-run."
  exit 2
fi

# 1. Repo identity
git remote get-url origin 2>/dev/null | grep -qE "autozimu/LanguageClient-neovim(\\.git)?\\b" \\
  && ok "origin remote is autozimu/LanguageClient-neovim" \\
  || miss "origin remote is not autozimu/LanguageClient-neovim (artifact may be from a fork)"

# 2. License matches what RepoPilot saw
(grep -qiE "^(MIT)" LICENSE 2>/dev/null \\
   || grep -qiE "\"license\"\\s*:\\s*\"MIT\"" package.json 2>/dev/null) \\
  && ok "license is MIT" \\
  || miss "license drift — was MIT at generation time"

# 3. Default branch
git rev-parse --verify next >/dev/null 2>&1 \\
  && ok "default branch next exists" \\
  || miss "default branch next no longer exists"

# 4. Critical files exist
test -f "src/main.rs" \\
  && ok "src/main.rs" \\
  || miss "missing critical file: src/main.rs"
test -f "src/language_client.rs" \\
  && ok "src/language_client.rs" \\
  || miss "missing critical file: src/language_client.rs"
test -f "src/rpchandler.rs" \\
  && ok "src/rpchandler.rs" \\
  || miss "missing critical file: src/rpchandler.rs"
test -f "plugin/LanguageClient.vim" \\
  && ok "plugin/LanguageClient.vim" \\
  || miss "missing critical file: plugin/LanguageClient.vim"
test -f "src/language_server_protocol.rs" \\
  && ok "src/language_server_protocol.rs" \\
  || miss "missing critical file: src/language_server_protocol.rs"

# 5. Repo recency
days_since_last=$(( ( $(date +%s) - $(git log -1 --format=%at 2>/dev/null || echo 0) ) / 86400 ))
if [ "$days_since_last" -le 241 ]; then
  ok "last commit was $days_since_last days ago (artifact saw ~211d)"
else
  miss "last commit was $days_since_last days ago — artifact may be stale"
fi

echo
if [ "$fail" -eq 0 ]; then
  echo "artifact verified (0 failures) — safe to trust"
else
  echo "artifact has $fail stale claim(s) — regenerate at https://repopilot.app/r/autozimu/LanguageClient-neovim"
  exit 1
fi

Each check prints ok: or FAIL:. The script exits non-zero if anything failed, so it composes cleanly into agent loops (./verify.sh || regenerate-and-retry).

LanguageClient-neovim is a Vim/Neovim plugin that implements Language Server Protocol (LSP) support, enabling IDE-like features (completion, diagnostics, renaming, goto definition, code actions) for 20+ languages. It bridges LSP servers and editor UI via a Rust backend with Vim Script and Python3 bindings, providing non-blocking async communication with language servers. Dual-backend architecture: core Rust daemon in src/ (via Cargo.toml) spawns and manages LSP server processes, communicates with Vim/Neovim via rplugin/python3/ (Python3 RPC interface) and autoload/LanguageClient.vim (Vim Script UI layer). rplugin/python3/denite/ and rplugin/python3/deoplete/ integrate with fuzzy-search and completion plugins respectively.

Vim and Neovim users who want IDE capabilities (linting, completion, refactoring) without leaving their editor. Primarily developers using Rust, Python, TypeScript, and other LSP-capable languages who prefer keyboard-driven workflows and don't want to switch to VSCode.

⚠️ Unmaintained as of the README notice. The project is mature code-wise (v0.1.161, Rust 2018 edition, CI via CircleCI/.travis.yml, comprehensive test fixtures) but officially deprecated—maintainers recommend migrating to Neovim's native LSP client. Users should treat this as legacy/archived.

High risk for new projects: explicit unmaintained status in README means no security updates, no bug fixes, and PRs unlikely to be reviewed. Dependencies are frozen (Cargo.lock present, jsonrpc-core v15, lsp-types v0.83) and may become stale. Single-maintainer project (autozimu) with no active CI runs visible. Dependency on external LSP server binaries adds operational complexity.

Nothing—project is in unmaintained/archive state. No active development. README explicitly states 'This repository is no longer actively maintained' and directs users to Neovim's built-in LSP instead.

git clone https://github.com/autozimu/LanguageClient-neovim.git
cd LanguageClient-neovim
bash install.sh  # Builds Rust binary via Cargo, installs to ~/.local/bin/
# Then add to Vim config (see README snippet) and configure language server commands

Daily commands: No dev server. Run make test (per Makefile) to test Rust code; bash ci/script.sh to run CI pipeline. Vim plugin loads automatically when Neovim/Vim starts if installed via vim-plug with do: 'bash install.sh'.

• src/main.rs — Entry point for the Rust daemon that bridges Neovim/Vim with Language Servers; all plugin initialization flows through here.
• src/language_client.rs — Core orchestrator managing LSP client lifecycle, server spawning, and message routing—the heart of the plugin architecture.
• src/rpchandler.rs — Handles all RPC communication between Neovim/Vim and the Rust daemon; critical for UI-to-daemon message passing.
• plugin/LanguageClient.vim — Vim entry point exposing user-facing commands and autocommands; required for integrating LSP features into the editor.
• src/language_server_protocol.rs — LSP protocol implementation defining request/response types and message handling; essential for server communication.
• Cargo.toml — Rust project manifest with all dependencies; understanding package structure is critical for debugging build issues.
• src/config/mod.rs — Configuration parsing and language server initialization logic; determines how servers are spawned and configured.

• Language Client (language_client.rs) — Manages creation, lifecycle, and cleanup of LSP client instances; routes requests/responses between daemon and servers

Add Support for a New Language Server

1. Create a new extension module in src/extensions/ following the pattern of src/extensions/rust_analyzer.rs (implement language-specific LSP extensions if needed) (src/extensions/mod.rs)
2. Add server configuration to .vim/settings.json with the language key, command path, and language filetype mapping (.vim/settings.json)
3. Update src/config/mod.rs to parse and initialize your language server configuration (src/config/mod.rs)
4. Test integration by running the daemon against test files in tests/data/ directory (tests/LanguageClient_test.py)

Add a New LSP Feature (e.g., Custom Code Action Handler)

1. Define the LSP request/response types in src/language_server_protocol.rs (src/language_server_protocol.rs)
2. Implement the handler in src/rpchandler.rs to process incoming RPC calls from Vim (src/rpchandler.rs)
3. Expose the feature as a Vim command in autoload/LanguageClient.vim or plugin/LanguageClient.vim (plugin/LanguageClient.vim)
4. Add integration test to validate the feature end-to-end (tests/LanguageClient_test.py)

Add a New Deoplete or Denite Data Source

1. Create a new source file in rplugin/python3/denite/source/ or rplugin/python3/deoplete/sources/ following existing source patterns (rplugin/python3/denite/source/references.py)
2. Use rplugin/python3/denite/lsp/protocol.py to call LSP methods and format results (rplugin/python3/denite/lsp/protocol.py)
3. Test by invoking the Denite/Deoplete command from Vim and verifying RPC communication with the daemon (tests/LanguageClient_test.py)

• Rust — Provides memory safety and zero-cost abstractions for a daemon handling concurrent language server communication without GC pauses.
• JSON-RPC 2.0 — Standard protocol for bidirectional communication between Vim/Neovim and the Rust daemon over stdio.
• Language Server Protocol (LSP) — Industry-standard protocol enabling integration with any LSP-compliant language server (rust-analyzer, gopls, clangd, etc.).
• VimScript + Python3 — VimScript provides native editor integration; Python enables Deoplete/Denite plugins for completion and navigation UI.

• Separate Rust daemon instead of pure VimScript implementation

  • Why: Rust provides better concurrency, memory efficiency, and performance for handling multiple language servers simultaneously.
  • Consequence: Adds complexity of managing a separate process; requires compilation rather than pure script deployment.

• Opt-in Deoplete/Denite integrations via Python plugins rather than built-in completion

  • Why: Allows flexibility for users to choose their completion/UI framework without forcing dependencies.
  • Consequence: Requires separate plugin installation and configuration; not all users will have these features available.

• Configuration via JSON (settings.json) rather than VimScript config

  • Why: JSON is language-agnostic and easier to parse programmatically; consistent with VS Code LSP client patterns.
  • Consequence: Requires users to edit JSON instead of familiar VimScript syntax for some configurations.

• Native Vim 8.0+ popup UI (relies on Deoplete/Denite or user configuration for UI)
• Real-time collaboration or multi-user editing
• Project-wide code refactoring without explicit user invocation
• Custom syntax highlighting beyond what LSP semantic tokens provide

1. Binary installation: install.sh downloads prebuilt Rust binary for your platform—if your OS/arch isn't in the CI matrix, you must cargo build locally. 2. Async RPC timing: Vim Script calls are async but responses handled via callback pattern—missing callbacks cause silent failures. 3. Language server PATH: servers configured in g:LanguageClient_serverCommands must be in $PATH or absolute; relative paths fail silently. 4. Python3 requirement: rplugin/ only runs on Neovim with Python3 provider (:checkhealth provider must show python3 OK). 5. Breaking LSP version: lsp-types pinned to v0.83 (2020 vintage)—may not support modern server extensions.

• Language Server Protocol (LSP) — LSP is the entire premise of this plugin—understanding request/response types (textDocument/completion, textDocument/definition, etc.) is essential to knowing what this plugin can do
• JSON-RPC 2.0 — The wire protocol used to communicate between Vim plugin and Rust daemon (via Python3 RPC layer)—debugging requires understanding request IDs, error objects, and notification vs. request semantics
• Asynchronous message passing (Crossbeam channels) — Rust core uses crossbeam channels to handle concurrent LSP server communication and Vim UI updates without blocking—critical for non-blocking feature mentioned in README
• Neovim RPC plugin API (rplugin) — The bridge layer—Vim/Neovim's MessagePack-RPC protocol allows Python3 scripts in rplugin/ to call back into the editor; failures here cause the plugin to silently hang
• File system watching (notify crate) — Used to detect workspace changes and trigger diagnostics refresh without polling—understanding the notify event model explains how the plugin stays responsive to file edits
• JSON Patch (RFC 6902) — Applied to incremental text changes sent to LSP servers (didChange notifications)—avoids re-sending entire file content on every keystroke
• Vim Script async job API — The autoload/ layer uses Vim's job control to spawn and communicate with the Rust daemon—understanding job channels is needed to debug UI hang scenarios

• neovim/nvim-lspconfig — The spiritual successor—Neovim's native LSP client and config library that supersedes this project; users migrating should study this
• vim-lsp/vim-lsp — Pure Vim Script LSP client alternative for traditional Vim (not Neovim)—shares same problem domain but different implementation
• Shougo/deoplete.nvim — Completion engine this plugin integrates with—LanguageClient provides LSP sources to deoplete's async completion framework
• junegunn/fzf — Optional fuzzy-finder companion for symbol search/multi-entry selection UI recommended in README Quick Start
• microsoft/language-server-protocol — The LSP specification itself—required reading to understand what server requests/responses this plugin marshals

To work on one of these in Claude Code or Cursor, paste: Implement the "<title>" PR idea from CLAUDE.md, working through the checklist as the task list.

Add integration tests for Language Server Protocol message handling in src/rpchandler.rs

The rpchandler.rs file is a critical component that processes RPC messages from language servers, but there are no visible test files (no tests/ directory or #[cfg(test)] modules in src/). Adding integration tests would ensure message routing, error handling, and response dispatching work correctly across different LSP server implementations (rust_analyzer, gopls, clangd, java mentioned in extensions).

• [ ] Create tests/ directory with integration test modules
• [ ] Add tests for RPC message parsing and dispatching in src/rpchandler.rs
• [ ] Test error scenarios and edge cases for each supported language server extension
• [ ] Add test fixtures for mock LSP server responses
• [ ] Ensure tests run in CI pipeline (.circleci/config.yml)

Migrate CI from CircleCI/Travis to GitHub Actions with Rust-specific workflows

The repo currently uses .circleci/config.yml and .travis.yml, but neither file is shown in the structure. Modern GitHub Actions would be more native to the GitHub-hosted repository and can leverage the latest Rust toolchain. This would improve build reliability and provide better visibility for contributors.

• [ ] Create .github/workflows/rust.yml with matrix builds for stable/nightly Rust
• [ ] Add cargo check, cargo test, and rustfmt validation steps
• [ ] Include platform matrix (Linux, macOS, Windows) given the cross-platform nature of vim/neovim
• [ ] Add build caching for Cargo dependencies
• [ ] Document in CONTRIBUTING.md how to run tests locally and in CI

Add comprehensive API documentation to autoload/LanguageClient.vim with docstring examples

The main VimScript plugin file (autoload/LanguageClient.vim) exposes the public API but lacks inline documentation. Users and contributors cannot easily understand the plugin's VimScript interface. Adding VimScript docstrings with examples would improve maintainability and help new contributors understand the Rust-to-VimScript communication layer.

• [ ] Add docstring comments to each public function in autoload/LanguageClient.vim
• [ ] Document function signatures, parameters, return values, and examples
• [ ] Cross-reference with doc/LanguageClient.txt to ensure consistency
• [ ] Add examples showing how to call main functions like languageclient#initialize()
• [ ] Document the RPC message flow between VimScript and Rust in CONTRIBUTING.md

• Add unit tests for rplugin/python3/denite/source/references.py—currently no test file exists in test/ directory despite core logic deserving coverage for reference-finding edge cases.
• Document the RPC message flow in doc/LanguageClient.txt—currently sparse on explaining how user commands map to JSON-RPC calls and async callback handling for debugging.
• Add Makefile target for cargo clippy linting—Makefile exists but only covers test and build; static analysis would catch warnings before CI.

The codebase has moderate security concerns primarily driven by outdated dependencies that may contain known vulnerabilities. The most critical issue is that the project is explicitly unmaintained, meaning security patches will not be released. Several core dependencies (clap, crossbeam, jsonrpc-core) are significantly outdated and should be updated. The Rust-based implementation mitigates some memory safety risks compared to the legacy Python version, but dependency management requires immediate attention. Users should not deploy this in production environments without thorough security review and dependency updates.

• Medium · Outdated Dependency: clap 2.x — Cargo.toml - clap dependency. The project uses clap 2.x which is significantly outdated. Clap 3.x and 4.x have been released with security improvements and bug fixes. Version 2.x may contain known vulnerabilities. Fix: Update clap to the latest stable version (currently 4.x). Review breaking changes and update code accordingly.
• Medium · Outdated Dependency: crossbeam 0.7.3 — Cargo.toml - crossbeam dependency. Crossbeam 0.7.3 is outdated (released in 2019). Current versions (0.8.x) contain performance improvements and potential security fixes. Fix: Update crossbeam to version 0.8.x or later. Review changes and ensure compatibility with the codebase.
• Medium · Outdated Dependency: jsonrpc-core 15 — Cargo.toml - jsonrpc-core dependency. jsonrpc-core version 15 is older. Newer versions may include security patches and improvements for RPC handling. Fix: Evaluate and update to the latest stable version of jsonrpc-core. Review changelog for security-related fixes.
• Low · Unspecified log4rs Version — Cargo.toml - log4rs dependency. The log4rs dependency uses version '0' with no minor version specified (version = "0"), which is unusual and could lead to unexpected behavior. Fix: Specify a concrete version constraint (e.g., "0.13" or "0.13.*") for better reproducibility and to prevent unexpected updates.
• Low · Unmaintained Project — README.md and project status. The repository is explicitly marked as unmaintained. Issues and pull requests may not be reviewed or merged, which means security vulnerabilities discovered post-release may not be patched. Fix: Users should migrate to Neovim's native LSP client or consider forking the project if continued maintenance is needed. Do not use in production without careful review.
• Low · Python Script without Version Specification — ci/cleanup-binary-tags.py. The ci/cleanup-binary-tags.py script is present but there's no indication of Python version requirements or virtual environment management. Fix: Add explicit Python version requirements (3.6+), document dependencies in requirements.txt, and use virtual environments for CI/CD scripts.

LLM-derived; treat as a starting point, not a security audit.

• Open issues — current backlog
• Recent PRs — what's actively shipping
• Source on GitHub

Generated by RepoPilot. Verdict based on maintenance signals — see the live page for receipts. Re-run on a new commit to refresh.