anomalyco/opencode
1
0
Fork 0
mirror of https://github.com/anomalyco/opencode.git synced 2026-07-22 02:05:26 -04:00
Code Issues 5.9k Packages Projects Releases 19 Wiki Activity

Emacs keybindings frustratingly inconsistent #3194

New Issue
Closed
opened 2026-02-16 17:39:03 -05:00 by yindo · 17 comments
yindo commented 2026-02-16 17:39:03 -05:00
Owner
Copy Link
Copy Source

Originally created by @gwd on GitHub (Nov 28, 2025).

Originally assigned to: @kommander on GitHub.

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

  1. Type a paragraph
  2. Type a second paragraph
  3. 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

Originally created by @gwd on GitHub (Nov 28, 2025). Originally assigned to: @kommander on GitHub. ### 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 1. Type a paragraph 2. Type a second paragraph 3. 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
yindo added the opentuibug labels 2026-02-16 17:39:03 -05:00
yindo closed this issue 2026-02-16 17:39:03 -05:00
yindo commented 2026-02-16 17:39:04 -05:00
Author
Owner
Copy Link
Copy Source

@github-actions[bot] commented on GitHub (Nov 28, 2025):

This issue might be a duplicate of existing issues. Please check:

  • #2649: Standard keyboard cursor navigation (Home/End key, ctrl+left/right key) - covers Ctrl+A behavior for line navigation
  • #3978: Cannot Navigate the TextArea using Ctrl and Alt - covers similar keybinding navigation issues
  • #3640: Surprising unexpected ctrl+p/ctrl+n behaviour - related to emacs keybindings not working as expected
  • #1268: Basic undo feature - addresses the missing undo functionality that would prevent data loss

Feel free to ignore if none of these address your specific case.

@github-actions[bot] commented on GitHub (Nov 28, 2025): This issue might be a duplicate of existing issues. Please check: - #2649: Standard keyboard cursor navigation (Home/End key, ctrl+left/right key) - covers Ctrl+A behavior for line navigation - #3978: Cannot Navigate the TextArea using Ctrl and Alt - covers similar keybinding navigation issues - #3640: Surprising unexpected ctrl+p/ctrl+n behaviour - related to emacs keybindings not working as expected - #1268: Basic undo feature - addresses the missing undo functionality that would prevent data loss Feel free to ignore if none of these address your specific case.
yindo commented 2026-02-16 17:39:04 -05:00
Author
Owner
Copy Link
Copy Source

@ariane-emory commented on GitHub (Nov 28, 2025):

C-k deleting 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?

@ariane-emory commented on GitHub (Nov 28, 2025): `C-k` deleting 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?
yindo commented 2026-02-16 17:39:04 -05:00
Author
Owner
Copy Link
Copy Source

