fix: parse lf as newline separate from cr as enter

[CSRessel]

relates to: #1505

[CSRessel]

This works for the ghostty setup with keybind = shift+enter=text:\n

Unfortunately I couldn't think of a straightforward way to handle the shift+enter=text:\x1b\r mapping that some people are using, but I would expect that is less common. Also, this PR stands alone quite well as a feature improvement for handling just the linefeed, whereas handling the weirder control sequence with escaped carriage return ought to have it's own discussion of the merits.

I've confirmed this is working on Linux with ghostty, appreciate anyone else's sanity check on Windows or Mac in particular.

[CSRessel]

Also this is very closely modeled off of the existing implementation for CR vs ctrl+M

Please correct all details I might have misunderstood and copied from that implementation!

[rekram1-node]

Going to test it

[rekram1-node]

So what terminal(s) does this work in that didn't before? just to be clear?

[CSRessel]

In ghostty, with all operating systems (in theory), the Claude-modified config that people often have:

# ~/.config/ghostty/config
keybind = shift+enter=text:\n

would lead to OpenCode ignoring shift enter newlines. Now after this PR, when new users come to OpenCode with this config (or any other config for a line feed character), shift+enter newline still works

EDIT: in theory, this could also be the case for WezTerm, VSCode terminal, or Sublime terminal (just going by the Claude docs — those are other terminals they try and modify keybinds for)

[rekram1-node]

@CSRessel hm if I put that in my ghostty config, restart ghostty, and run opencode, shift enter already works

Could it be another terminal it is an issue for?

I also tested in a few other teminals and I can't seem to see any difference from these changes and latest opencode, just wanna be sure I understand the change and what it solves

Sorry for continuous reviewing I just wanna understand what is being solved & where

[rekram1-node]

also claude was doing the shift+enter=text:\x1b\r not the newline one

[CSRessel]

No you're spot on that OpenCode does work for shift+enter with the config I mentioned above; I just confirmed your result on my machine.

I'm not sure if I was previously having this issue with an earlier version of OpenCode, or the different config of shift+enter=text:\x1b\r that you point out. (I've been using the CSI u sequence in my config for a while now, since it's supported in OpenCode and in Codex, and I haven't touched claude's CLI for a while)

I can think some more about if it's possible to cleanly support the \x1b\r sequence! And retarget this PR for that fix

[rekram1-node]

that'd be awesome thank u

[CSRessel]

I revisited this last night, and figured out how I think tui/input/parse.go should be modified to support the \x1b\r sequence. However, I can't get my modifications to the go modules to be picked up within bun dev, and I haven't found anything in the repo that describes or automates this process (package.json scripts, build scripts, readmes, etc).

Since the go TUI code is being deprecated anyway I'm inclined to close this, unless it's a very straightforward process to test out go parse changes?

[rekram1-node]

@CSRessel if you run bun run dev it will always build and use the local go changes

Feel free to close if you prefer