Rewrite issue #10, add issue #11 (Ctrl-C REPL behaviour)

Rewrite #10 with refined interactive command design: bare-word REPL
fallback instead of ! prefix, result table assigned to _, same shape
as captured commands. Add #11 for Ctrl-C clearing the current line
instead of exiting the REPL.

issues/11-ctrl-c-repl-behaviour.md

@@ -0,0 +1,49 @@
+# Issue #11 — Ctrl-C REPL behaviour
+
+**Status:** open
+
+## Problem
+
+The Lua REPL immediately exits on Ctrl-C. This is annoying — every other shell and REPL (bash, zsh, python, node) treats Ctrl-C as "cancel what I'm typing", not "quit".
+
+## Desired behaviour
+
+**Dirty line** (cursor on a line with text already typed):
+- Clear the current input line
+- Print a fresh prompt on a new line
+
+```
+> local x = some_long_exp^C
+>
+```
+
+**Empty line** (no text typed yet):
+- Print `^C` and a fresh prompt (consistent with bash/zsh)
+- Optionally: two consecutive Ctrl-C on empty lines could exit (like Python's REPL), but this may be unnecessary if `Ctrl-D` / `exit` works
+
+## Current behaviour
+
+The Lua REPL sets a debug hook via `laction()` on `SIGINT` that calls `luaL_error(L, "interrupted!")`. This aborts whatever Lua code is running and also kills the REPL input loop.
+
+## Implementation approach
+
+The fix is in `lua.c`'s REPL loop. The signal handler needs to behave differently depending on context:
+
+**During input** (waiting for user to type a line):
+- If using readline/libedit: readline already handles `SIGINT` — it clears the line and returns. We just need to not treat this as a fatal error.
+- If using the `fgets` fallback: set a flag on `SIGINT`, check it after `fgets` returns, clear the buffer and re-prompt.
+
+**During execution** (running Lua code):
+- Keep the existing behaviour: interrupt the running code with an error. This is correct — `SIGINT` during a long-running Lua computation should stop it.
+
+## Open questions
+
+- Should readline's `rl_catch_signals` / signal handling be configured explicitly?
+- Does libedit (macOS default) handle `SIGINT` the same way as GNU readline?
+- Should Ctrl-C during a multi-line continuation (prompt `>>`) discard the entire multi-line input and return to the primary prompt?
+
+## Files touched
+
+| File | Description |
+|------|-------------|
+| `lua.c` | Modify signal handling in `doREPL()` / `pushline()` to distinguish input vs execution context |