nik/lush

Files

Cormac Shannon 47abb04921 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.

2026-02-28 23:20:55 +00:00

2.0 KiB

Raw Blame History

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

2.0 KiB Raw Blame History