turbo-editors/turbo-pythonpublic Fork 0
main
Commits
Clone
git clone https://git.rickub.com/turbo-editors/turbo-python.git
git clone ssh://git@rickub.com/turbo-editors/turbo-python.git

Host key fingerprint (ed25519): SHA256:iycHnxEyq0Q7uyVpB7JlznP0G7JrTPXLYRcAU5CSLhc — verify it before your first connect.

📦 Turbo Python 6fc62ea · on main · k33g · 10h ago
2026-09-03-first-editor.md · 82 lines · 4.4 KBmarkdown
Blame HistoryOpen raw

Handoff — 2026-09-03 — Turbo Python, first build

Where this stopped

The editor is complete and verified. Suite green, quality gate PASS, documentation
complete in both languages, .memory/ written, the family updated in turbo-core and in the
other two editors. Nothing is in flight.

What the next session must know

Nothing is committed. The whole tree is untracked on main at efb533c
(Initial commit). The user commits, tags and releases; do not do it for them. A proposed
first commit message is at the bottom of this file.

Four repositories were touched, not one. If the user commits only turbo-python, the
family updates in turbo-core, turbo-go and turbo-rust stay uncommitted beside it:

Repository Changed
turbo-core README.md, docs/{en,fr}/README.md, profile/profile.go (a comment), docs/{en,fr}/how-to/{release-the-library,test-without-publishing,write-the-starter-files}.md, docs/{en,fr}/explanation/architecture.md, .memory/summary.md
turbo-go docs/{en,fr}/explanation/architecture.md, plus three claims a pty run showed were stale: the tutorial's menu bar listing, its "→ four times" count, and reference/menus.md's opening sentence
turbo-rust the same three, plus the English reference/menus.md saying project menus appear "between Go and Help" in an editor whose menu is called Rust

Each of those three repositories has its own .memory/ history entry and handoff for what
was done to it.

None of those is an API change, so no turbo-core release is needed. turbo-python pins
v0.4.0, which is published, and needed no library change at all.

Traps met here, so they are not met again

  • A copied binary is the wrong architecture. This sandbox is Linux, the user is on
    macOS, and both see the same files. Everything built here went to /tmp, and nothing was
    left in bin/. make build recreates it.
  • Adapting is not substituting. The documentation came from Turbo Rust's and a
    mechanical pass left a dozen defects no test could see — a diagram labelled
    internal/rustlang, a tutorial that had the reader type Rust, crate in five pages,
    golangci-lint in the French explanation whose English twin was correct, and the
    English menus reference saying "between Go and Help". Grep for the editor you copied from
    and read every hit; then grep for the language, in prose, which is where the ones
    that survive hide.
  • The diagram is a file nothing imports, so nothing noticed it was Turbo Rust's.
    diagram_test.go now holds it to go list. Adopt that test in the other editors if you
    ever touch their diagrams.
  • A tutorial's key counts go stale when the library grows a menu. "Press → four times to
    reach Options" was written before the Code menu existed. Re-count them in a pty rather
    than trusting them.
  • Two uv commands in the copied docs did not exist. Run the toolchain commands you
    document; uv update has never been a thing.

If you pick this up next

Nothing is required. Things that would be worth doing, in rough order:

  1. Let the user commit and tag v0.1.0, then 03-build-releases.sh and
    04-release.upload-binaries.sh. None of the four scripts has been run for real from here.
  2. Try pyright or ruff-lsp against the same profile — the profile takes a command and
    arguments, so it is a two-line experiment, and it would tell us whether the "seven of
    nine questions" note is about pylsp or about Python.
  3. Time the scanner on a large file. It has never been measured.
  4. A Problems… entry for the tutorial was considered and left out; the tutorial
    mentions the gutter mark instead.

Proposed first commit message

Turbo Python: a Turbo C-style editor for Python on turbo-core

The command, the profile and a hand-written Python scanner — everything
else is turbo-core v0.4.0, required from the module proxy with no replace.

Scanner: all six string prefixes, both triple quotes carried across line
breaks, line continuations, decorators, soft keywords, and PEP 8's two
name shapes told apart — SCREAMING_SNAKE_CASE is a constant, CapWords a
type, even when called.

Language server: pylsp, looked for in the active virtualenv, ~/.local/bin,
pyenv's shims and macOS' per-version script directories as well as PATH.

