Hacker News Reader

Comment by maxbrunsfeld | Hacker News Reader

What forms of keyboard navigation are you missing? We try to make sure everything is controllable from the keyboard.

The first thing I always do when I go into any new editor is set up the "Select All Instances of highlighted word". So like how there is cmd-d for the next occurrence, I also like having a shortcut to select _all_ occurrences. Would love for this to be added.

More generally, this looks really awesome and also really enjoyed your team's blog post detailing the GPUI implementation (even though large parts of it went over my head)

Yes, these are an absolute must :) Came here looking specifically if this was possible. The cool thing is that is currently the only thing I've been missing after playing for a couple hours! I've tried vscode yearly to see if it had become tolerable, but alas. This is the first time I've tried something that might steal me away from Sublime.

There's an issue for it: https://github.com/zed-industries/community/issues/75

I haven't played enough with it to give good feedback, I've edited my comment to be more fair.

* Seems to me that a lot of the keyboard shortcuts are chords or require hitting an arrow key, sometimes even both. Example: VS Code's default mapping for vertical split is cmd+backslash, but Zed requires cmd+k -> arrow key.

* The project panel (file tree) doesn't support hjkl for navigation. The website says Vim mode is still under construction, but in my mind that applies to actual buffer editing, not general UI interactions. My impression is that today most editors, hell even a lot of websites, support hjkl or similar for navigation in cases where it doesn't conflict with anything else.

My perspective is that "keyboard-focused" implies "ergonomic shortcuts and UI navigation without leaving the home row". If I'm gonna move my hand from the home row to reach the arrow keys, I might as well just reach for the mouse and get 10x the possible interactions. Anecdotally, I tested myself just now and I'm pretty sure it takes me more time to "find my footing" when I move my fingers to the arrow keys than it does to just grab a mouse and click something.

This might be wrong expectations on my end, but my hope is that Zed can bring the powerful navigation of Doom Emacs/Spacemacs minus the bugginess and terrible performance of Emacs. Whenever the devs talked about Zed, I just imagined VSpaceCode without the jank that comes when you override 90% of an editor's default bindings. What I'm seeing from an hour of usage doesn't feel that much more powerful than VS Code in terms of keyboard navigation (kudos on the snappy performance though, it really is night and day). I'm aware this is an early beta, I just hope you folks agree and are going to push more in this direction.

Yeah, they don't seem to have any serious Emacs person in their team. So, like so many people who try and build editors in the last few decades, they seem to miss some fundamental things (while focusing on other worthy things like the core rope+crdt enabling fast local & collaborative editing).

They talk about things like having a plug-in type system in the future based on e.g. WASM but, as you're pointing out, their fundamental perspective is built around the simplistic notion of a control panel with fixed functionality that's primarily accessed via a bizarre set of keymaps. On this front, might as well stick with JetBrains.

Having some kind of leader keybinding would be great along with something like "which-key" for discoverability.

Checking out Spacemacs or Doom Emacs would give a clear idea of what I'm talking about.

If unfamiliar with emacs, VSpaceCode is a VSCode extension that ports Spacemacs-style keybindings pretty successfully, although the UI is suboptimal due to limitations of VSCode extensions.

I couldn't find a way to show/hide various panels. e.g. line numbers, the bars with the (<- ->) arrows etc.

Would be great to allow toggling visibility of each of these pieces via an action to maximize screen real estate. Really annoying in VSCode that they force you to go into settings for some of the visibility toggles. Of course, didn't spend very long investigating.

Also after selecting VSCode keybindings, CMD+\ does not split the editor as it does in VSCode. Seems like a bug

Reply on news.ycombinator.com