Sounds great. Looking forward to doing a simple test run with Astro SSG
I'm really liking it thus far!
It is Rust software, so there is probably a good 50-90% waste when it comes to just raw needed vs. actual lines of code in there, but there is no way anyone makes a renderer so overcomplicated that it takes up a meaningful part of the 500 MB or so Zed takes up on Windows.
We should strive to write better software that is faster, smaller and more resilient.
"Storage is cheap" is a bad mentality. This way of thinking is why software only gets worse with time: let's have a 400mb binary, let's use javascript for everything, who needs optimization - just buy top of the shelf super computer. And it's why terabytes of storage might not be enough soon.
That said, storage is cheap, it's not a mentality but a simple statement of fact. You think zed balloons their file sizes because the developers are lazy. It's not true. It's because the users have become lazy. No one wants to spend time downloading the correct libraries to use software anymore. We've seen a rise in binary sizes in most software because of a rise in static linking, which does increase binary size, but makes using and testing the actual software much less of a pain. Not to mention the benefits in reduced memory overhead.
VSCode and other editors aren't smaller because the developers are somehow better or more clever. They're using dynamic linking to call into libraries on the OS. This linking itself is a small overhead, but overhead none-the-less, and all so they can use electron + javascript, the real culprits which made people switch to neovim + zed in the first place. 400mb is such a cheap price to pay for a piece of software I use on a daily basis.
I'm not here to convince you to use Zed or any editor for that matter. Use what you want. But you're not going to somehow change this trend by dying on this hill, because unless you're working with actual hardware constraints, dynamic linking makes no sense nowadays. There's no such thing as silver bullet in software. Everything is a tradeoff, and the resounding answer has been people are more than happy to trade disk space for lower memory & cpu usage.
That is not a problem for code, but if you just want to open some random .txt file or .csv file, these are often enough not utf-8 encoded, especially if they contain non English text.
The github issue for this is showing progress, but I think it's a mistake to promote the editor to stable as is.
> does we run game engine for code??
Zed literally does this; they render their UI using a graphics library just like a video game.
They aren't high-dpi though, just big and still zoomed. On the plus side, it's very similar experience to two 4:3 monitors glued together... side by side apps on half the screen is a pretty great experience... on the down side, RDP session suck, may need to see if I can find a scaling RDP app.
As I understand, DirectWrite font rendering uses Windows subpixel font rendering. It seems OK on my monitor (better than the linux version) but haven't done any pixel peeping.
They seem to have anticipated this issue and designed it accordingly!
Seems like the only way to get high quality font rendering these days is a 4k+ display.
Just be aware that half the population prefers Windows font rendering.
I love my ARM Surface Pro, and Zed would make a wonderful editor on this hardware. If anyone from Zed is reading this, please think about it!
https://github.com/rust-lang/rust/issues/145864 was opened because of the the discrepancy
[Window Title]
Critical
[Main Instruction]
Unsupported GPU
[Content]
Zed uses DirectX for rendering and requires a compatible GPU.
Currently you are using a software emulated GPU (Microsoft Basic Render Driver) which
will result in awful performance.
For troubleshooting see: https://zed.dev/docs/windows
Set ZED_ALLOW_EMULATED_GPU=1 env var to permanently override.
[Skip] [Troubleshoot and Quit]
> Open source game streaming client
> Moonlight allows you to play your PC games on almost any device
OK, fine, maybe Sunshine will be different.
> Sunshine is a self-hosted game stream host for Moonlight.
Maybe not.
Your company trusts you to write code but not run code?
MSTSC is one of the rock-solid tools from Microsoft, and does better than almost everything else available on the market other than some PC over IP technologies specifically highly optimized for this use case. I've been programming with an ancient ThinkPad forever because I'm just remoting into a much more powerful machine.
It may not be an actual problem with zed either, despite the warning.
And if it was actually software emulated, which I can't believe for a moment, though I admit I never checked (I just always assumed the window contents were transmitted via some kind of video encoder) - then I can't imagine that a text editor would be a problem.
The input latency might not be as good as you'd like.
Yeah input latency is annoyingly rough, not super bad but _just_ laggy enough to make it annoying to use.
Debating how much I want to change things, I can directly punch into my Linux machine but all my dev IDEs are on a VM for a long list of reasons, and I doubt Zed is going to run on my old ThinkPad if it struggles on software rendering, but we'll see.
I haven't fully switched over to using it as my daily-driver because Zed's heavy reliance on GPU rendering means that it locks up every time I suspend & resume my Linux box [0,1] but I'm optimistic about the progress they're making on it.
Quick install on any platform and just works. And obviously plenty of configuration that’s available to you but if you haven’t I’d give that a go.
Tried zed, it's interesting but several things are missing including the ability to skip extensions auto-update... which imho is critical for security.
If you want to talk about perf in the context of a text editor show me how big of a file you can load--especially if the file has no line breaks. Emacs has trouble here. If you load a minified js file it slows to a crawl especially if syntax highlighting is on. Also show me how fast the start up time is. This is another area where Emacs does not do well.
So Zed is available on Windows--but only if you have a x64 processor. Lots of people run Windows on Arm64 and I don't see any mention of Arm64. This is where the puck is heading.
Also noticed Emacs key binding is in beta still.
I have never, ever felt “latency” in editor UI. Any editor UI. It’s editing text for Pete’s sake. I can only type so fast, or read so fast.
It's the same with high dpi monitors. Some people (me included) are driven absolutely insane by the font rendering on low density monitors, and other people don't even notice a difference.
Honestly, consider yourself blessed. One less thing in the world to annoy you.
Low-dpi font rendering also isn’t an issue for me, unless it is so bad as to be illegible (which no modern system is).
We really do perceive things differently.
But waaaaah they don't support a processor that accounts for probably less then 10% of Windows Machines
Also, I do not believe Windows on Arm64 is a very large demographic? Especially for developers, unless they're specifically into that platform.
Once you are beyond a bare minimum, every other speed metric is more important. Zed does really well on many of those, but some depend on the LSP, so they become the bottleneck quickly.
https://web-backend.simula.no/sites/default/files/publicatio...
> At the most sensitive, our findings reveal that some perceive delays below 40 ms. However, the median threshold suggests that motorvisual delays are more likely than not to go undetected below 51-90 ms.
By this study's numbers, 20ms is somewhat below the lower limit of ~40ms, but not too far below. 100ms would be easily perceivable - though, based on the other replies, it seems that VS Code does not actually have that much latency.
Don't confuse this with human reaction time, which is indeed an order of magnitude higher, at over 200ms. For one thing, reaction time is based on unpredictable events, whereas the appearance of keystrokes is highly predictable. It's based on the user's own keypresses, which a touch typer will usually have subconsciously planned (via muscle memory) several characters in advance. So the user will also be subconsciously predicting when the text will appear, and can notice if the timing is off. Also, even when it comes to unpredictable events, humans can discern, after the fact, the time difference between two previous sensory inputs (e.g. between feeling a keyboard key press down and seeing the character on screen), for much shorter time differences than the reaction time.
Of course, just because these levels of latency are perceptible doesn't mean they're a material obstacle to getting work done. As a relatively latency-sensitive person, I'm not sure whether they're a material obstacle. I just think they're annoying. Higher levels of latency (in the hundreds of ms) can definitely get in the way though, especially when the latency is variable (like SSH over cellular connections).
On the other hand, I just thought of one way that even a small fixed amount of latency can be a material obstacle. Personally, I type fast but make lots of typos, and I don't use autocorrect. So I need to react to incorrect text appearing on screen, backspace, and retype. The slower I react, the more text I have to delete (which means not just more keypresses but also more mental overhead figuring out what I need to retype). For this purpose, I am bound by the human reaction time, but editor latency is added on top of that. The sooner the text appears, the sooner my 'reaction timer' can start, all the way down to 0 latency. [Edit: And 100ms of latency can make a meaningful difference here. I just did a quick typing speed test and measured 148 WPM which is around 12 characters per second, so 100ms is one extra character, or a bit more.]
Also, latency might affect productivity just by being annoying and distracting. YMMV on whether this is a legitimate complaint or whether you should just get used to it. But personally I'm glad I don't have to get used to it, and can instead just use editors with low latency.
Also you can absolutely feel the visual difference between 60Hz (~16ms) and 120Hz (~8ms), and for audio it's even more nuanced.
Just because studies don't back this up yet doesn't make it false. I imagine this is really hard to measure accurately, and focusing only on neuron activity seems misguided too. Our bodies are more than just brains.
Human neural feedback loop latency is a range that varies widely depending on the type of loop involved. Reflex loops are fastest, operating in tens of milliseconds, while complex loops involving conscious thought can take hundreds of milliseconds.
Short-latency reflex: 20-30ms. Signal travels through spinal cord, bypassing the brain. E.g. knee-jerk reflex.
Long-latency reflex: 50-100ms. Signal travels to the brainstem and cortex for processing before returning. E.g. Adjusting grip strength when an object begins to slip from your hand.
Simple sensorimotor reaction: 230 - 330ms. Simple stimulus-response pathway involving conscious processing, but minimal decision-making. E.g. pressing a button as soon as light turns on.
Visuomotor control: ~150ms, adaptable with training. Complex, conscious loops involving vision, processing in the cortex, and motor commands. E.g. steering a bike to stay on a path in a video game.
Complex cognitive loops: Brain's processing speed for conscious thought is estimated at 10 bits per second, much slower than the speed of sensory data. High-level thought, decision-making, internal mental feedback. E.g. complex tasks like analyzing a chess board or making a strategic decision.
The first test was the simple one-light-one-button test. I found that I had reaction time somewhere in the 220-270ms range. Pretty much what you'd expect.
The second test was a sound reaction test: it makes a noise, and I press the button. I don't remember the exact times, but my reaction times for audio were comfortably under 200ms. I was surprised at how much faster I was responding to sound compared to sight.
The last test was two lights, and two buttons. When the left light came on I press the left button; right light, right button. My reaction times were awful and I was super inaccurate, frequently pressing the wrong button. Again, I don't remember the times (I think near 400ms), but I was shocked at how much just adding a simple decision slowed me down.
The latest benchmark I could find is 2022 and it's nowhere as bad as you claim
https://github.com/microsoft/vscode/issues/161622#issuecomme...
I know as a matter of fact that bad extensions slow down VSCode significantly.
Me! Frame rate and input latency are very important for a tool I use for hours every day. Obviously that's not the only feature I look for in an editor but if an editor _doesn't_ have it, I skip it. I also try to work on devices with 120Hz displays and above these days.
The specific techniques used to send, receive, and parse JSON could matter.
You can have custom functions in your language server that is not in spec and have your editor specific plugin call them.
I imagine there is a lot of this for typescript.
But I'm not sure if this can explain the speed difference..
One thing I noticed in the implementation is that it looks like it is using stdin/stdout for the JSONRPC inter-process communication, rather than named pipes or sockets. VSCode uses named pipes. I wouldn't be at all surprised if that's a significant bottleneck - I'm about to file a bug.
EDIT - commented on the tsserver thread here: https://github.com/zed-industries/zed/issues/18698#issuecomm...
You can build the most beautiful and fastest IDE, but with this bugs, it’s useless
I'd like to properly give it a go one day due to the effort put into its vim keybindings, but until then I'll stick to neovim.
The only feature that is preventing me from switching to Zed is the current lack of DevContainer support[1]. After investing a significant amount of time perfecting a devcontainer (custom fat image with all tools/libs + config), it would be a large step backwards to go back to installing everything locally.
There's a lot of eyes on this feature, so I'm hopeful it will be implemented in the future.
I’m all for documenting every bit of my setup, but beyond that…
Why not write that document as a bunch of build instructions instead of free-form text, while also isolating the result from the rest of the system.
In the devcontainer you can run code snippets, use the system shell and access an execution environment close to production if well made.
It also allows to avoid (system) dependency conflicts between different projects you may work on.
There's other toolchains that are more involved or conflict with an operating system's pre-installed stuff, like (iirc) Ruby on MacOS.
All the other editors I use are aware of outside changes, but not Zed. And I'm just not willing to close and reopen the file to get fresh contents. Eventually, I'll forget to do it and lose some work.
Changes to open files without any modifications in the buffer are always shown. Are you using any kind of containers or virtual fs that might be interfering?
What's worse is C++ autocomplete - both on the same project with clang and CMake - it might be that I need some more setup, but I felt like Zed understood much less of tricky modern C++ (tbf, VS Code isn't perfect either) and the autocomplete was kinda broken. I fully admit this might be due to my own inexperience, so I won't hold it against Zed, but so far I haven't seen anything significantly better to justify making the switch.
Also after install, the install directory takes up 400MB+. Even VSCode only takes up around 380MB. I believe it when they say it's not an Electron app, but I do wonder what's being packed in there. I was always under the impresion that Rust apps are pretty lightweight, but that install size is nearing Java levels of binary/dependency bloat.
This needs to be justified asap to help people understand and reconsider installing it.
897MB! But it appears to have installed itself twice for some reason. Maybe one is an 'update' which it didn't clean up...? I'm not sure.
Edit: I just opened it and it cleaned itself up. 408MB now. I guess it was in the process of upgrading.
Honestly I'd be all for this if the OS had a good autoupdate mechanism for 3rd party applications. But that's not the world we live in. Certainly not on windows - which is too busy adding antivax conspiracy articles to the start menu.
And with Chromium this directly leads to crashes - when you update the browser as its open, the new tabs will open with the new version of the binary, with the old ones still using the old binary - which usually leads to crash.
I prefer 'you cannot do X' instead of 'we allow you to do it, but it might misbehave in unpredictable ways'.
The world moved into dynamic linking in the 1980's for a reason.
It is cool to advocate for a return to static linking when it is basic CLI tools.
Reasons that no longer exist. Storage is cheap, update distribution is free, time spent debugging various shared lib versions across OSes is expensive.
They should shut up and just buy bigger drives. Ah, they can't on their laptops, bummer.
Also try to develop mobile apps with that mentality,
https://www.abbacustechnologies.com/why-your-app-keeps-getti...
You could say "just don't buy Apple products". And sure, that might be a solution for some. But the question of what laptop to buy is an extremely complicated one, where storage pricing is just one of many, many, many different factors. I personally have landed on Apple laptops, for a whole host of reasons which have nothing to do with storage. That means that if I have to bump my storage from 1TB to 2TB, it directly costs me $600.
I don't check the installation size of applications anymore.
This feels especially relevant since we're discussing Zed here, the Mac-focused developer tool, and developers working on Mac are the exact people who pay $600/TB.
Embrace your wallet will be owned by Apple. Then you can continue.
Sorry, but people buying Apple products are different bread :D
My /usr is 15G already, and /var/lib/docker isn't that far off despite people's obsession with alpine images. If more people would dismiss storage as cheap it'll quickly become expensive, just not per GiB.
> update distribution is free
I wouldn't be surprised if at one point Github would start restricting asset downloads for very popular projects simply because of how much traffic they'd generate.
Also, there's still plenty of places on the planet with relatively slow internet connectivity.
I'll be very grateful if you stopped using all my RAM for two buttons and a scrollbar thank you.
> At this time, we prioritize performance and out-of-the-box functionality over minimal binary size. As is, this issue isn't very actionable, but if you have concrete optimization ideas that don't compromise these priorities, we'd be happy to consider them in a new issue.
For people who are serious about their text editors, 400m is a small price to pay for something that works for you.
Maybe compared to electron, but binary size is an issue with any nontrivial rust application. Due to how cargo works, it compiles and bundles in every dependency in world.
400MB is unnecessarily large though.
Half of Electron namely Node.js. As majority of lsp are .js based. Also extensions are WASM. Also VS Code keeps extensions in separate config directory, while Zed in main directory.
400 mb for new project in this amazing bestest compiled language ever made is ridiculous.
And that's still comparing apples to oranges, because git is compiled with full optimizations. Running `cargo build --release` produces a 462KB binary.
Even if I'm comparing to my system's git installation, that's still 3.9MB, and that's with all the debug info stripped.
Yes rust (like C++) tends to produce larger binaries than C, but lets be real here: The reason Zed has a bloated binary is the ~2000 rust packages that comprise it.
Hundreds of those MBs are from tree-sitter grammars, which are JavaScript compiled to C.
For what it's worth, the zed executable on Linux weighs 3.2 MB.
EDIT: Sorry, the nix store is too good at hiding things from me. It's actually around 337 MB plus webrtc-sys.
$ pwd
/tmp/zed/target/release
$ ls -lh ./zed
-rwx------ 2 john john 1.4G Aug 28 17:10 zed
$ dut zed/ | sort -h
598M 0B | | /- webrtc-sys-0a11149cbc74bc90
598M 0B | | | /- out
598M 0B | | |- webrtc-sys-090125d01b76a5e8
635M 160M | | /- s-hal7osjfce-1h7vhjb-4bdtrsk93m145adnqs17i9dxe
635M 160M | | |- project-06kh4lhaqfutk
641M 161M | | /- project-1ulvakop54j8y
641M 161M | | | /- s-hal5rdrth3-0j8nxqq-d0wsc7qnin39797z4e8ibhj4w
1.1G 1.1G | | /- zed-ed67419e7a858570
1.1G 1.1G | |- zed
1.3G 1.3G | /- zed-64b9faeefdf3b7df
1.3G 1.3G |- zed
1.4G 0B |- build
2.2G 0B | |- build
7.9G 1.4G /- deps
9.4G 0B |- release
14G 2.9G | |- incremental
19G 4.2G | /- deps
33G 0B /- debug
42G 0B /- target
42G 0B zed
$ du -h ./target/debug/deps/
20G ./target/debug/deps/
$ du -h ./target/release/deps/
8.0G ./target/release/deps/
$ du -h ./target/debug/zed
1.2G ./target/debug/zed
$ du -h ./target/release/zed
1.4G ./target/release/zed
Any explanations as to why "cargo" does not seem to re-use libraries (dependencies) in a shared directory, or why it needs >2000 dependencies (that I see being downloaded and compiled), or why the executable file of the release mode is 1.4G unstripped while of the debug one it is less?
ls -lh /nix/store/63rdpgbzn7f1smh7688crcrpfsh833bb-zed-editor-0.199.10/bin/zeditor
-r-xr-xr-x. 2 root root 3.2M Jan 1 1970 /nix/store/63rdpgbzn7f1smh7688crcrpfsh833bb-zed-editor-0.199.10/bin/zeditor
ls -lh /nix/store/52smrb1z8r4n71zx50xagkcdrhlga4y5-zed-editor-0.207.4/libexec/.zed-editor-wrapped
-r-xr-xr-x. 2 root root 337M Jan 1 1970 /nix/store/52smrb1z8r4n71zx50xagkcdrhlga4y5-zed-editor-0.207.4/libexec/.zed-editor-wrapped
$ strip --strip-all ./target/release/zed
$ du -h ./target/release/zed
261M ./target/release/zed
$ strip --strip-all ./target/debug/zed
$ du -h ./target/debug/zed
482M ./target/debug/zed
To make matters worse, it takes several minutes for Zed's window to appear on a cold start, whereas VSCode launches almost instantly.
[1] I am trying to measure it as we speak but it is taking quite a long time.
That one is interesting. It's much quicker for me, even cold starts are below 1s, and subsequent startups are basically instant.
I wonder why though.
[1] I have not measured subsequent launches of VSCode though, but Zed is relatively pretty quick after the initial launch.
Unless by "compiled in", some in-lining of the C code into Rust codebase is meant.
[1] https://github.com/emacs-tree-sitter/tree-sitter-langs/relea...
Maybe something like this to figure out what directories to delete:
# With dut
find . -type f -name Cargo.toml -printf '%h\n' | sort -u | xargs -r -d '\n' -I{} dut -s {} | sort -h
# With du
find . -type f -name Cargo.toml -printf '%h\n' | sort -u | xargs -r du -sh | sort -h
ripgrep $ cargo clean
Removed 3411 files, 1020.2MiB total
websocat $ cargo clean
Removed 1726 files, 820.7MiB total
Or the fact that there is incremental compilation artifacts...
And of course the amount of dependencies. A single project might depend on hundreds of crates (quite common), each compiled separately with its own build artifacts. sighs.
I'm not sure what gave you that impression. I'd say Rust is pretty well known for fat binaries
RAM:
213 MB Zed
41 MB ST
Storage:
406 MB Zed
52 MB ST
Startup time:
Zed is slower than ST (but only by a few milliseconds).
Also when you reopen ST it will remember how you've resized the window from last time whereas Zed won't.
Haha wait what? Are you confusing Zed (the text editor) with something else? Surely it doesn't ship with video conferencing???
I disagree Zed is an IDE, it is quite far from InteliJ, Borland/Embarcadero, VS, XCode, Eclipse, Netbeans...
If it is about adding enough plugins until it eventually becomes one, then any programmer's editor is an IDE.
Try to use Zed to debug Go code.
Zed is the new emacs?
In Zed, you need to write a full blown plugin, and can change only what the Zed authors exposed through their plugin API.
For me, as long as it's better than alternatives it's good enough. Especially if it's not running JS.
i can’t describe it in any other way other than it feels cold to use
i wonder if anyone else felt the same in earlier versions and feels that it’s fixed
Okay, I may ocassionally do some code editing on it. But most of the time it's gotta be VSCode or vim/nvim.
I hope Zed stays clean. We'll see. So far so good. Was quite happy they had a JetBrains base hotkey setup. Had to add a few of my own but I could pretty easily, nothing missing so far.
It's native code, and it shows. It also has some AI integrations that are different, but I don't know how well they work.
It looks nice, but I haven't managed to use it for long.
Last I checked, cheapest MacBook is $999+ for the air.
It obviously varies a lot by the preferred languages, but Windows is still at the top, on average.
Turns out there are plenty of other jobs as programmers.
What I meant was there are so many problems with Windows that the team cannot do it quickly (they post about it before: https://zed.dev/blog/windows-progress-report).
Just surprised, as I thought building GUI app on Windows must be easy right, as must be libs/frameworks already available to support that? It's just not.
I worked at multiple FAANGs and can't see me or any of my colleagues capable of doing this.
1. I deleted a few hours of work because I was late night coding and I decided to rename a file before check-in and delete the old version. Well I renamed it and Right-Click -> Deleted the new version by accident.
It turns out Zed has both "Delete" and "Trash" right next to each other in its right-click menu. Delete skips the trash and Zed does not implement Ctrl+Z yet, so unless you have a backup that file is gone. Because I renamed it and had not yet checked in it wasn't in version control yet.
2. For some reason a particular crate in my Rust workspace wasn't having errors and warnings show up in the editor. I messed with configuration a bunch and couldn't figure it out, so I tried VSCode and it just worked without any additional configuration.
Like what's the benefit?
I would be using Zed full time if Sublime Text wasn't already perfect for me.
- Issues with various keybinds not working as expected, e.g. Ctrl+S to save works on my Linux machines but not Windows if Vim Mode is enabled
- Issues with LSPs/diagnostics not working on Windows the same way they work on macOS/Linux
- The terminal holds a lot of assumptions about how the system works that don't hold true on Windows, e.g. "the user has one shell they use for all things" or "setting environment variables in the OS is easy"
I love Zed on my work issued macbook and use it full time, but the Windows version still needs some work.
Windows has a GUI, how can it not be easy. /s
It isn't as easy as on Linux, but you press Windows, type env, click edit Variables then select User vs. System, the you press add. That's not too complicated.
Like, it’s not great.
Wait, what? That seems like an incredibly important missing piece of functionality.
I'm not going to claim Zed has a good UI in this space, but saying it doesn't implement Ctrl + Z for a feature which is literally "skip the undo-ability of this option" is a bit misleading.
"Delete" is the last option in the right click menu for both and when you select it both show a very similar dialogue box asking you to confirm.
VSCode's 'Delete' by default moves the file to the trash and can be undone with Ctrl + Z. Zed's 'Delete' skips the trash and can't be undone with Ctrl + Z.
I should have mentioned the confirmation box but after years of use I've begun clicking through that box so quick I didn't realize the behavior was different in Zed.
After years of deleting files in VSCode I have a muscle memory for that behavior and I just skip through the dialogue. I didn't realize Zed's 'Delete' worked differently until I lost work, so I was just reflexively skipping through its confirm screen as well.
So --
* if there is no such dialog, it's on zed * If there is such a dialog and you clicked yes, it's on you
Just checked, there is a modal dialog that reads:
*Delete "asd"?*
(Cancel) (Delete)Zed's dialogue just says "Delete file.txt?" so if you're used to VSCode it's very easy to skip through that dialogue reflexively.
It randomly deleted 3-line chunks all across my codebase. No rhyme or reason. I was just about to commit a big change, so it was annoying.
It might have been a global search and replace, but there was no clue in the history. And I can't think what kind of regex it could have been.
Or maybe a bug in IPC with the language server?
Anyone got any clues about what I did?
(I love Zed, on Mac and Linux. Even went as far as buying a new graphics card as my 5-year-old one didn't have Vulcan support, which is pretty much mandatory for Zed)
If you then Ctrl+A to select all and press backspace, I wonder if that would delete all those 3-line chunks...
(I'm asking instead of finding out myself because of the little interest I have in this editor)
Either you have a community that happily maintains extensions or you have an "official" extension manager that rolls out an update every next year
Seems like a reasonable ask.
> or you have an "official" extension manager that rolls out an update every next year
As a debian user, sign me up!
https://zed.dev/docs/configuring-zed#auto-install-extensions
Unfortunately, there's a bunch of small things still holding me back. Proper file drag & drop for one, the ability to listen to audio files inside the editor, and even a bunch of extensions, in particular one that shows a spectrogram for an audio file.
Maybe my biggest gripe is that Python support is still better in VSCode. Clicking on definitions is faster and more reliable.
When vscode was released, Sublime was faster - and it stayed faster. But that wasn't enough to stop the rise of vscode.
Yes ofc I can use Finder instead but in vscode I just cmd+p.
Bye
nwah1•23h ago
janpio•22h ago
metaltyphoon•21h ago
janpio•13h ago