129 tests, five of them against a real pylsp. Quality gate PASS.
Documentation in English and French, 33 pages each.
 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
# Handoff — 2026-09-03 — Turbo Python, first build

## Where this stopped

The editor is **complete and verified**. Suite green, quality gate PASS, documentation
complete in both languages, `.memory/` written, the family updated in turbo-core and in the
other two editors. Nothing is in flight.

## What the next session must know

**Nothing is committed.** The whole tree is untracked on `main` at `efb533c`
(`Initial commit`). The user commits, tags and releases; do not do it for them. A proposed
first commit message is at the bottom of this file.

**Four repositories were touched, not one.** If the user commits only `turbo-python`, the
family updates in `turbo-core`, `turbo-go` and `turbo-rust` stay uncommitted beside it:

| Repository | Changed |
| --- | --- |
| `turbo-core` | `README.md`, `docs/{en,fr}/README.md`, `profile/profile.go` (a comment), `docs/{en,fr}/how-to/{release-the-library,test-without-publishing,write-the-starter-files}.md`, `docs/{en,fr}/explanation/architecture.md`, `.memory/summary.md` |
| `turbo-go` | `docs/{en,fr}/explanation/architecture.md`, plus three claims a pty run showed were stale: the tutorial's menu bar listing, its "→ four times" count, and `reference/menus.md`'s opening sentence |
| `turbo-rust` | the same three, plus the English `reference/menus.md` saying project menus appear "between **Go** and Help" in an editor whose menu is called Rust |

Each of those three repositories has its own `.memory/` history entry and handoff for what
was done to it.

None of those is an API change, so **no turbo-core release is needed**. turbo-python pins
`v0.4.0`, which is published, and needed no library change at all.

## Traps met here, so they are not met again

- **A copied binary is the wrong architecture.** This sandbox is Linux, the user is on
  macOS, and both see the same files. Everything built here went to `/tmp`, and nothing was
  left in `bin/`. `make build` recreates it.
- **Adapting is not substituting.** The documentation came from Turbo Rust's and a
  mechanical pass left a dozen defects no test could see — a diagram labelled
  `internal/rustlang`, a tutorial that had the reader type Rust, `crate` in five pages,
  `golangci-lint` in the *French* explanation whose English twin was correct, and the
  English menus reference saying "between Go and Help". Grep for the editor you copied from
  **and read every hit**; then grep for the *language*, in prose, which is where the ones
  that survive hide.
- **The diagram is a file nothing imports**, so nothing noticed it was Turbo Rust's.
  `diagram_test.go` now holds it to `go list`. Adopt that test in the other editors if you
  ever touch their diagrams.
- **A tutorial's key counts go stale when the library grows a menu.** "Press → four times to
  reach Options" was written before the Code menu existed. Re-count them in a pty rather
  than trusting them.
- **Two `uv` commands in the copied docs did not exist.** Run the toolchain commands you
  document; `uv update` has never been a thing.

## If you pick this up next

Nothing is required. Things that would be worth doing, in rough order:

1. **Let the user commit and tag `v0.1.0`**, then `03-build-releases.sh` and
   `04-release.upload-binaries.sh`. None of the four scripts has been run for real from here.
2. **Try pyright or ruff-lsp** against the same profile — the profile takes a command and
   arguments, so it is a two-line experiment, and it would tell us whether the "seven of
   nine questions" note is about pylsp or about Python.
3. **Time the scanner on a large file.** It has never been measured.
4. **A `Problems…` entry for the tutorial** was considered and left out; the tutorial
   mentions the gutter mark instead.

## Proposed first commit message

```
Turbo Python: a Turbo C-style editor for Python on turbo-core

The command, the profile and a hand-written Python scanner — everything
else is turbo-core v0.4.0, required from the module proxy with no replace.

Scanner: all six string prefixes, both triple quotes carried across line
breaks, line continuations, decorators, soft keywords, and PEP 8's two
name shapes told apart — SCREAMING_SNAKE_CASE is a constant, CapWords a
type, even when called.

Language server: pylsp, looked for in the active virtualenv, ~/.local/bin,
pyenv's shims and macOS' per-version script directories as well as PATH.

129 tests, five of them against a real pylsp. Quality gate PASS.
Documentation in English and French, 33 pages each.
```