They wrote their own GUI toolkit (oof) and it's hardware accelerated (argh), so OS portability is going to be unusually difficult unless they planned for it from the beginning. No mention of that in the article, so I doubt they did.
hypertown@lemmy.world
on 27 Feb 2024 06:33
nextcollapse
They already have very experimental Linux support. You have to build whole app yourself though. I’d say that in month or two we’ll get a binary.
You can track Linux porting progress in this issue
abhibeckert@lemmy.world
on 27 Feb 2024 10:00
nextcollapse
Because GTK is designed for GUI software, and this is a text editor. Almost everything is text - it’s got more in common with Vim than Gedit.
eveninghere@beehaw.org
on 27 Feb 2024 14:18
nextcollapse
Edit: I’m writing this out of my ass, so don’t quote me.
They wrote that they GPU(I?)-accelerate the font rendering. Well, indeed, fonts are usually rendered with CPUs because it’s slow to use the traditional VRAM (which sits in the GPU) for this task, given that the text itself is stuck in the RAM (sitting right next to the CPU). With integrated chips like the Apple Silicon, it probably makes sense to move the font rendering into the GPU because the memory is unified. GTK is absolutely not designed to do this, AFAIK.
But that also means that, to get this particular benefit of their dedicated GUI framework, you probably have to buy an Apple Silicon Mac. There are PCs with similar architecture, iirc, but that also means that there’s no way you can upgrade your GPU or RAM individually in the future… My fear is that, on a standard PC, it might be just as responsive as other editors.
Didn’t treesitter come from the Atom editor? These guys always take things really far so this isn’t surprising.
saddlebag@lemmy.world
on 27 Feb 2024 08:00
nextcollapse
Its already possible to build manually on linux and there’s a tracking issue.
*edit. same as the other post
Carighan@lemmy.world
on 27 Feb 2024 08:11
collapse
I mean on the one hand, the hardware acceleration is awesome. The GUI toolkit is not of course (I assume MacOS has a default one to make everything look like it belongs?), but at least they made it look like a native app instead of the usual electron shit where it’s clearly a web page with a window border and some design 15y old me might think is cool but 16y old me would already have been ashamed of.
As I understand, GUI toolkits will usually support various widget styles or “Look and Feels”.
So, they can just use a glossy graphic for a button on macOS and a flat graphic on Windows 11, without having to reimplement the whole application in the native toolkit. It will usually not feel entirely native, but at least, it won’t look out of place…
mvirts@lemmy.world
on 27 Feb 2024 03:48
nextcollapse
🎉
Sanctus@lemmy.world
on 27 Feb 2024 04:01
nextcollapse
I’ll be watching this one. It looks nice. Please come to Linux. I do loves me my vim. I did not like setting it up as much as I thought I would to be an IDE. I’m sorry I was mean Zed.
NeoNachtwaechter@lemmy.world
on 27 Feb 2024 05:43
nextcollapse
Yes, that was mean, because nobody is able to make another editor as powerful as vim.
Time will tell for sure, but helix is looking really good and once they have support for plugins I’m rather sure it will be a very, very powerful editor.
zygo_histo_morpheus@programming.dev
on 27 Feb 2024 07:47
collapse
I don’t think helix will ever catch up to a lot of vims lesser know features of which there are a lot. I think that’s by design as well, I think that helix wants to have a smaller surface area than vim and for a lot of people that will be the right choice. I personaly use ex-commands for example, or the quickfixlist fairly often so for me I have a hard time imagining helix not feeling like a step down power-wise (as nice as multiple cursors are).
abhibeckert@lemmy.world
on 27 Feb 2024 09:57
nextcollapse
VSCode has way more features than Vim. Including the ability to run Vim inside the IDE. Or Emacs.
Sais no-one that knows vim, thou it have a vi-like mode that is missing most advanced vi-trixs.
priapus@sh.itjust.works
on 27 Feb 2024 19:24
collapse
I was also disappointed not to have ex-commands, but I soon realized Helix’s use of multiple cursors with commands that support regex can accomplish the same tasks in a way I found more intuitive. Definitely took a bit to get rid of my :%s/new/old/g muscle memory, but Helix’s select command works very similarly and just as quickly.
Quickfix commands on the other hand I never used. It seems Helix has some features such as jumping to diagnostics and errors, but it doesn’t have the ability to do so automatically after running make like Vim does (afaik). I don’t write much C, so I didn’t know that feature existed to begin with.
zygo_histo_morpheus@programming.dev
on 27 Feb 2024 20:10
collapse
Multiple cursors are a lot better than :s for you standard search and replace, unless you have a really big file at which point helix gets to slow (which isn’t that common) but there are a lot of other stuff you can do with ex commands.
I use :make pretty often, vim ships with the ability to parse a lot of compiler/linter outputs out of the box so if you tell it which one with :compiler you get build errors in the quickfix list. I also use :grep a lot. You can do <space>/ to grep in helix but I often find that I want to add command line options to only search in specific directories or for specific file types (we have a large codebase at work). Being able to filter results with :Cfilter, and being able to go back to old quickfix results with :colder is also really nice. Finally, you can use :cdo to apply ex commands to stuff you’ve matched in the quickfix list.
As an example, if you get a build error because you’ve renamed a variable in one file but not the places it gets referenced in other files, you can :make to get the build errors in you quickfix list, :Cfilter to narrow it down to only that specific class of error if needed and then do :cdo s/oldName/newName/g to rename the variable in all places that cause errors. You can then go back to the list of all errors with :colder and handle other errors in another way if needed.
I’ll have to admit that I don’t do this that often so honestly I wouldn’t lose out on that much switching to helix (after it gets proper plugin support and someone makes a decent replacement for the fugitive git plugin) but I would feel less powerful not knowing that I have those tools up my sleave lol.
priapus@sh.itjust.works
on 27 Feb 2024 21:07
collapse
Those are some neat features. I hadn’t heard of them when I was using Vim. Parsing the compiler output to go straight to the error is very cool. I definitely think plugin support will bring a lot of people to Helix. I don’t currently have any features I’m waiting on, but I’m sure I’ll find some plugins to make it even better once they’re available.
I’ve been trying out Helix as of late. It’s a bit different than vim, but I’m beginning to like it.
seliaste@lemmy.blahaj.zone
on 27 Feb 2024 09:39
collapse
Helix’s autocomplete is too bad for me to be able to like it
priapus@sh.itjust.works
on 27 Feb 2024 19:15
collapse
what do you mean? Helix uses LSP servers, usually the same ones used by Vim and VS Code.
were you using it without the LSP’s installed? If you were, then you would only get completion based of the treesitter grammars, which would be very limited.
seliaste@lemmy.blahaj.zone
on 27 Feb 2024 19:25
collapse
no, the autocomplete trigger is rly bad and triggers when moving the cursor around instead of when you actually type
It’s a documented problem and they are working on fixing it
priapus@sh.itjust.works
on 27 Feb 2024 19:28
collapse
Ah I see. I usually only move the cursor when in command mode, so that might be why I haven’t noticed it. That’s unfortunately an issue I’ve noticed in a lot of editors. In fact, because Zed is so fast, the auto completion is super obnoxious atm and constantly flashes at you while you type.
seliaste@lemmy.blahaj.zone
on 27 Feb 2024 19:29
collapse
I know it’s the intended way but I’m too much of a modal noob for that, I’m actually working on a non-modal editor for this reason that’s similar to helix and fish philosophies
cozy_agent@lemmy.world
on 27 Feb 2024 06:59
nextcollapse
Nice, been finding vscode more and more laggy after each update, so hopefully this is something to replace it with at some point.
FooBarrington@lemmy.world
on 27 Feb 2024 11:21
nextcollapse
The inevitable cycle of modern open-source text editors. First there was Atom, then that got too slow and most switched to VS Code. Next seems to be Zed… I wonder what comes after it!
DrDeadCrash@programming.dev
on 27 Feb 2024 12:38
nextcollapse
Lapce looks pretty cool, for an alpha.
fruitycoder@sh.itjust.works
on 27 Feb 2024 17:56
collapse
Seems fair tbh. As long as the total usability goes up to that is!
jelloeater85@lemmy.world
on 27 Feb 2024 20:26
collapse
I had the same prob, when I swapped to Codium and paired down my plugins, it was snappy again.
tunetardis@lemmy.ca
on 27 Feb 2024 07:05
nextcollapse
I tried it briefly. It certainly is a lot snappier than Atom ever was, I’ll give it that. Seemed to be pretty good with Python, but when I opened some C++ source, it went around reformatting my indentation and replaces tabs with spaces. I will have to see if there is a way to disable all that, as I found it obnoxious.
QuadriLiteral@programming.dev
on 27 Feb 2024 13:59
collapse
If I wrote an IDE and detected tabs I’d just have it delete the codebase
It was more than just tab conversion. For example, it decided on its own that:
if(...) {
...
}
else {
...
}
would look better like:
if(...) {
...
} else {
...
}
I mean I guess I could live with that, but really? I imagine there’s some config where you can disable all this, but it just doesn’t seem worth some giant git commit every time I touch a file with the editor.
My guess is that it has that default because they use Rust. Everyone uses rustfmt so everything looks the same and if you always format before a commit you never get massive diffs.
Most rust projects I’ve seen even have a ci job to check the formatting with rustfmt.
nyakojiru@lemmy.dbzer0.com
on 27 Feb 2024 07:18
nextcollapse
It’s strange because how much “powerful” or “high performance” a code editor needs? It’s just , a code esitor you can code in notepad lol
Pyroglyph@lemmy.world
on 27 Feb 2024 07:49
nextcollapse
You can code in Notepad in the same way you can eat off the floor with your hands. Using better tools is a nicer experience.
As for performance, when one of the world’s most popular editor runs on Electron, it’s not that hard to see why performance could be an issue when working on large projects on older hardware.
I’ve never personally had an issue with VSCode’s performance, but I’m also fortunate enough to be in a position where I can afford a relatively modern machine. Many others have to make do with what they have, which is why Zed might appeal to them.
azertyfun@lemmy.blahaj.zone
on 27 Feb 2024 11:20
nextcollapse
Electron has other drawbacks than performance as well.
The big one for me is that my workflow is based on vim, where you split tabs into buffers. There is no way to split a tab into windows in VSCode. Only windows into tabs, which is super dumb and annoying because related files are never shown together unless you click a bunch of tabs. Apparently the reasoning for this insane behavior is “yeah well electron is based on chromium so tough luck we can’t do shit”.
spartanatreyu@programming.dev
on 28 Feb 2024 00:50
collapse
What do you mean by:
There is no way to split a tab into windows in VSCode.
Do you mean, drag a tab out of a window to create a new window? Because if so, you can do that in vscode.
azertyfun@lemmy.blahaj.zone
on 03 Mar 2024 16:32
collapse
No, literally have one tab with multiple windows inside it (the default for vim).
tab 1 | tab 2
w1 | w2 | w1 | w2
w3 | w4 | w3
spartanatreyu@programming.dev
on 04 Mar 2024 00:21
collapse
I’m assuming for your example that only one tab is shown at a time?
In that case, you can do that in vscode, the only difference is the semantics of what is considered a “window”, and what is considered a “tab”.
To do this in vscode:
Have one window with four panes, and another window with three panes:
I mean I don’t care, I’m very happy with vim now. But the terribly naive tab support is the reason I left vscode for vim initially. People who have only known “vscode-like” tabs don’t know what they are missing out on.
spartanatreyu@programming.dev
on 07 Mar 2024 04:07
collapse
You mean a whole different window at the OS level?
Yes, that way I could switch between windows in a single shortcut, or even place them side by side so I can see both at the same time with other shortcuts.
That’s just a way inferior hack to the way vim does it by default.
Can you explain this more?
Why wouldn’t you want window management to be managed by the window manager?
azertyfun@lemmy.blahaj.zone
on 02 Apr 2024 15:04
collapse
Sorry, I didn’t log into this account for a while.
Anyways, I guess in an ideal world the window management could be done fully via the window manager. In practice this doesn’t work too well, because that would require a more complex protocol than currently exists. For VSCode for instance, that would require disabling the native tabbing feature (but keeping the native splitting because otherwise I’ll end up with duplicated panes such as the file list) and implementing something custom to translate tab operations to sway-wm operations (in my case).
I guess it could work but it’s not supported OOTB, and after a lot of work is probably going to end up being a lot more clunkier than what I have going on in vim.
jelloeater85@lemmy.world
on 27 Feb 2024 20:28
collapse
I mean, I rock JetBrains for a lot of stuff. It’s a pig on resources, but man does it have a great feature set.
Carighan@lemmy.world
on 27 Feb 2024 08:12
nextcollapse
Yeah like Atom or VSCode this is more a half-IDE in concept. Assuming it gets enough support it’s somewhere between a text editor (but will be more sluggish than pure text editors and struggle with very large files but then you ought to have specialized log viewers for that anyways) and an actual IDE (but have only limited IDE features).
eveninghere@beehaw.org
on 27 Feb 2024 13:43
nextcollapse
Agreed. It’s weird to put the performance of a text editor at the center of PR.
I have sooooo many questions.
Why do they compare a text editor’s performance with that of IDEs??? CLion is possibly the slowest of all Jetbrains IDEs because the C++ language is very complex. Choosing CLion makes even less sense because IntelliJ is now public-testing a lightweight C++ CLion spinoff, which is faster than CLion.
Why should I care whether my editor is written with Rust? C was fine as long as I trust the devs on security. Async doesn’t matter at all to the enduser…
Besides, if I wanted a snappy editor I just use vim.
My fear is that they might have concluded that all the performance boost they made wasn’t important as a text editor, and they are presenting some weird comparison to hide it.
Besides, if you write C++, the bottleneck is not the typing response, but the code analyzer.
It’s also not like C++ is a language used by majority of customers. Why not advertise with JavaScript instead? Python? Those are also better fit for text editors. Because statically typed languages like C++ can benefit hugely from a full-fledged IDEs, taking away the room for this text editor further.
It feels like their AI integration is not outstanding (probably not, indeed).
The collaborative editing might not align well with their emphasis on responsiveness, either, because the network latency will be felt. Not to mention that collaborative editing is pioneered by IntelliJ, also.
Why do you need another channel/chat management tool if your team already has a Slack? Why would your team use a chat platform that can be used only by mac users?
As I indicated in my other comment, it’s possible that the PC port of their GPUI-based GUI can be far slower due to the heave reliance on Apple Silicon. I even doubt a port is possible in the first place, especially if their code heavily relies on Apple-specific APIs for the Silicon.
And all descriptions of their features are suspiciously vague. How are they better than a marketing scheme to raise the stock price?
Maybe it is going to be just an average editor in the era of remote-office (looking at channels and collab edit), ChatGPT-assists (AI-integration) and async. Maybe it’s a proof-of-concept that will soon give ways to another generation of editors.
NotSteve_@lemmy.ca
on 27 Feb 2024 15:26
nextcollapse
You can really see the difference between opening VSCode and Zed, even more so if you compare it to something like JB’s Fleet editor.
To be fair, it’s not the easiest to compare right now since Zed is lacking a million features of Code, but if all the work they’ve done keeps it as fast as it is with features like user extensions it will be well worth it.
I usually have ~10 different VS Code windows open at a time (yay microservices ❤️), so having something as fast as Zed would be really appreciated.
learningduck@programming.dev
on 27 Feb 2024 17:08
nextcollapse
I could notice the slowness of Atom when I compared it to VS Code.
Sublime is also noticeably faster than VS Code, but the gap doesn’t feel so wide that I want to jump the ship.
I think it depends on the number of characters in the file that make the difference more noticeable.
fruitycoder@sh.itjust.works
on 27 Feb 2024 18:01
collapse
I’ll be honest it was surprising how much nicer using GPU accelerated terminal was for me.
If you are in a ui enough snappyness is a nice to have for sure.
That said this is an IDE not just a text editor, the automated tools is what sets the apart.
parens@programming.dev
on 27 Feb 2024 08:48
nextcollapse
Looking forward to the memes once this dies
(Zed’s dead)
uid0gid0@lemmy.world
on 27 Feb 2024 11:39
nextcollapse
runs only on MacOS
And
get it into the hands of millions of developers
Seems contradictory
expr@programming.dev
on 27 Feb 2024 17:07
nextcollapse
Yup. Especially since it’s written in Rust… Like why? Rust has a great cross-platform story.
priapus@sh.itjust.works
on 27 Feb 2024 19:11
collapse
they’ve written a custom GPU framework to achieve the performance the level of performance they have. it’s currently only compatible with macos, but is being ported to other operating systems.
SorteKanin@feddit.dk
on 28 Feb 2024 07:41
nextcollapse
Why in the world wouldn’t you just use Vulkan? Then it would still be portable to other platforms with probably still good performance, no?
priapus@sh.itjust.works
on 28 Feb 2024 21:53
collapse
vulkan is a graphics api, not a framework. their framework is using vulkan.
SorteKanin@feddit.dk
on 28 Feb 2024 22:10
nextcollapse
If their framework is using Vulkan, why is it not compatible with anything but MacOS? Isn’t the point of Vulkan that it’s cross platform?
priapus@sh.itjust.works
on 29 Feb 2024 03:18
collapse
It’s not fundamentally incompatible, they just haven’t written the code to make it compatible yet. GPU frameworks need a lot of OS specific code, so it will take some time for them to make it run perfectly on Linux.
davawen@programming.dev
on 29 Feb 2024 20:25
collapse
This is wrong. Their framework uses metal, which is an apple only graphics API.
priapus@sh.itjust.works
on 03 Mar 2024 20:00
collapse
My bad, I was referring to the new Linux implementation which is using Vulkan, which was not clear. The MacOS implementation only supports Metal, as MacOS does not support Vulkan natively. I assume the Vulkan implementation will also be what is used for the Windows build.
AnUnusualRelic@lemmy.world
on 28 Feb 2024 13:20
nextcollapse
I remember when we ran text editors on a turnip. It wasn’t much but we were happy.
expr@programming.dev
on 28 Feb 2024 14:05
collapse
For sure. If 32-year-old vim can handle multi-GB files smoothly, you don’t need a GPU.
priapus@sh.itjust.works
on 27 Feb 2024 19:12
nextcollapse
runs only on MacOS for now
it will be released on both Linux and Windows, with Linux support currently being the top ranking issue on their GitHub page. they have a tracking issue showing that many pr’s have already been merged working towards Linux support.
0nekoneko7@lemmy.world
on 27 Feb 2024 12:39
nextcollapse
I don’t see the need of it.
milicent_bystandr@lemm.ee
on 27 Feb 2024 19:47
nextcollapse
Shout out for Lapce.
I remember reading a bit about this (from Atom) a while back and having iffy feelings… I don’t wish to slander based on vague memories but certainly at the time I hoped Lapce would catch on instead.
It’s still in development, but has a handful of aspects that I really like as the right way to go about things.
Pika@sh.itjust.works
on 28 Feb 2024 04:23
nextcollapse
Honestly even if they had coded this to anything other than MacOS I wouldn’t use it, I’m not too keen on learning a software that’s developed by a team that archived their previous project, given how popular atom was when they decided to archive it it concerns they could just do the same with this one.
zehcnas34@programming.dev
on 28 Feb 2024 07:05
nextcollapse
On the plus side, the fact they stopped Atom development has allowed our community fork of Pulsar to flourish and it has seen loads of active development over the last year. I do find it hard to blame the original team, it was clearly a Microsoft thing to make sure they put all focus on VSCode.
matcha_addict@lemy.lol
on 03 Mar 2024 23:46
collapse
How did Zed get so much publicity? Do they happen to have a lot of funding or something? I’ve seen a million of these posts and I’m just really uninterested, as does a big portion of comments I see.
threaded - newest
Sounds cool! Too bad it’s only on MacOS atm
I’m waiting for it to come on Linux.
.
How would they know a release date if they haven’t finished making it yet?
Great question – would someone ask that of my boss please? 😉
They wrote their own GUI toolkit (oof) and it's hardware accelerated (argh), so OS portability is going to be unusually difficult unless they planned for it from the beginning. No mention of that in the article, so I doubt they did.
They already have very experimental Linux support. You have to build whole app yourself though. I’d say that in month or two we’ll get a binary. You can track Linux porting progress in this issue
Anybody got a nix flake though?
Sounds like gimp with gtk (gimp toolkit) all over again
.
Because GTK is designed for GUI software, and this is a text editor. Almost everything is text - it’s got more in common with Vim than Gedit.
Edit: I’m writing this out of my ass, so don’t quote me.
They wrote that they GPU(I?)-accelerate the font rendering. Well, indeed, fonts are usually rendered with CPUs because it’s slow to use the traditional VRAM (which sits in the GPU) for this task, given that the text itself is stuck in the RAM (sitting right next to the CPU). With integrated chips like the Apple Silicon, it probably makes sense to move the font rendering into the GPU because the memory is unified. GTK is absolutely not designed to do this, AFAIK.
But that also means that, to get this particular benefit of their dedicated GUI framework, you probably have to buy an Apple Silicon Mac. There are PCs with similar architecture, iirc, but that also means that there’s no way you can upgrade your GPU or RAM individually in the future… My fear is that, on a standard PC, it might be just as responsive as other editors.
Didn’t treesitter come from the Atom editor? These guys always take things really far so this isn’t surprising.
Its already possible to build manually on linux and there’s a tracking issue.
*edit. same as the other post
I mean on the one hand, the hardware acceleration is awesome. The GUI toolkit is not of course (I assume MacOS has a default one to make everything look like it belongs?), but at least they made it look like a native app instead of the usual electron shit where it’s clearly a web page with a window border and some design 15y old me might think is cool but 16y old me would already have been ashamed of.
As I understand, GUI toolkits will usually support various widget styles or “Look and Feels”.
So, they can just use a glossy graphic for a button on macOS and a flat graphic on Windows 11, without having to reimplement the whole application in the native toolkit. It will usually not feel entirely native, but at least, it won’t look out of place…
🎉
I’ll be watching this one. It looks nice. Please come to Linux. I do loves me my vim. I did not like setting it up as much as I thought I would to be an IDE. I’m sorry I was mean Zed.
Yes, that was mean, because nobody is able to make another editor as powerful as vim.
Time will tell for sure, but helix is looking really good and once they have support for plugins I’m rather sure it will be a very, very powerful editor.
I don’t think helix will ever catch up to a lot of vims lesser know features of which there are a lot. I think that’s by design as well, I think that helix wants to have a smaller surface area than vim and for a lot of people that will be the right choice. I personaly use ex-commands for example, or the quickfixlist fairly often so for me I have a hard time imagining helix not feeling like a step down power-wise (as nice as multiple cursors are).
VSCode has way more features than Vim. Including the ability to run Vim inside the IDE. Or Emacs.
Sais no-one that knows vim, thou it have a vi-like mode that is missing most advanced vi-trixs.
I was also disappointed not to have ex-commands, but I soon realized Helix’s use of multiple cursors with commands that support regex can accomplish the same tasks in a way I found more intuitive. Definitely took a bit to get rid of my
:%s/new/old/gmuscle memory, but Helix’s select command works very similarly and just as quickly.Quickfix commands on the other hand I never used. It seems Helix has some features such as jumping to diagnostics and errors, but it doesn’t have the ability to do so automatically after running make like Vim does (afaik). I don’t write much C, so I didn’t know that feature existed to begin with.
Multiple cursors are a lot better than
:sfor you standard search and replace, unless you have a really big file at which point helix gets to slow (which isn’t that common) but there are a lot of other stuff you can do with ex commands.I use
:makepretty often, vim ships with the ability to parse a lot of compiler/linter outputs out of the box so if you tell it which one with:compileryou get build errors in the quickfix list. I also use:grepa lot. You can do<space>/to grep in helix but I often find that I want to add command line options to only search in specific directories or for specific file types (we have a large codebase at work). Being able to filter results with:Cfilter, and being able to go back to old quickfix results with:colderis also really nice. Finally, you can use:cdoto apply ex commands to stuff you’ve matched in the quickfix list.As an example, if you get a build error because you’ve renamed a variable in one file but not the places it gets referenced in other files, you can
:maketo get the build errors in you quickfix list,:Cfilterto narrow it down to only that specific class of error if needed and then do:cdo s/oldName/newName/gto rename the variable in all places that cause errors. You can then go back to the list of all errors with:colderand handle other errors in another way if needed.I’ll have to admit that I don’t do this that often so honestly I wouldn’t lose out on that much switching to helix (after it gets proper plugin support and someone makes a decent replacement for the fugitive git plugin) but I would feel less powerful not knowing that I have those tools up my sleave lol.
Those are some neat features. I hadn’t heard of them when I was using Vim. Parsing the compiler output to go straight to the error is very cool. I definitely think plugin support will bring a lot of people to Helix. I don’t currently have any features I’m waiting on, but I’m sure I’ll find some plugins to make it even better once they’re available.
I’ve been trying out Helix as of late. It’s a bit different than vim, but I’m beginning to like it.
Helix’s autocomplete is too bad for me to be able to like it
what do you mean? Helix uses LSP servers, usually the same ones used by Vim and VS Code.
were you using it without the LSP’s installed? If you were, then you would only get completion based of the treesitter grammars, which would be very limited.
no, the autocomplete trigger is rly bad and triggers when moving the cursor around instead of when you actually type It’s a documented problem and they are working on fixing it
Ah I see. I usually only move the cursor when in command mode, so that might be why I haven’t noticed it. That’s unfortunately an issue I’ve noticed in a lot of editors. In fact, because Zed is so fast, the auto completion is super obnoxious atm and constantly flashes at you while you type.
I know it’s the intended way but I’m too much of a modal noob for that, I’m actually working on a non-modal editor for this reason that’s similar to helix and fish philosophies
Nice, been finding vscode more and more laggy after each update, so hopefully this is something to replace it with at some point.
The inevitable cycle of modern open-source text editors. First there was Atom, then that got too slow and most switched to VS Code. Next seems to be Zed… I wonder what comes after it!
Lapce looks pretty cool, for an alpha.
Seems fair tbh. As long as the total usability goes up to that is!
I had the same prob, when I swapped to Codium and paired down my plugins, it was snappy again.
I tried it briefly. It certainly is a lot snappier than Atom ever was, I’ll give it that. Seemed to be pretty good with Python, but when I opened some C++ source, it went around reformatting my indentation and replaces tabs with spaces. I will have to see if there is a way to disable all that, as I found it obnoxious.
If I wrote an IDE and detected tabs I’d just have it delete the codebase
It was more than just tab conversion. For example, it decided on its own that:
if(...) { ... } else { ... }would look better like:
if(...) { ... } else { ... }I mean I guess I could live with that, but really? I imagine there’s some config where you can disable all this, but it just doesn’t seem worth some giant git commit every time I touch a file with the editor.
.
Ah I think I found it. I need to go:
{ "format_on_save": "off" }My guess is that it has that default because they use Rust. Everyone uses rustfmt so everything looks the same and if you always format before a commit you never get massive diffs.
Most rust projects I’ve seen even have a ci job to check the formatting with rustfmt.
It’s strange because how much “powerful” or “high performance” a code editor needs? It’s just , a code esitor you can code in notepad lol
You can code in Notepad in the same way you can eat off the floor with your hands. Using better tools is a nicer experience.
As for performance, when one of the world’s most popular editor runs on Electron, it’s not that hard to see why performance could be an issue when working on large projects on older hardware.
I’ve never personally had an issue with VSCode’s performance, but I’m also fortunate enough to be in a position where I can afford a relatively modern machine. Many others have to make do with what they have, which is why Zed might appeal to them.
Electron has other drawbacks than performance as well.
The big one for me is that my workflow is based on vim, where you split tabs into buffers. There is no way to split a tab into windows in VSCode. Only windows into tabs, which is super dumb and annoying because related files are never shown together unless you click a bunch of tabs. Apparently the reasoning for this insane behavior is “yeah well electron is based on chromium so tough luck we can’t do shit”.
What do you mean by:
Do you mean, drag a tab out of a window to create a new window? Because if so, you can do that in vscode.
No, literally have one tab with multiple windows inside it (the default for vim).
I’m assuming for your example that only one tab is shown at a time?
In that case, you can do that in vscode, the only difference is the semantics of what is considered a “window”, and what is considered a “tab”.
To do this in vscode:
Have one window with four panes, and another window with three panes:
Window 1 ┌──────────┬──────────┐ │ │ │ │ Pane 1 │ Pane 2 │ │ │ │ ├──────────┼──────────┤ │ │ │ │ Pane 3 │ Pane 4 │ │ │ │ └──────────┴──────────┘ Window 2 ┌──────────┬──────────┐ │ │ │ │ Pane 1 │ Pane 2 │ │ │ │ ├──────────┴──────────┤ │ │ │ Pane 3 │ │ │ └─────────────────────┘You can then switch between your windows (or “tabs” in your example) by keyboard shortcut.
In vscode, you can make the Panes different files, or even different views of the same file.
You mean a whole different window at the OS level? That’s just a way inferior hack to the way vim does it by default.
I’ve found an issue from 2017 about it and this related one that focuses more specifically on supporting vim-like behavior. This is just, fundamentally, something that VSCode doesn’t implement simply because of technical limitations. The extensions that attempt to recreate this behavior are apparently all quite janky.
I mean I don’t care, I’m very happy with vim now. But the terribly naive tab support is the reason I left vscode for vim initially. People who have only known “vscode-like” tabs don’t know what they are missing out on.
Yes, that way I could switch between windows in a single shortcut, or even place them side by side so I can see both at the same time with other shortcuts.
Can you explain this more?
Why wouldn’t you want window management to be managed by the window manager?
Sorry, I didn’t log into this account for a while.
Anyways, I guess in an ideal world the window management could be done fully via the window manager. In practice this doesn’t work too well, because that would require a more complex protocol than currently exists. For VSCode for instance, that would require disabling the native tabbing feature (but keeping the native splitting because otherwise I’ll end up with duplicated panes such as the file list) and implementing something custom to translate tab operations to sway-wm operations (in my case).
I guess it could work but it’s not supported OOTB, and after a lot of work is probably going to end up being a lot more clunkier than what I have going on in vim.
I mean, I rock JetBrains for a lot of stuff. It’s a pig on resources, but man does it have a great feature set.
Yeah like Atom or VSCode this is more a half-IDE in concept. Assuming it gets enough support it’s somewhere between a text editor (but will be more sluggish than pure text editors and struggle with very large files but then you ought to have specialized log viewers for that anyways) and an actual IDE (but have only limited IDE features).
Agreed. It’s weird to put the performance of a text editor at the center of PR.
I have sooooo many questions.
Why do they compare a text editor’s performance with that of IDEs??? CLion is possibly the slowest of all Jetbrains IDEs because the C++ language is very complex. Choosing CLion makes even less sense because IntelliJ is now public-testing a lightweight C++ CLion spinoff, which is faster than CLion.
Why should I care whether my editor is written with Rust? C was fine as long as I trust the devs on security. Async doesn’t matter at all to the enduser…
Besides, if I wanted a snappy editor I just use vim.
My fear is that they might have concluded that all the performance boost they made wasn’t important as a text editor, and they are presenting some weird comparison to hide it.
Besides, if you write C++, the bottleneck is not the typing response, but the code analyzer.
It’s also not like C++ is a language used by majority of customers. Why not advertise with JavaScript instead? Python? Those are also better fit for text editors. Because statically typed languages like C++ can benefit hugely from a full-fledged IDEs, taking away the room for this text editor further.
It feels like their AI integration is not outstanding (probably not, indeed).
The collaborative editing might not align well with their emphasis on responsiveness, either, because the network latency will be felt. Not to mention that collaborative editing is pioneered by IntelliJ, also.
Why do you need another channel/chat management tool if your team already has a Slack? Why would your team use a chat platform that can be used only by mac users?
As I indicated in my other comment, it’s possible that the PC port of their GPUI-based GUI can be far slower due to the heave reliance on Apple Silicon. I even doubt a port is possible in the first place, especially if their code heavily relies on Apple-specific APIs for the Silicon.
And all descriptions of their features are suspiciously vague. How are they better than a marketing scheme to raise the stock price?
Maybe it is going to be just an average editor in the era of remote-office (looking at channels and collab edit), ChatGPT-assists (AI-integration) and async. Maybe it’s a proof-of-concept that will soon give ways to another generation of editors.
You can really see the difference between opening VSCode and Zed, even more so if you compare it to something like JB’s Fleet editor.
To be fair, it’s not the easiest to compare right now since Zed is lacking a million features of Code, but if all the work they’ve done keeps it as fast as it is with features like user extensions it will be well worth it.
I usually have ~10 different VS Code windows open at a time (yay microservices ❤️), so having something as fast as Zed would be really appreciated.
I could notice the slowness of Atom when I compared it to VS Code. Sublime is also noticeably faster than VS Code, but the gap doesn’t feel so wide that I want to jump the ship.
I think it depends on the number of characters in the file that make the difference more noticeable.
I’ll be honest it was surprising how much nicer using GPU accelerated terminal was for me.
If you are in a ui enough snappyness is a nice to have for sure.
That said this is an IDE not just a text editor, the automated tools is what sets the apart.
Looking forward to the memes once this dies
(Zed’s dead)
And
Seems contradictory
Yup. Especially since it’s written in Rust… Like why? Rust has a great cross-platform story.
they’ve written a custom GPU framework to achieve the performance the level of performance they have. it’s currently only compatible with macos, but is being ported to other operating systems.
Why in the world wouldn’t you just use Vulkan? Then it would still be portable to other platforms with probably still good performance, no?
vulkan is a graphics api, not a framework. their framework is using vulkan.
If their framework is using Vulkan, why is it not compatible with anything but MacOS? Isn’t the point of Vulkan that it’s cross platform?
It’s not fundamentally incompatible, they just haven’t written the code to make it compatible yet. GPU frameworks need a lot of OS specific code, so it will take some time for them to make it run perfectly on Linux.
This is wrong. Their framework uses metal, which is an apple only graphics API.
My bad, I was referring to the new Linux implementation which is using Vulkan, which was not clear. The MacOS implementation only supports Metal, as MacOS does not support Vulkan natively. I assume the Vulkan implementation will also be what is used for the Windows build.
How much GPU performance do you need for text?
I remember when we ran text editors on a turnip. It wasn’t much but we were happy.
For sure. If 32-year-old vim can handle multi-GB files smoothly, you don’t need a GPU.
runs only on MacOS for now
it will be released on both Linux and Windows, with Linux support currently being the top ranking issue on their GitHub page. they have a tracking issue showing that many pr’s have already been merged working towards Linux support.
I guess if you are committed to supporting a hard to support platform, may as well get it out of the way first?
But yeah, seems like a pretty poor release.
.
I don’t see the need of it.
Shout out for Lapce.
I remember reading a bit about this (from Atom) a while back and having iffy feelings… I don’t wish to slander based on vague memories but certainly at the time I hoped Lapce would catch on instead.
It’s still in development, but has a handful of aspects that I really like as the right way to go about things.
https://lapce.dev/
Honestly even if they had coded this to anything other than MacOS I wouldn’t use it, I’m not too keen on learning a software that’s developed by a team that archived their previous project, given how popular atom was when they decided to archive it it concerns they could just do the same with this one.
I’m assuming it was a MS decision
On the plus side, the fact they stopped Atom development has allowed our community fork of Pulsar to flourish and it has seen loads of active development over the last year. I do find it hard to blame the original team, it was clearly a Microsoft thing to make sure they put all focus on VSCode.
How did Zed get so much publicity? Do they happen to have a lot of funding or something? I’ve seen a million of these posts and I’m just really uninterested, as does a big portion of comments I see.