ctrl_d_exits: Ctrl-D at a prompt, where the tty cannot do it

Windows has no VEOF. The console driver does not know the character, so
^D arrives at cmd.exe and PowerShell as an ordinary keystroke and they
ignore it -- it even echoes, which is how you find out: the line reads
`echo hello^D`. The one key that closes a pane on every other platform
does nothing at all, and closing a pane becomes a word you have to type.

That you can type `exit` instead is the tell: the intent was never
ambiguous, only unspoken. So slosh speaks it. What goes to the pane is
the word, not a signal and not a close from outside -- the shell runs
its own cleanup, returns its own status, and keep_dead decides what is
left behind, all three of which reaching past it would skip. It is also
what the user would have typed, so there is nothing new to explain.

The knob is what makes it honest, because a wrong guess costs a pane.
It fires only with the shell itself in the foreground (a program that
is running may want the EOF for itself -- `cat` reading to end is the
whole job), only on the primary screen (in an editor or a pager ^D is
half a page down, and the alternate screen is the pane stating that
rather than us matching process names), and only on an empty line
(POSIX sends EOF there; what it does not do is discard what you typed).

The line is an estimate. The shell's editor is on the far side of a
pty, so pane_send_key counts what it forwarded since the last Enter.
Editing it does not model -- a recalled history entry, ^U, completion
-- leaves the count too high, which forgets to exit. That is the
direction to be wrong in; the other one throws away a half-typed
command.

Default true on Windows, false on POSIX, where the line discipline
already does this and does it properly: ^D there is also EOF for `cat`
and every REPL, none of which is ours to intercept. A knob rather than
an #ifdef so the guards are the same code everywhere and can be tested
where the test suite runs -- test_ctrl_d.py turns it on and drives all
four decisions, plus the case that does exit.

Telling trapped from forwarded needs a program that reports what it
received: on POSIX a forwarded ^D also ends an idle shell, and looking
for the word `exit` cannot separate them either, because bash prints
`exit` itself on EOF.

Verified on the Windows box as well, where it is the default: ^D at an
idle cmd.exe prompt takes the pane (and with it the session, having no
panes left), `more` in the foreground keeps its own EOF, and a
half-typed line survives with the line still on screen.

1 files changed, 35 insertions, 0 deletions

diff --git a/src/app.c b/src/app.c
index 795eb97..d931774 100644
--- a/src/app.c
+++ b/src/app.c
@@ -1372,6 +1372,40 @@ static bool prefix_command(app_t *a, const input_event_t *ev) {
   return run_action(a, config_lookup(&CFG, ev->key, ev->mods));
 }
 
+/* Ctrl-D where the line discipline cannot do it: see `ctrl_d_exits` in
+ * config.h for why this exists and why it is this narrow.
+ *
+ * What it sends is the word, not a signal. `exit` is what the user would have
+ * typed and what every shell slosh can start already understands, so the pane
+ * ends the way it ends on POSIX -- the shell's own cleanup, its own exit
+ * status, and `keep_dead` deciding whether the corpse stays. Reaching past the
+ * shell to close the pane would skip all three, and would also be a second
+ * meaning for a key that already has one.
+ *
+ * Returns true when the keystroke was spent here and must not be forwarded. */
+static bool ctrl_d_exit(app_t *a, const input_event_t *ev) {
+  if (!CFG.ctrl_d_exits || ev->action == KEY_RELEASE) return false;
+  if (ev->key != GHOSTTY_KEY_D) return false;
+  if ((ev->mods & (MOD_CTRL | MOD_ALT | MOD_SUPER | MOD_SHIFT)) != MOD_CTRL)
+    return false;
+
+  pane_t *p = cur(a)->focus->pane;
+  /* An editor or a pager reads ^D as half a page down, and both live on the
+   * alternate screen -- which is the one thing here the pane can state rather
+   * than have guessed about it. */
+  if (pane_alt_screen(p)) return false;
+  /* A program in the foreground is a program that may want the EOF itself.
+   * NULL is the shell at its own prompt, with nothing running under it. */
+  char fg[1024];
+  if (pane_foreground(p, fg, sizeof fg)) return false;
+  /* On a line with something on it, POSIX sends EOF and the shell ignores it;
+   * what it does not do is throw the line away. Neither do we. */
+  if (!pane_line_empty(p)) return false;
+
+  pane_write(p, "exit\r", 5);
+  return true;
+}
+
 /* What an action does, given the action rather than the key that asked for it
  * -- because the command palette asks for actions by name, and a palette that
  * had to synthesise a keystroke to run one would be inventing input. */
@@ -1672,6 +1706,7 @@ void app_event(app_t *a, const input_event_t *ev) {
       pane_start(cur(a)->focus->pane);
       break;
     }
+    if (ctrl_d_exit(a, ev)) break;
     pane_send_key(cur(a)->focus->pane, ev);
     break;
   case EV_MOUSE: {