Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

Provide generic position-aware text primitives (word-at-position, whole-word occurrences) + a hover MarkupContent builder

Open
  • Is something wrong?
#2 0 comments 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

Nobody has claimed this yet.

Assessment

Difficulty
4/5
Estimated time
3-5 days
Newbie friendliness
48/100
Issue type
Feature
Clarity
Clearly specified
Activity status
Quiet
Tech stack
rust
Domain
backend-api-design, developer-experience

Research direction

Read the existing osprey-lsp crates/osprey-lsp/src/text.rs and wire::hover_result implementations, then compare them with lspkit-vfs position conversion and lspkit-server hover handling. Add reusable position-aware text helpers and the optional Markdown hover response builder in the appropriate crates; done means the requested behavior is covered and osprey-lsp can migrate to those shared helpers.

Written by the indexing model from the issue text.

Description

Context

Building hover/definition/references for the Osprey language server (osprey-lsp, built on lspkit/lspkit-server/lspkit-vfs/lspkit-live), we found that lspkit provides the engine contract, JSON-RPC dispatch, capability registration (including the Hover capability), and lspkit-vfs encoding/position conversion — but not the small set of generic, language-agnostic text/position primitives that every LSP backend needs. As a result osprey-lsp hand-rolls them in its own crates/osprey-lsp/src/text.rs.

These are not language-specific: they operate purely on text + PositionEncoding, so they belong in lspkit-vfs (or a lspkit-text module) rather than being reinvented per server.

Requested primitives

  1. Word / identifier span at a position — given a line (or rope + position) and a PositionEncoding, return the identifier under the cursor and its (start, end) character offsets in the negotiated encoding. Today this is text::word_at in osprey-lsp. This is the core lookup behind hover, go-to-definition, signature help, and rename.

  2. Whole-word occurrence scan — given document text + a name + encoding, return every whole-word occurrence with line/char spans. Today this is text::occurrences, used for find-references and definition anchoring.

  3. Encoding-aware column measurement — char_width(c, encoding) / measure(str, encoding) / prefix_to(line, character, encoding). lspkit-vfs already has position_to_byte internally; exposing these would let servers stop duplicating the UTF-8/UTF-16 width logic.

  4. (Minor) Hover MarkupContent builder — lspkit-server knows the Hover capability but offers no helper to build the { contents: { kind: \"markdown\", value } } response. A tiny hover_markdown(Option<String>) -> Value (null when None) would remove hand-rolled JSON in each server's wire layer.

Why this matters

The "one engine, two surfaces" value of lspkit is undercut if each backend still re-implements identifier extraction and occurrence scanning — exactly the bits most prone to off-by-one and encoding bugs. Centralizing them in lspkit-vfs would make these correct once.

Current workaround

osprey-lsp carries its own text.rs (word_at, occurrences, char_width, measure, prefix_to) and a wire::hover_result JSON builder. We'd happily migrate to lspkit equivalents once available.

Filed while implementing variable hover (type + doc comments) in osprey-lsp; the hover content is necessarily language-specific (Osprey type inference + doc-comment grammar), but the position/text plumbing above is not.

Dominant language
Rust
Stars
0
Forks
0
Avg merge
1h 46m
Merged PRs (30d)
13

Getting set up

Open in Codespaces

Starts the project's dev container in your browser, under your own GitHub account.

  • No Dockerfile or Docker Compose file
  • Has a pull request template
  • No contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from Nimblesite/lspkit

All issues in Nimblesite/lspkit

Similar issues

More Rust issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.