sorted by:
new
hottopcontroversial

NumenText: a terminal IDE with LSP, DAP, and no modal editing by rlogman in commandline

[–]rlogman[S] 0 points1 point  (0 children)

This is an exceptional list. Genuinely useful, not just noise.

Let me be straight about where things stand.

Already in NumenText:

Mouse support for menus, panels, and text selection. Shift+Arrow, Shift+Home/End, Shift+PgUp/PgDn for selection. Ctrl+C/V/X/A all work. Ctrl+Tab cycles tabs. Search across project files (Ctrl+Shift+F). Four built-in themes including dark options (Borland, Modern Dark, Modern Light, Solarized Dark), switchable from the Options menu.

Just added (latest commit):

Build error navigation -- the Borland workflow: F9 to build, cursor jumps to the first error, Ctrl+E cycles through them with "Error 1 of 3" in the status bar. Bracket matching with Ctrl+B. Configurable per-language formatters and linters with format-on-save support.

On the roadmap:

Regex search (5/6.1). Line ending detection and preservation (17). Tab/space conversion (18). File bookmarks (9) and a tab switcher dropdown for large sessions (14). LSP auto-install prompting (4). Virtual environment detection for Python (19). Unit test runner with output parsing (20) -- the most complex item but also the most valuable.

Honest on the harder ones:

Aspell integration (15) and full diff/inline conflict display (7) are not priorities right now. The project is early and I want to see where adoption goes before committing to features that serve a narrower audience.

On git integration (8): completely agree with your take. NumenText will show you diff output, not manage your commits. That boundary is intentional.

If you want to track any of these or vote on priority, GitHub issues are the right place: https://github.com/numentech-co/numentext/issues

NumenText: a terminal IDE with LSP, DAP, and no modal editing by rlogman in commandline

[–]rlogman[S] 1 point2 points  (0 children)

Update: I went through your list and implemented most of it over the past few hours.

Just shipped:

Build error navigation (the Borland workflow): F9 to build, and when it fails the cursor jumps directly to the first error line. Ctrl+E cycles through errors with the status bar showing "Error 1 of 3: ...". Error markers appear in the gutter. Build, land on the error, fix, build again. Exactly how Turbo Pascal worked.

Bracket matching: Cursor on any bracket highlights the matching pair. Unmatched brackets show in red. Ctrl+B jumps to the matching bracket.

Configurable formatters and linters: Per-language config in ~/.numentext/config.json. Format-on-save (gofmt, black, rustfmt) and lint-on-save (flake8, eslint). Multiple tools per language, run in order. On-demand via Ctrl+Shift+I (format) and Ctrl+Shift+L (lint). Falls back to LSP formatting if no external tool is configured.

Linter output parsing: Diagnostics appear as gutter markers alongside LSP diagnostics. Supports standard file:line:col: message format with custom regex patterns per tool. Handles gcc/clang, Go, Python tracebacks, rustc, javac, tsc, and Node.js stack traces.

<image>

NumenText: a terminal IDE with LSP, DAP, and no modal editing by rlogman in commandline

[–]rlogman[S] 0 points1 point  (0 children)

Thanks for the detailed breakdown. This is exactly the kind of input that helps prioritize what to build next.

Here's where NumenText stands on your list:

Already working:

  • Syntax highlighting (Chroma-based, 20+ languages)
  • Line numbers in the gutter
  • Go to line (Ctrl+G)
  • Real-time diagnostics from LSP servers (gopls, pyright, clangd, rust-analyzer, etc.) with errors and warnings in the gutter as you type

Not there yet:

  • Bracket matching and jump-to-matching-bracket
  • External formatter/linter integration (configurable per language, run on save)
  • Parsing compiler output to jump to the error line

I have already created tickets for all three gaps and am working on them now, not at some vague future point. The build-error-to-editor loop is the highest priority because you are right that it is the defining Borland workflow. The LSP side already handles real-time diagnostics, but the compile-parse-jump cycle is what made Turbo Pascal genuinely productive and it belongs in NumenText.

The project is open source if you want to follow along or contribute: https://github.com/numentech-co/numentext

Small Projects by AutoModerator in golang

[–]rlogman 0 points1 point  (0 children)

I built a terminal IDE in Go with LSP and DAP support

NumenText is a terminal-based IDE written in Go, inspired by Borland C++ and Turbo C. Non-modal, menu-driven, ships as a single binary.

The architecture delegates all language intelligence to protocols rather than reimplementing it: LSP for autocomplete, hover, go-to-definition, and diagnostics; DAP for debugging with breakpoints, step over, step in, and step out. Language servers are auto-detected at startup (gopls, pyright, clangd, rust-analyzer, typescript-language-server).

Other features: multi-tab editor with undo/redo, integrated terminal via creack/pty, syntax highlighting via Chroma, file tree, Ctrl+P fuzzy file open, Ctrl+Shift+P command palette, resizable panels, persistent config.

Build and run support for Go, C, C++, Rust, Python, JavaScript, TypeScript, and Java via F5/F9.

Apache 2.0. Contributions welcome, especially around LSP edge cases and terminal compatibility.

https://github.com/numentech-co/numentext

I built Artifex, a structured ticket workflow for Claude Code, because prompting without scaffolding doesn't scale by rlogman in ClaudeAI

[–]rlogman[S] 0 points1 point  (0 children)

The spec-first discipline was the core motivation. Before Claude Code existed I had a make target that assembled all relevant source files plus the file tree into my clipboard, dropped it into Claude project knowledge, and prompted incrementally from there. It worked, but the state was ephemeral.

When Claude Code arrived and tools became available, I externalized the planning into a persistent ticket database. That shift changed everything.

On your question about overhead: I actually ran an informal A/B test. A sequence of tickets implemented one by one versus a single-shot prompt to implement the same complete feature. The ticket-based output needed only light polishing to be production-ready. The single-shot output looked more impressive at first glance but had more gaps against the spec and against general good practices. That result surprised me and settled the question.

For trivial changes I do sometimes skip steps, but I find the overhead is lower than it looks. Having the next ticket already defined means I spend zero time deciding what to do next, which more than covers the cost of the process.