Emacs Compatibility Tracking Issue

[morgoth]

Rather than a monolithic "implement emacs in Zed" enhancement request (which is inherently unactionable) this issue is a tracking issue for centralizing various Zed bug fixes and enhancements to better supporting emacs-like compatibility and operation in Zed.

• Add emacs keymap #19605
• cut-buffer / yank support for ctrl-k and ctrl-y #14260
• Add a mark / select mode #8580
• Visual overline syntax decoration like Emacs' "Decorate Tags" option in EDE mode  #20986
• User-defined visual text substitutions (Prettify Symbols Mode in vim/emacs/vsc) #18420
• Zed Terminal is slower to process ctrl-x than MacOS Terminal (emacs) #16214
• Editor::KillRingCut support for multiple lines? (emacs) #22490

Comments such as "I need emacs mode to switch to Zed!" and the like are unwelcome here.
Please vote with 👍 below instead.

Editor note (@notpeter): Originally this issue was for an emacs keymap, a beta of which shipped in #19605

[ozanmakes]

An offical "Emacs mode" would be really nice. There is a couple of example user configurations over here: https://github.com/zed-industries/community/discussions/1653

At the moment the lack of a "mark" command is the biggest holdup. In Emacs, pressing Ctrl+SPC will toggle selection and let you use movement commands to select text without keeping Shift pressed. Any chance this could be added to Zed?

[akaihola]

At the moment the lack of a "mark" command is the biggest holdup. In Emacs, pressing Ctrl+SPC will toggle selection and let you use movement commands to select text without keeping Shift pressed. Any chance this could be added to Zed?

At least there's an issue for this (go and vote!):

• Add a mark / select mode #8580

[notpeter]

For those following this issue we've recently shipped two emacs-related improvements:

• Add emacs keymap #19605
• Implement readline/emacs/macos style ctrl-k cut and ctrl-y yank #21003

Please try out the Emacs (beta) keymap by triggering the welcome: toggle bas keymap selector:

It's very basic at this point, but give it a whirl, happy to consider PRs with improvements / refinements.

Rather than close this issue I've repurposed it as a tracking issue for additional Emacs-related enhancements and I've edited the issue description above to include links to other issues.

One other update, sadly, due to issues with international keyboards we also opted to revert terminal.option_as_meta to default to false again:

• Make terminal.option_as_meta=false in default settings #19364

If you need emacs/readline style keybinds in your terminal which use meta / alt you will want to add this to your settings.json:

  "terminal": {
    "option_as_meta": true
  }

[notpeter]

I've added a bunch of the suggestions provided above and hidden the associated comments to keep this thread from growing out of control. Where possible I'm trying to stick only the actual default emacs keybinds and avoid people's personal binds.

Here are some recent improvements which have made their way into Zed:

• Add emacs keybinds for previous/next/cancel in search #21921 is available in v0.167.x (since last Wednesday 2025-01-01 in Zed Stable)
• Emacs keybinding improvements (2025-01-02) #22590 will be available in v0.169.x (from Wednesday in Zed Preview; Zed Stable 2025-01-15)

@rakete Nifty that There's you've managed to build a Mark mode workaround with AutoHotKey.
As mentioned above, there's also a a dedicated issue:

• Add a mark / select mode #8580

[dmvianna]

I'm a big fan of occur. Would it be too much to add it to a task? Obviously that's functionality that goes well beyond keybindings.

[notpeter]

@dmvianna I don't have any experience using emacs occur but fundamentally it looks quite similar to a Zed Project Search multibuffer. Zed multibuffers support editing across multiple files while paging through search results. Currently multibuffers default to +2 / -2 lines of context above/below the line in question, I imagine it would be possible to create an occur search multibuffer that have 0 lines of context and potentially hide 'expand context up/down' buttons to create a more minimalist view which more closely resembles occur. Feel free to file an issue. To be upfront, it's not something we're likely to immediately prioritize, but it definitely would be worth tracking user interest.

[kzar]

It might be worth adding "ctrl-o": "editor::Newline" for the editor context?

[notpeter]

@kzar Emacs ctrl-o behavior is slightly different that editor::Newline, ctrl-o creates a newline below but does not move the cursor. I would prefer to add support for an optional parameter to the editor::NewlineBelow action so that we could bind "ctrl-o": ["editor::NewlineBelow", {"move_cursor": false}].

Similar to this:

