VS Code came up out of nowhere pretty recently, and is used by a lot of people, so that shows that there is (or was, but still post-vim) opportunity for a new editor. Whether Zed is able to gain momentum to cater for the long-tail that other developers do remains to be seen, but I'm pretty keen to see more products trying to compete for users.
Also, you know, insert Emacs joke here assuming if you still have enough RAM to post, etc.
All composed commands. Like Repeat. As in `repeat the following command 5 times`.
Like `d5` in Vim (delete 5lines).
Or y30 (Copy 30 lines).
Or `V?^func` (select text from current cursor position to the beginning of the function).
None of those are memorised commands. They're simply one command composed with another.
Composability is the real killer feature in Vim. Even in Emacs, I don't get the same ease of composability as I do in Vim.
M-b causes it to go back to the beginning of the word and search ends, you can still adjust the selection with other movements. It's not as tight as V?<regex> but it's still composable.
Or you use evil mode and get those vi-style bindings in the editor.
EDIT: Actually, playing around with your `V?` command doesn't it select that entire line rather than to that pattern? So the emacs equivalent would actually be: C-space C-M-s ^func C-e
Well, that changes things. I replied to the 'programming text editor' part.
The editor wars are over and everyone won because of separation of concerns. Yay!
The folks I know who use Emacs or vim (including me) are by and large still using those tools since before Atom and Sublime got popular. We just have LSP, now, like VSCode does.
I've tried to switch to neovim twice since and gave up. Lua is nice and I did get into that the first time. Crashing and errors were rife though. The second time, which was very recently, it seemed like everything had changed again, all completely new plugins etc. And I struggled to do some basic stuff, I guess I've just forgotten the more in-depth file/window management. So it goes.
It was a really slick play. Still, it was an overall positive for the profession, and you can still use VSCodium without the telemetry.
[0] https://insights.stackoverflow.com/survey/2021#most-popular-...
I also use either vim or nano when viewing/editing files on the command line (either msys2 wsl, or headless linux).
Re: IDEs, I mainly use IntelliJ, with VSCode being used for a few things.
I'm thinking it would be nice if my Lazarus IDE supported Vim commands.
https://github.com/neovim/neovim/wiki/Related-projects#gui
There's also the GitHub topic:
They did not seem applicable when I first saw them, so ... Mea Culpa?
Feature parity with Vim is not meaningful in my opinion. LSP evened the playing field enough for all editors to the point where you can daily drive anything and be no less productive than most.
Use whatever you like and helps you get the job done. That includes Vim too, but I'm getting sick and tired of people acting like using Vim is some kind of irreplaceable boon. Becoming a better thinker will make you an exponentially better programmer than any tool.
Vim's understanding of tokens makes some reasonable assumptions, but unless you've configured the textobjects plugin to talk to a properly configured language server, you're working on vim's presumed tokenization and not a tokenization that's native to whatever the underlying language is. Helix tries to bundle this in by default, but it still doesn't feel like a first class citizen.
As for turning machines, not since the 80's have the tokens that appear in our editors been the tokens that are manipulated by our processors. There are typically a myriad of bytecode translations or compiler optimizations or parser hijinks between what you're editing and what you're running. It's the AST that matters to the code author, and the AST is a tree, not a string.
We need to get to the point where you can directly annotate on a function parameter:
> this function is slow when this parameter is > 100
...such that the annotation sticks to that parameter, however the viewer has chosen to render the text.
The best we can do at present is to sprinkle some text nearby leave the problem of deciding which parameter and which function are referenced an exercise for the reader. This then necessitates that we preserve the way the text appears, which prevents us from presenting it differently based on the view context (e.g. maybe the reader prefers different units, timezones, or a language which flows their text differently than the author).
LSP can be the foundation to a paradigm of code editing instead of text editing. I want the kind of integration we have with Smalltalk IDE like Pharo and the SLIME plugin for Common Lisp and Emacs.
> It's the AST that matters to the code author, and the AST is a tree, not a string.
I'd take variable inspection (not sure it's the real term) before AST manipulation. More often than not, I'm more worried about the result of data processing than the processing itself. Such capability exists in live programming, such as the system itself. And I believe this kind of rapid feedback is a much better experience.
Some pretty full-featured editors already exist that people are happy with or, perhaps, have at least gotten used to. Where does a new editor fit in?
It's neat that it's "multiplayer" but that's an edge case.
I'm also not convinced by the business model. Do people really want channels, calls and chat integrated with their code editor? Personally, I have an almost visceral negative reaction to the idea but maybe that's just me.
Chat is similar.
There’s some talk in the Mac world about “Mac-assed Mac apps”. I use BBEdit as my main editor because it feels right. The default shortcuts are like every other Mac app. You can use standard Mac tools like AppleScript to automate it. It uses the same fonts, widgets, and menu systems as everything else. It’s made for that environment and it shows in a million ways.
VSCode is a marvel of engineering and I love that it exists. It also feels uncanny-valley “off” on my Mac in ways that make my brain itch, so I don’t use it. Same with Obsidian: it’s a brilliant app, but it bugs me. It’s not bad in any way, it’s just not the right choice for me.
Have you ever seen a serious programmer which is not on a Mac?
A few months ago I switched to WezTerm and, after some config wrestling, I've been very happy using it (https://github.com/bbkane/dotfiles/tree/master/wezterm).
I think of something like grep, where if I tried to grep a large hierarchy it'd be really slow and I'd sorta reason to myself "well yeah it's a lot of files in a large tree, of course it'll be slow!". Then I installed ripgrep and suddenly what I thought was a reasonable speed was shown to be unreasonably slow!
edit: see this comment for a much better explanation than mine of what I originally meant https://news.ycombinator.com/item?id=39409763
VS Code starts in under a couple of seconds, and I have it open all day long; once open, other windows open even faster than that.
If it took any longer than a couple of seconds, I'd start blaming the extensions other editors won't have.
If I'm opening a codebase with thousands of files, I don't mind to wait a couple of seconds, as long as it's responsive afterwards.
that's just the first noticeable difference.
but there have been instances lately where opening, editing and saving the file took me less time with zed than just open it in VS Code and waiting for it to be ready for inputs
> VS Code starts in under a couple of seconds
I am talking about relative speed differences. Imagine you open the same code base and the editor is ready in half a second. going back to the "slower" one would be unbearable.
now admittedly zed is no way near to the extensibility of VS Code so it is probably doing less and that's where probably much of the speed difference comes from, but it can't really be overlooked once you experienced it.