{{ message }}
Repository navigation
Emacs keybindings frustratingly inconsistent #4877
Description
Description
So a fairly hardcoded sequence of keys in my brain for emacs is "Ctrl-A Ctrl-K", to go to the beginning of the line and delete it.
Unfortunately, currently in opencode:
- Ctrl-A takes you to the beginning of the entire text window, not the beginning of that line
- Ctrl-K then deletes the first paragraph, which is often something I spent over a minute writing
- There doesn't seem to be an "Undo" function to get this text back (e.g., Ctrl-_ or Cmd-Z)
This has happened to me three times today, and I don't remember it happening before; has something changed?
I could deal with the Ctrl-A behavior if there was some way to undo the Ctrl-K; but to have your work just go up in smoke is really frustrating.
OpenCode version
1.0.119
Steps to reproduce
- Type a paragraph
- Type a second paragraph
- Press "Ctrl-A" then "Ctrl-K" in quick succession
First paragraph is deleted instead of the second paragraph
Screenshot and/or share link
No response
Operating System
macOS
Terminal
Ghostty
Activity
github-actions commentedon Nov 28, 2025
This issue might be a duplicate of existing issues. Please check:
Feel free to ignore if none of these address your specific case.
ariane-emory commentedon Nov 28, 2025
C-kdeleting instead of yanking is a readline-ism, lots of apps are like that (for example, most shells like bash/fish/etc and most other agent CLIs)... I do agree that I'd prefer yanking, but I've kind of gotten used to it, and I'm sure many other folks have the opposite preference and prefer it just how it is. shrug What can ya do?kommander commentedon Nov 28, 2025
undo/redo is ctrl+- (minus/dash) and ctrl+. (dot)
There are conflicting expectations all around on what the default bindings should be I am afraid. Just recently this one went into opentui anomalyco/opentui#344. I am currently not sure how to handle these conflicting expectations best.
ariane-emory commentedon Nov 28, 2025
Personally, I've long since grown accustomed to maintaining a 300+ line
.elfile of custom keybindings in my emacs config: so, I don't really care what the default keybindings are - so long as they can be rebound, I'm happy to do a little work and rebind keys myself.Maybe we could have a second command that yanks the remainder of the line, not bound to any key by default but allowing those of us who'd prefer this behaviour to configure a keybinding for it ourselves? That way, we wouldn't change the default behaviour and surprise users who have come to expect it and those with different preferences would have a way to get what we want, keeping everybody happy.
gwd commentedon Nov 28, 2025
@kommander It looks like opentui#344 is the main fix I want. Thanks for the undo -- I'll give that a try! Is that documented anywhere?
@ariane-emory I've gotten used to C-k is delete in bash as well; generally I really did mean to delete it and accept the consequences if I don't. But when you're expecting to delete the paragraph you're on and instead you end up delete a completely different paragraph, that's an issue.
kommander commentedon Nov 28, 2025
I don't think new default keybindings are documented properly yet.
As for start/end of line the question is: logical or visual line?
When just typing along it will Auto wrap the text visually, but it is still just one logical line. So does it jump to the start of where it wrapped visually or to the beginning of the logical line, which could be considered a "paragraph"? I think there is a lot of confusion coming from that.
gwd commentedon Nov 29, 2025
It looks like macOS goes to the beginning of the logical line, and emacs in wordwrap mode goes to the beginning of the visually wrapped line; so either one seems like a reasonable choice. I'd say go with what you think is best, and feel free to chose based on what's easiest to implement.
jdanbrown commentedon Nov 30, 2025
For cli apps, isn't readline by far the most commonly used thing, and thus the closest we have to a de-facto standard?
That's not to say that every app needs to mimic readline 100%, but just that a least-surprising design choice is to default to readline behaviors as much as is reasonable for a given app, since readline's behaviors are the behaviors that most cli users will expect.
Lenbok commentedon Dec 11, 2025
A f**ing frustrating one for me is Alt-D which my neurons trigger to delete a word forward actually clears the entire prompt!
kommander commentedon Dec 11, 2025
What OS and terminal emulator do you expect
alt+dto be word forward deletion for? In the textarea it is currently mapped todelete-linewhich was the expectation from other users.ariane-emory commentedon Dec 11, 2025
I'd like that in iTerm2 on MacOS. Since I live in emacs, I'm soooo accustomed to
M-dakaalt+dmeaningkill-word(delete the word ahead of point and put it in the clilpboard) that not having the same behaviour in opencode is something I frequently trip over.1 remaining item
jdanbrown commentedon Dec 11, 2025
+1
alt+d(M-D) doeskill-wordin readline, which is always what I consider to be the closest thing to an authority on cli line editing norms:kommander commentedon Dec 11, 2025
alt+dby default will bedelete-word-forward. Additionally, all textarea input actions will be customizable, so any default that does not live up to personal standards can be remapped.Lenbok commentedon Dec 11, 2025
That will be a great frustration reducer! Please also link to documentation that lists all the default keybinds. (The keybind section of the opencode docs seems to only have a few examples)
(Edit: just saw your message on another issue about the newly extended documentation - thanks!)
kommander commentedon Dec 11, 2025
For completeness https://opencode.ai/docs/keybinds/ - should list all the additional
input_*binding possibilitie.aspiers commentedon Jan 18, 2026
Anyone interested in Emacs keybindings will probably be interested in #6778 too.
mikaelj commentedon Feb 21, 2026
If the opencode team has decided that ctrl-k is delete, why couldn't it be yank instead? Both delete the line, the difference is that yank also places it in a buffer where it can be restored with ctrl-y.
It's strictly better.
Non-Emacs user suffer from the non-yanking too. I hate Emacs, love Vim. But still use ctrl-k/ctrl-y, all the time.
It's how standard UN*X systems (Linux, macOS) these days behave. Why reinvent a square wheel? You already do C-a, C-e, C-k (but wrong).
In fact, looking at the opencode keybindings mapping, I think the goal was to emulate this but the one doing it didn't fully understand it never having used C-y, and now it seems they're not willing to back down on a bad decision? Sheesh.
ariane-emory commentedon Feb 21, 2026
@mikaelj Using Control+K for yank would be truly novel behaviour, not resembling either readline or Emacs. Normally in Emacs, Control+K is
kill-line, and Control+Y isyank.Contro+K to delete the line (without killing it to the clipboard) is readline/shell behaviour, and it appears that that's the team has chosen.
mikaelj commentedon Feb 21, 2026
@ariane-emory my description was incorrect.
What I meant was:
Ctrl-K to delete to end of line and put it in a buffer.
Then C-y to paste the contents of the buffer.
That's how bash works on my Linux and macOS systems.
ariane-emory commentedon Feb 21, 2026
@mikaelj That isn't what I see. Control+K just deletes the line for me in bash.
bash_compressed.mp4
mikaelj commentedon Feb 22, 2026
I have
set -o emacs.The counter-argument to my statements about how bash behaves was: "bash does not do that"
As you can see and test for yourself, it clearly does.
Now that I have trivially falsified that statement -- can we move along?
I know there are key bindings, but none of them is
input_copy_and_kill_to_line_end.So I guess that's the bug report.
ariane-emory commentedon Feb 22, 2026
@mikaelj I will agree that we were both not speaking as precisely as we could have: apparently bash can do this, but it does not do this by default.
mikaelj commentedon Feb 22, 2026
ariane-emory commentedon Feb 22, 2026
I'm not sure that "who used
C-kfor anything at all first?" was ever what was at question. If so, you didn't make that clear. I'm sure if I dug further back, I could find even earlier uses for this key. What did BBN's Interlisp-D useC-kfor? How about Multics? I'm sure these probably used this key for something, but why should we care?In any case, so far as I'm aware the team's intent with the keybindings is to ape readline, and any resemblance to the emacs bindings that you and I love is largely a spandrel that rides along as a result of aping readline.
ab commentedon Aug 19, 2026
@ariane-emory Bash does do
C-yas yank by default. So does readline. Was your test with some customized shell environment?https://www.gnu.org/savannah-checkouts/gnu/bash/manual/bash.html#Readline-Killing-Commands-1
https://man7.org/linux/man-pages/man3/readline.3.html