zed/assets/keymaps/default-linux.json

Line 306 in ba7b9b3

"ctrl-/": ["editor::ToggleComments", { "advance_downwards": false }],

zed/crates/editor/src/actions.rs

Lines 79 to 85 in ba7b9b3

	#[derive(PartialEq, Clone, Deserialize, Default)]
	pub struct ToggleComments {
	#[serde(default)]
	pub advance_downwards: bool,
	#[serde(default)]
	pub ignore_indent: bool,
	}

And then add a conditional inside the newline_below to optionally move the cursor.

zed/crates/editor/src/editor.rs

Line 3139 in ba7b9b3

pub fn newline_below(&mut self, _: &NewlineBelow, cx: &mut ViewContext<Self>) {

[kzar]

Good point about not moving the cursor, but I don't think that editor::NewlineBelow is right because if you're at the start of a line C-o should move the current line down (or if you're in the middle of a line, it should move the part after your cursor down). Perhaps we could go with your approach to stop the cursor moving, but with editor:Newline?

[kzar]

"ctrl-t": "editor::Transpose" for the editor context is another one I kept missing. (@notpeter is it helpful if I keep commenting with these, or if not is there a better way to share them that would help?)

[dmvianna]

@dmvianna I don't have any experience using emacs occur but fundamentally it looks quite similar to a Zed Project Search multibuffer.

I opened a feature request, where I delve more deeply into the differences between occur and Zed Project Search Multibuffer: #22943

[dmvianna]

Oh, duh.

"context": "Editor:"

    "ctrl-y": "editor::Paste",
    "alt-w": "editor::Copy",
    "ctrl-w": "editor::Cut",
    "ctrl-?": "editor::Redo",
    "ctrl-shift-n": "editor::SelectDown",
    "ctrl-shift-p": "editor::SelectUp",
    "alt-shift-f": "editor::SelectToNextWordEnd",
    "alt-shift-b": "editor::SelectToPreviousWordStart",
    "ctrl-alt-shift-f": "editor::SelectToEndOfLine",
    "ctrl-alt-shift-b": "editor::SelectToBeginningOfLine"

This below also stops the Assistant from opening at every attempt to run editor::Redo.

"bindings"

  "alt-x": "app_menu::OpenApplicationMenu",
  "ctrl-?": null

And this prevents the cursor movement commands from opening new buffers when reaching beyond the first and last lines of a buffer.

"context": "Workspace:"

  "ctrl-n": null,
  "ctrl-p": null,

[dmvianna]

Another biggie: the kill ring. Basically a copy history that you can browse through by typing alt-y after the first ctrl-y (paste). And all its associated commands, as actually seeing the list of copy items in memory before choosing one (pressing alt-y not preceded by ctrl-y or itself).

There's an issue for it already, it would be nice to have it in the description of this issue too.

[dmvianna]

Moving around the workspace panes is different from Emacs, which will just cycle through all available buffers and has no default concept of how they're positioned. Zed seems to organise them spatially, so instead of having just the default Emacs ctrl-x o (which I rebinded to alt-o as per Mastering Emacs in my own configuration), I had to use spatial bindings. I dislike it; I find Emacs's approach better, especially when I can use IBuffer to locate buffers by name using ctrl-x b.

In Emacs, I go to the pane I want the buffer to be and switch to it by name. In Zed (at least for now), I have to locate the pane by looking at the tabs, switching to the pane and then choosing the desired tab. Suboptimal.

Here's my current config:

"context": "Workspace"

  "ctrl-x o": "tab_switcher::Toggle",
  "alt-x b": ["workspace::ActivatePaneInDirection", "Left"],
  "alt-x f": ["workspace::ActivatePaneInDirection", "Right"],
  "alt-x p": ["workspace::ActivatePaneInDirection", "Up"],
  "alt-x n": ["workspace::ActivatePaneInDirection", "Down"]

[dmvianna]

pop-global-mark in Emacs takes you back to the last mark, which in Zed it is the same as xref-go-back.
"context": "Pane"

  "alt-,": "pane::GoBack",  // xref-go-back
  "ctrl-x ctrl-space": "pane::GoBack",  // pop-global-mark
  "ctrl-u ctrl-space": "pane::GoForward"  // set-mark-command with negative prefix

Typing ctrl-x ctrl-space fast enough in Zed is tricky. How can I make Zed less impatient?