@kommander commented on GitHub (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 https://github.com/sst/opentui/pull/344. I am currently not sure how to handle these conflicting expectations best.

@kommander commented on GitHub (Nov 28, 2025): undo/redo is ctrl+- (minus/dash) and ctrl+. (dot)<br><br>There are conflicting expectations all around on what the default bindings should be I am afraid. Just recently this one went into opentui [https://github.com/sst/opentui/pull/344](https://github.com/sst/opentui/pull/344). I am currently not sure how to handle these conflicting expectations best.
yindo commented 2026-02-16 17:39:04 -05:00
Author
Owner
Copy Link
Copy Source

@ariane-emory commented on GitHub (Nov 28, 2025):

Personally, I've long since grown accustomed to maintaining a 300+ line .el file 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.

@ariane-emory commented on GitHub (Nov 28, 2025): Personally, I've long since grown accustomed to maintaining a 300+ line `.el` file 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.
yindo commented 2026-02-16 17:39:04 -05:00
Author
Owner
Copy Link
Copy Source

@gwd commented on GitHub (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.

@gwd commented on GitHub (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.
yindo commented 2026-02-16 17:39:04 -05:00
Author
Owner
Copy Link
Copy Source

@kommander commented on GitHub (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.

@kommander commented on GitHub (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.
yindo commented 2026-02-16 17:39:04 -05:00
Author
Owner
Copy Link
Copy Source

@gwd commented on GitHub (Nov 29, 2025):

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"?

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.

@gwd commented on GitHub (Nov 29, 2025): > 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"? 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.
yindo commented 2026-02-16 17:39:04 -05:00
Author
Owner
Copy Link
Copy Source

@jdanbrown commented on GitHub (Nov 29, 2025):

There are conflicting expectations all around on what the default bindings should be I am afraid. Just recently this one went into opentui https://github.com/sst/opentui/pull/344. I am currently not sure how to handle these conflicting expectations best.

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.

@jdanbrown commented on GitHub (Nov 29, 2025): > There are conflicting expectations all around on what the default bindings should be I am afraid. Just recently this one went into opentui https://github.com/sst/opentui/pull/344. I am currently not sure how to handle these conflicting expectations best. For cli apps, isn't readline by far the most commonly used thing, and thus the closest we have to a de-facto standard? - https://man7.org/linux/man-pages/man3/readline.3.html 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.
yindo commented 2026-02-16 17:39:04 -05:00
Author
Owner
Copy Link
Copy Source

@Lenbok commented on GitHub (Dec 10, 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!

@Lenbok commented on GitHub (Dec 10, 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!
yindo commented 2026-02-16 17:39:04 -05:00
Author
Owner
Copy Link
Copy Source

@kommander commented on GitHub (Dec 11, 2025):

What OS and terminal emulator do you expect alt+d to be word forward deletion for? In the textarea it is currently mapped to delete-line which was the expectation from other users.

@kommander commented on GitHub (Dec 11, 2025): What OS and terminal emulator do you expect `alt+d` to be word forward deletion for? In the textarea it is currently mapped to `delete-line` which was the expectation from other users.
yindo commented 2026-02-16 17:39:04 -05:00
Author
Owner
Copy Link
Copy Source

@ariane-emory commented on GitHub (Dec 11, 2025):

I'd like that in iTerm2 on MacOS. Since I live in emacs, I'm soooo accustomed to M-d aka alt+d meaning kill-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.

@ariane-emory commented on GitHub (Dec 11, 2025): I'd like that in iTerm2 on MacOS. Since I live in emacs, I'm soooo accustomed to `M-d` aka `alt+d` meaning `kill-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.
yindo commented 2026-02-16 17:39:04 -05:00
Author
Owner
Copy Link
Copy Source

@b0o commented on GitHub (Dec 11, 2025):

Same here. I always expect Alt+D to delete the next word in CLIs, shells, repls. I even have my browser configured like that. I've never heard of Alt+D doing delete-line. I have lost multiple prompts in opencode due to this behavior, it's been very annoying. Alt+D doing kill-word has been the default behavior in any shell I can remember using - sh, bash, zsh, nushell. Same for REPLs like node, python, R, lua. It also works the way I expect in Claude Code.

@b0o commented on GitHub (Dec 11, 2025): Same here. I always expect Alt+D to delete the next word in CLIs, shells, repls. I even have my browser configured like that. I've never heard of Alt+D doing delete-line. I have lost multiple prompts in opencode due to this behavior, it's been very annoying. Alt+D doing kill-word has been the default behavior in any shell I can remember using - sh, bash, zsh, nushell. Same for REPLs like node, python, R, lua. It also works the way I expect in Claude Code.
yindo commented 2026-02-16 17:39:04 -05:00
Author
Owner
Copy Link
Copy Source

@jdanbrown commented on GitHub (Dec 11, 2025):

+1 alt+d (M-D) does kill-word in readline, which is always what I consider to be the closest thing to an authority on cli line editing norms:

@jdanbrown commented on GitHub (Dec 11, 2025): +1 `alt+d` (`M-D`) does `kill-word` in readline, which is always what I consider to be the closest thing to an authority on cli line editing norms: - https://man7.org/linux/man-pages/man3/readline.3.html#DEFAULT_KEY_BINDINGS
yindo commented 2026-02-16 17:39:04 -05:00
Author
Owner
Copy Link
Copy Source

@kommander commented on GitHub (Dec 11, 2025):

alt+d by default will be delete-word-forward. Additionally, all textarea input actions will be customizable, so any default that does not live up to personal standards can be remapped.

@kommander commented on GitHub (Dec 11, 2025): `alt+d` by default will be `delete-word-forward`. Additionally, all textarea input actions will be customizable, so any default that does not live up to personal standards can be remapped.
yindo commented 2026-02-16 17:39:04 -05:00
Author
Owner
Copy Link
Copy Source

@Lenbok commented on GitHub (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!)

@Lenbok commented on GitHub (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!)
yindo commented 2026-02-16 17:39:04 -05:00
Author
Owner
Copy Link
Copy Source

@kommander commented on GitHub (Dec 11, 2025):

For completeness https://opencode.ai/docs/keybinds/ - should list all the additional input_* binding possibilitie.

@kommander commented on GitHub (Dec 11, 2025): For completeness [https://opencode.ai/docs/keybinds/](https://opencode.ai/docs/keybinds/) - should list all the additional `input_*` binding possibilitie.
yindo commented 2026-02-16 17:39:04 -05:00
Author
Owner
Copy Link
Copy Source

@aspiers commented on GitHub (Jan 17, 2026):

Anyone interested in Emacs keybindings will probably be interested in #6778 too.

@aspiers commented on GitHub (Jan 17, 2026): Anyone interested in Emacs keybindings will probably be interested in #6778 too.
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
acp
bad
bug
discussion
docs
documentation
enhancement
extension
good first issue
growth
help-wanted
mcp
model-problem
needs:compliance
nix
opentui
perf
pull-request
Mirrored from GitHub Pull Request
 tui
web
windows
zen
No Label bug opentui
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
yindo
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: anomalyco/opencode#3194
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?