The README makes claims. this file backs them up with evidence from real code.
From README (lines 13-15):
🚀 Universal Editor Support - One server powers plugins for VS Code, Neovim, Emacs, JetBrains, Sublime, Zed, and Helix
Evidence: /var/mnt/eclipse/repos/universal-language-server-plugin/clients/vscode/extension.ts (~70 LOC) initializes LSP client, no business logic. /var/mnt/eclipse/repos/universal-language-server-plugin/clients/neovim/init.lua (~65 LOC) configures Neovim LSP. Similar pattern in /var/mnt/eclipse/repos/universal-language-server-plugin/clients/emacs/universal-connector.el (~75 LOC), JetBrains, Sublime, Zed, Helix clients all under 100 LOC.
Caveat: <100 LOC constraint proves architecture works (thin clients delegate all logic). Does NOT prove clients are complete—they’re minimal proof-of-concept implementations. Production clients may need more setup code (error handling, configuration UI).
From README (lines 17-18):
⚡ High Performance - Sub-100ms responses, <50MB memory, <500ms startup
Evidence: /var/mnt/eclipse/repos/universal-language-server-plugin/server/src/main.rs uses tokio async runtime for sub-100ms latency. Document storage via dashmap (lock-free concurrent HashMap) keeps memory bounded. Benchmarks at /var/mnt/eclipse/repos/universal-language-server-plugin/server/benches/ measure Markdown→HTML conversion (2.5ms), HTML→Markdown (8.3ms), LSP completion (1.2ms).
Caveat: Benchmarks are microbenchmarks on synthetic data. Real-world performance depends on document size, network latency, client behavior. No production load testing yet.
From README (lines 171-181):
| From | To | Quality | Notes |----------|----------|---------| | Markdown | HTML | ✅ High | Full support via pulldown-cmark | Markdown | JSON | ✅ High | Structured representation | HTML | Markdown |
⚠️ Good | Some formatting may be lost | HTML | JSON | ✅ High | DOM structure extraction | JSON | Markdown | ✅ High | Key-value representation | JSON | HTML | ✅ High | Via Markdown intermediary
Evidence: /var/mnt/eclipse/repos/universal-language-server-plugin/server/src/core.rs implements converters using pulldown-cmark (Markdown→HTML), scraper (HTML parsing), serde_json (JSON). Round-trip tests at /var/mnt/eclipse/repos/universal-language-server-plugin/server/tests/core_tests.rs validate Markdown→HTML→Markdown preservation.
Caveat: Conversion is syntactic (format structure), not semantic (meaning preservation). Complex HTML (frames, scripts, dynamic content) loses information when converted to Markdown. "High quality" means format-valid output, not lossless semantics.
Uses hyperpolymath LSP + universal plugin pattern. Same pattern across: - format-registrations — Document format plugin registry - protocol-squisher — Protocol conversion via LSP - rescript-openapi — OpenAPI LSP integration
All share: LSP server (Rust/language-agnostic), thin clients (all editors), zero editor-specific business logic.
| Path | Contents & Purpose |
|---|---|
|
Rust server entry: tokio event loop, LSP handler init, HTTP/WebSocket server startup |
|
LSP 3.17 implementation using tower-lsp: document sync, completion, hover, diagnostics, execute_command handlers |
|
HTTP REST API (axum): /api/convert, /api/documents, /api/stats endpoints |
|
WebSocket real-time updates: server push on document changes, timestamped events |
|
Conversion engine core: Markdown→HTML (pulldown-cmark), HTML→Markdown, JSON↔*. Format detection, error handling. |
|
Concurrent document storage (dashmap): lock-free HashMap, TTL tracking, event emission |
|
LSP 3.17 compliance tests: document sync, capability negotiation, method invocation |
|
Conversion correctness tests: round-trip validation, format preservation, error cases |
|
HTTP API contract tests: endpoint correctness, response format, status codes |
|
VS Code extension (~70 LOC): LanguageClient setup, stdio transport, document selector registration |
|
Neovim config (~65 LOC): LSP client initialization, command registration |
|
Emacs package (~75 LOC): lsp-mode integration, hook setup |
|
JetBrains plugin (~55 LOC): IntelliJ SDK integration, LSP client binding |
|
Sublime plugin (~60 LOC): LSP client, command dispatch |
|
Zed native LSP config: language association, server invocation |
|
Helix native LSP config: language definition, server setup |
|
Web UI: single-page HTML app with JS for WebSocket/Fetch API integration |
|
Client-side JS: document manager, live converter UI, real-time WebSocket updates |
|
Container image: Rust server + web UI, multi-stage build |
|
Compose orchestration: server + optional postgres for persistence |
|
Complete REST API reference: endpoints, request/response schemas, examples |
|
LSP 3.17 compliance notes: supported methods, capability negotiation, limitations |
|
Architecture deep-dive: why LSP works for universality, thin client pattern, codegen strategy |
|
Build targets: build, release, test, docker-build, install, clean |
Honest Assessment: Production-ready server + proof-of-concept clients. Rust server is complete and tested. Editor clients are minimal (intentionally <100 LOC to prove architecture). Web UI is functional but basic.
What Works: - Rust server: LSP, HTTP, WebSocket (all tested) - Conversion core: Markdown ↔ HTML ↔ JSON (tested) - All 7 editor clients (working, not feature-complete) - Web UI (functional, no fancy features)
What’s Incomplete: - Advanced conversion formats (YAML, XML, TOML) - Plugin system for custom converters - Official LSP compliance testing (vs. Microsoft’s suite) - Performance optimization for very large documents
Open an issue or reach out at j.d.a.jewell@open.ac.uk — happy to explain the LSP architecture, conversion strategy, or universal plugin model.