clear_screen loses track of first prompt

[lilyball]

When I press ⌘K to clear_screen, Ghostty clears everything except the current prompt, but it forgets that it's a prompt. I've confirmed this in three different ways:

1. jump_to_prompt won't jump to that first prompt
2. closing the window after clearing asks me to confirm
3. alt+click won't move the cursor

The reason I actually noticed this is that pressing ⌘K twice in a row was deleting the first line of my two-line prompt, though the confirm to close thing is a bit annoying too.

[mitchellh]

Discussion until it's directly actionable by a contributor. At this point, investigation needs to be done.

I think this is a shell bug and not Ghostty. clear_screen sends form-feed (0x0C) to the shell, and the shell is responsible for redrawing the prompt. Ghostty can't assume it'll be a prompt because technically the program can do anything given this command character.

Fish in particular I believe doesn't re-trigger the prompt start event on FF. Is this what's happening?

[lilyball]

I tested both Fish and Bash (I don't have shell integration set up for zsh since I don't use it), both fail in the same way. But now that you've mentioned this, I just tested and ⌃L also causes Ghostty to think it's no longer at a prompt, which itself is a problem.

I didn't realize clear_screen was actually deleting everything and sending form-feed, I assumed it just cleared everything up to the prompt without sending anything to the shell. Why ask the shell to repaint? The only shell I'm aware of that used absolute positioning for its prompt was nushell, and testing right now even that seems to have fixed itself since the last time I used it. That said, form-feed absolutely should still tell Ghostty that it's a prompt, and this is failing in bash so it's not just a fish issue.

FWIW I just tested and bash does not execute $PROMPT_COMMAND upon receipt of form-feed. I expect Fish is similarly not emitting a fish_prompt event here, just as it doesn't when you ask fish to repaint the prompt. So if the prompt command itself is responsible for printing the OSC 133 sequences that's a problem. But I would have assumed they'd go into the prompt string? I haven't researched the exact codes in question though.

[mitchellh]

I just tested and ⌃L also causes Ghostty to think it's no longer at a prompt, which itself is a problem.

This is definitely not handled by Ghostty at all. This sends Ctrl+L encoded key code directly to the shell, and the shell is repainting the screen. So this is definitely a shell issue. The clear_screen action is more likely fixable by Ghostty if we can find the right logic, but Ctrl+L is upstream 100%. There's a good chance it's one and the same shell bug though.

Why ask the shell to repaint?

Traditionally because we don't know where prompts are and this is the ancient terminal behavior to ask it to redraw a new page (form feed -- you put in new paper into your metaphorical physical terminal and you're asking to feed a new page).

When we do know where prompts are, I don't know. I think this is an area I'm willing to have re-researched how other terminals that support OSC 133 handle their clear screen actions. The clear screen stuff hasn't been touched in probably over a year besides basic code reshuffling...

So if the prompt command itself is responsible for printing the OSC 133 sequences that's a problem. But I would have assumed they'd go into the prompt string? I haven't researched the exact codes in question though.

Take a look at src/shell-integration. We can probably hammer a fix into there worst case for each of the shells.

[lilyball]

fwiw Terminal.app's Clear Screen behavior does not send anything to the shell, it purely manipulates scrollback history. Though it also doesn't know where the prompt is so it doesn't handle multiline prompts very well (I set up a keybinding in fish to repaint the prompt so I could hit that after every clear). I don't know how other terminals do it, but ultimately, since prompts aren't typically rendered using absolute positioning, I don't think there's much reason to send the form-feed to the shell when all we're doing is throwing away history and we do in fact know where the prompt is (at least, I'm assuming we know both the start and the end of the prompt, and not just where the insertion point is?).

That said, if we can fix form-feed behavior to work, then that would be great and would make the question of whether clear_screen sends a form-feed academic. My assumption without reading the spec is OSC 133 would have commands for "start of prompt" and for "end of prompt" and that these codes should bracket the prompt itself, and therefore would go in PS1 (for bash) or fish_prompt (for fish).