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

[Feature Proposal] Toggleable File Explorer & Opt-In AI Assistant (via C ABI Plugin)

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

Maintainers usually reply within 1 day

Nobody has claimed this yet.

Assessment

Difficulty
5/5
Estimated time
Over a week
Newbie friendliness
25/100
Issue type
Feature
Clarity
Needs clarification
Activity status
Quiet
Tech stack
c, cpp, rust
Domain
cli, tooling

Research direction

Read CONTRIBUTING.md for the stated lightweight and plugin goals, then inspect src/tui.rs, src/framebuffer.rs, and src/buffer. This issue is a proposal for two broad features rather than a defined implementation task; done would first require maintainer feedback on scope, architecture, and whether the work should be split.

Written by the indexing model from the issue text.

Description

Hello maintainers,

I have been exploring the edit repository and really appreciate the homage to the classic MS-DOS editor combined with the strict lightweight philosophy. I would love to contribute to the project by introducing two modern workflow features that respect the editor's minimal footprint: a toggleable file explorer and an AI assistant.

Because keeping the binary size small is a stated priority in CONTRIBUTING.md, I want to propose an architecture for these features before writing any code.

Feature 1: Toggleable File Explorer (Native UI)

Navigating multi-file projects currently requires leaning heavily on the terminal or file picker. I propose adding a lightweight, toggleable folder tree sidebar.

  • UI Integration: This would be built using the existing immediate mode UI primitives in src/tui.rs and drawn to src/framebuffer.rs.

  • Behavior: It would remain completely hidden by default to preserve the classic layout, toggleable via a specific hotkey or menu bar option.

  • State Management: It would read the local directory structure lazily to ensure it does not impact the editor's extremely fast startup time.

Feature 2: AI Assistant & Live Editing (Plugin Architecture)

Bringing AI-powered live editing and an AI chat tab to the editor would be highly valuable, but introducing an HTTP client and JSON parser directly into the Rust core violates the zero-dependency philosophy.

  • The Plugin Approach: I propose laying the groundwork for the plugin system mentioned in the contributing guidelines. We could expose a simple C ABI that allows external dynamic libraries to read from and write to the text buffer.

  • External Execution: The actual AI logic, network requests, and text parsing would live entirely in a separate, optional C/C++ dynamic library that the user must explicitly load. If the user does not load the plugin, edit retains its sub-megabyte size.

  • Capabilities: The ABI would allow the plugin to either open a dedicated "AI Tab" using the TUI or manipulate text directly in the active src/buffer at the current cursor position.

Proposed Next Steps

I am happy to take the lead on building these features. Would the core team prefer to see these as two separate pull requests?

Specifically, I would like feedback on:

  • Is the team open to adding a persistent, toggleable sidebar layout to tui.rs?

  • Would you accept a PR that introduces the initial FFI/C ABI bindings to support the external AI plugin concept?

Looking forward to your thoughts!

Dominant language
Rust
Stars
14.6k
Forks
735
Avg merge
21h 38m
Merged PRs (30d)
10

Getting set up

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 microsoft/edit

All issues in microsoft/edit

Similar issues

More Rust issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.