Hacktoberfest 2026: những issue maintainer đã đánh dấu cho tháng Mười, đang mở và phù hợp người mới. Xem issue Hacktoberfest

Separate language support from vscode-R again

Đang mở
#1,749 6 bình luận 3 reaction 0 người được giao Xem trên GitHub

Maintainer thường phản hồi trong vòng 1 ngày

Chưa có ai nhận issue này.

Đánh giá

Độ khó
5/5
Thời gian dự kiến
Hơn một tuần
Mức phù hợp với người mới
35/100
Loại issue
Tính năng
Độ rõ ràng
Khá rõ ràng
Mức độ hoạt động
Sôi nổi
Công nghệ
r, typescript, vscode

Hướng nghiên cứu

The issue names no implementation files or tests. Start by reviewing the existing language-server integration and related issues #1540 and #1648, then compare the proposed minimal extraction with the extension-pack structure. Done would be an agreed extraction approach with minimal behavior changes; the larger runtime split is explicitly separate.

Do mô hình lập chỉ mục viết ra từ nội dung của issue.

Mô tả

I would like to reconsider separating the language-server integration from vscode-R, similar to the old vscode-r-lsp, and eventually make REditorSupport.r an extension pack / umbrella extension.

When vscode-r-lsp was merged into vscode-R in 2.1.0 (#695), languageserver was effectively the standard choice for R language intelligence.
That is no longer the case.

The R editor ecosystem now has several actively developed, independently distributed tools with VS Code extensions:

  • Air provides a very fast Rust-based formatter and language server.
  • Jarl provides a fast Rust-based linter with diagnostics and automatic fixes.
  • Arity provides a full Rust-based language server with completion, hover, go-to-definition/references, rename, diagnostics, semantic tokens, and more.
  • Posit's Oak may become another standalone R language server in the future.

In particular, these newer tools are designed around fast static analysis.

Given this ecosystem, it no longer seems ideal for vscode-R itself to own one particular LSP client/runtime combination.
VS Code ecosystems such as Python and Java also separate language support and other tooling into independently maintained extensions, often combined through an extension pack.

A possible long-term structure would be:

REditorSupport.r          # extension pack / main entry point
├─ REditorSupport.r-syntax
├─ REditorSupport.r-runtime
└─ REditorSupport.r-lsp   # current languageserver-based integration

r-lsp could remain the default language support installed by the pack, while users could disable or replace it with Air, Jarl, Arity, or future alternatives without fighting functionality bundled into the main extension.

The first step could simply be extracting the existing LSP client with minimal behavior changes.
A larger runtime split can be discussed separately.


Related to #1540, #1648

Ngôn ngữ chính
TypeScript
Star
1.2k
Fork
139
Merge trung bình
20 giờ 32 phút
Pull request đã merge (30 ngày)
25

Chuẩn bị môi trường

Bắt đầu từ đâu

  1. Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
  2. Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
  3. Fork repository và làm thay đổi trên một nhánh.
  4. Mở pull request có tham chiếu số hiệu của issue.

Issue khác của REditorSupport/vscode-R

Tất cả issue của REditorSupport/vscode-R

Issue tương tự

Thêm issue về TypeScript

Nhận issue mới trong hộp thư của bạn

Bản tóm tắt ngắn những issue GitHub phù hợp với người mới.