> What I need is an emacs with more lisp and less javascript
Lem[0] in ncurses mode might be your friend. Unfortunately the BDFL deprecated the SDL frontend seemingly due to the SDL3 breakages, but the web one uses webview + a homegrown system instead of electron and framework magic, so it's still fairly lightweight
its main proposition is that the whole thing is written in Common Lisp, so it retains the hackable model of traditional Emacses without retaining the legacy of GNU Emacs
A lot of people use VSCode. Zed's value proposition is being basically that but with fully native code, so without the madness that is Electron. If you're not a fan of this kind of tooling, it's totally fine, but many people see the value in having an extensible graphical code editor
My tone probably came off as antagonistic and that was not my intention. I was interested in if anyone was using the high fidelity graphical features for something other then making the environment prettier.
I am always interested in what features new editors and how people use them and such and if I am missing out.
As far as I can tell, no. I moved to zed from nvim for fast starts + better AI UX with edit prediction & agents than nvim without start time/RAM of cursor. It delivered on that, but now that I think about it my coding practices have changed so much since that decision (sitting in Claude / https://www.conductor.build) I should probably just go back to nvim!
From this perspective - not sure, to be honest. For me an important factor was that Zed is getting way more love from its devs than my old editor of choice Helix. But also not being constrained to a cell grid is very nice in terms of readability to me.
One thing that Zed doesn't solve but likely will is that I found "jump to label" style of features (I think flash.nvim is the closest for neovim?) is almost unreadable to me with inlined labels, but that's so highly specific I'm almost willing to live with it
Zed us, in fact, fully native. It's top-to-bottom Rust, which gives them C++ equivalent speeds or better compiles to native code and lets them much more easily make use of multi-threading parallelism than basically any other language that compiles to a static binary. They also use a custom GUI framework built from the graphics driver's up to be maximally efficient, performance smooth and low latency; that's literally the subject of this thread!
The only reason it would be spawning Node.js processes is if it's running a javaScript/typescript language server for you, but that's not a property of Zed itself, it's something any other editor would do (including VS Code). Also, the resident memory of Zed, even with multiple entire projects with hundreds of tabs open, running several language servers and multiple terminals and AI agents for me never exceeds about 900 megabytes, which is significantly less than VS Code uses even at startup.
Whatever it was that you ran into, it's likely some kind of fluke or platform-specific bug.
I believe latest Iced versions do have a `Lazy` widget wrapper, but I believe that effectively means you need to make your own virtual list on top of it
Custom widgets aren’t particularly hard to do in iced, but I wish some of those common cases would be committed back / made available.
Except the above virtualised lists, another case I hit was layered images (sprites for example). Not very hard to write my own, sure, but it’d be nice to have that out of the box as in eg. egui
After using projects named like "slurp", "eww" (combined with "yuck"), "yay", "honkers railway", "jason" and many many others, I personally kind of gave up on any attempts to judge projects by their titles. Partly due to many developers being whimsical nerds, partly because even marketable names say nothing about the product half the time so what's the point anyway
A funny workaround I employed is running Beeper. It's a Matrix client that also provides chat mirroring for other platforms. The sync is slightly jank but it works for what I want to achieve
The mirroring stuff is FOSS and I think so is the client, the financial model being that you're limited to a fairly low amount of services proxies at once without a paid plan
osu! is probably the longest running financially successful game with a fully FOSS modern core (though a proprietary legacy core). And there are many other smaller projects that have seen plenty of success. There are also a lot of mods that run as FOSS projects on top of proprietary games. So yeah, there are some projects to look into
Rust has 3 "platform support" tiers (effectively - guaranteed to work, guaranteed to build, supposed to work). However, these are (obviously) defined only for some of the target triples. This project defines "Tier-4" (which is normally not a thing) unstable support for Windows Vista-and-prior
If you count Rc/Arc as garbage collection you should count RAII + The Borrow Checker (i.e. all safe rust) as garbage collection too IMHO. It collects garbage just as automatically - it just does so extremely efficiently.
That said I tend to count neither. Garbage collection to me suggests you have something going around collecting it, not just you detect you're done with something when you're done with it and deal with it yourself.
I still wouldn't call it GC in that case. It's pretty much exactly the same as std::shared_ptr in C++, and we don't usually call that GC. I don't know about the academic definition, but I draw the line at a cycle collector. (So e.g. Python is GC'd, but Rust/C++/Swift are not.)
I consider reference to be garbage collection, and so do most CS textbooks. However Rc/Arc/shared_ptr are GC facilities used (often sparingly) inside predominantly non-GC'd languages, so, yeah, I wouldn't say Rust "is" or "has" GC. It has facilities for coping with cleanup, both RAII and GC.
In one of the interviews that came out when the Steam Machine embargo ended, someone from Valve said that, unlike with Steam Deck, they can't afford to sell at a loss because the form factor and the OS of the Machine make it possible to buy it just for general compute, which would be devastating with negative margins. So, unfortunately, I guess it will be 800-1000$ in the end
That is still cheaper than the index when it came out, and it sounds like a general improvement in all areas. Flagship vr for less than the cost of the latest smartphone seems pretty reasonable given how low adoption is.
It's not exactly what you're looking for but you might be interested in Lem[0]. It's an emacs-style editor but written completely in Common Lisp on top of curses/SDL2. I haven't used it that much (same for Emacs itself, really), but it looks like a very solid foundation
Does look interesting, in the meantime I've been hooked on Zed which has users building support for missing Vim features, they claim their goal isn't to 100% emulate Vim functionality, but I would not be shocked if it just winds up having most if not everything most people like about Vim fully baked in.
Lem[0] in ncurses mode might be your friend. Unfortunately the BDFL deprecated the SDL frontend seemingly due to the SDL3 breakages, but the web one uses webview + a homegrown system instead of electron and framework magic, so it's still fairly lightweight
its main proposition is that the whole thing is written in Common Lisp, so it retains the hackable model of traditional Emacses without retaining the legacy of GNU Emacs
[0] https://lem-project.github.io/
reply