One of my long-standing "would make if I had the time and perseverance" themes has been a terminal text editor that's hugely VSCode-like + compatible, so always glad to hear anyone going anywhere near that, and hence I perked up from these:
> Prioritizes standard keybindings and a minimal learning curve.
> Extensibility: Uses TypeScript (via Deno) for plugins, making it accessible to a large developer base.
Because where you are now with Fresh, you're probably really not far from supporting say `settings.json`, `launch.json`, `tasks.json`, `keybindings.json`, `.tmTheme`s and theme `.json`s, and indeed bringing up a VSCode-API-implementing "extension host" that can load up and run/host most `.vsix`es. Now, being terminal-based you'd skip over certain feature subsets such as webviews, custom (non-text) editors and the like... and might postpone Notebooks and such fancies initially, but:
Consider! 1000s of high-value, capable, tech-specific dev extensions out there, all readily supported by your just-spawned new editor. Doesn't that sound pretty exciting?
After all, there's a huge subset of VSCode fans who'd always switch in a heartbeat to a just-simply-non-Electron version (whether native or terminal) of the very same feature-scape & extensions & UI dev experience if only it was made and to max compatibility (and MS won't ever do so).
All that's missing (from screenshot glance) is the other sidebars & panels in addition to File Explorer =)
Will be putting your Fresh on my Github Watch list, but then again, I never really read the GH feed anyway.. but maybe I'll remember to check back in every quarter or so =)
I've been mulling over vscode extension compatibility... There is a challenge there, because the API surface is non-trivial and some of it is "web-ish". I wouldn't want people to be disappointed if 60% of the plugins they try to use don't really work properly.
Also, there are nuances like VSCode exposing APIs that force the entire file to be in-memory (which is how VSCode works), this is fine but in my editor I'm trying to get extensions to work well even if the file is huge (encouraging incremental / partial stuff).
But yes, it's a very compelling vision... and part of the reason I chose TypeScript.
Shameless plug: I did a series a couple years back, before AI was this huge, about writing a Vim-like editor in Rust, in case you want to play with it in the future:
I'm a little annoyed that for a Rust based tool the recommended installation command is to use npm. Why? Is Cargo not good enough? Cargo seems exceptionally well to me.
I get the frustration, but I think the npm option actually makes sense here. A lot of users who’d benefit from a fast Rust tool aren’t Rust developers and won’t have Cargo installed. Shipping it through npm lowers the barrier while still giving everyone the performance benefits. It’s not a knock on Cargo, just a way to make the tool more accessible.
Given the fairly shoddy security story with NPM, I genuinely don't understand the hesitation to publish a binary and have a README instruction to curl/wget it into `/usr/local/bin` or `~/.local/bin`. If it's going through NPM that publishing step has to be done already, unless the NPM build is pulling down rust to compile it all as a native extension.
Eventually it'd wangle it's way into homebrew or the unstable branch of another package registry.
But that's me, because I really dislike installing binaries via a language's package manager, because they don't get updated unless I frequently run the upgrade commands for each package manager.
Does it matter? You are apparently contemplating running a third-party binary on your machine anyway. It seems a bit weird to Worry about npm’s security story, which is all about executing arbitrary code.
Thing is… who is regularly running `npm update` or `cargo update` to keep local software up to date?
I wouldn’t, because I might be in a repo and it starts upgrading all my local dependencies, and I’m not gonna add a text editor as a dev dependency. I’ll happily take the binary, or a tar.gz with the binary in it, though.
(Btw I love how it’s following the old DOS aesthetic)
I've been wanting a generic package manager for a while that is cross-platform. I wonder how one could find funding for such a project. Thinking about users from various OS' installing tools and software from your niche package manager, yeah that bad boy is going to grind to a halt if you have no key funding.
I just tested it and I must say congrats. I really enjoy the command palette, the open file menu and the multi cursor. It's well thought, really intuitive so far and I definitively will use it regularly (more once I setup the LSP).
I tried it, I like it a lot, but I did find an issue straight away.
I'm on MacOS and I have remapped the fn and command keys so it can be more like Windows (I can't undo 20+ years of muscle memory, and also I just don't wanna)
Anyway, Fresh seems to ignore the remapping - it's back to the command key for copy/paste and the command palette.
Is there a way to access the dropdown menus by keyboard? I can see F underlined for File but no modifier key seems to make it happen
This is probably not your responsibility. Modifier keys and especially rebinding them are really in the realm of the OS and the Terminal emulator. The application really shouldn't have to do special things to accommodate Mac OS idiosyncrasies.
Installed it and out of the box this is the best new TUI editor I've tried, probably ever. There are so many great editors out there but I've never been a fan of modal editing, despite recognizing it's incredible power. My brain just doesn't work that way, yet I'm highly keyboard focused and prefer terminal over gui for most things, especially text.
Great work on this! Very good performance but also a very good UX and you really nailed the discoverability / accessibility - basically everything works intuitively and needs very little explanation - this is something that I can't say about really any other editor I've tried.
This may finally replace nano as my default utility editor, if not my main IDE.
I built my UX on the shoulders of giants, inspired by WordPerfect 5, Turbo Pascal, and similar legendary heros of the early 90s. Plus a command palette like VSCode.
It’s nice that Claude allows you to make things like this just because you want them to exist, right? Making it by hand would be a multi-month project, but it seems to have taken about 3 weeks?
Completely agree - Claude multiplied my productivity in this case by a factor of 3 at least. It took ~3 weeks "wall clock time" - worked around the clock pretty intensely (got hooked! I love this) so maybe more like 1 month of normal working hours. Would have taken a lot longer than that without Claude Code and I would have given up before reaching this state.
Haven't tried it but I'm pretty sure this editor is going to be very popular very soon.
Because configuring an editor that comes with different plug-in systems in a third programming language is a lot of hassle for people who are too focused at getting the job done and don't want to be distracted with a whole another configuration framework in yet another programming language.
I had given up hope on ever finding an editor like this. Just did a little bit of browsing in a current project and WOW. Going to use this for the rest of the day and kick the tires. Well done!
It loads instantly, and memory usage is minimal <80 MB.
It does seem like vlf requires configuration and adjustment, e.g. navigation with the normal keys works differently (jumps to beginning/end of current chunk instead of the whole file). Basically it exposes the chunk concept to the user.
In Fresh it's designed into the core and should be more transparent (although there are still limitations).
I need to think about that still, you raise a good point. I'd like people to be able to use parts of the source pretty much freely, but I wouldn't want someone to replicate the entire editor as a proprietary closed-source product.
> Efficiency: Uses a lazy-loading piece tree to avoid loading huge files into RAM
I once started writing a text editor on Linux, and first went down a similar route: a piece table over a mmap()'d file. But I abandoned using mmap, because Linux file systems typically don't have mandatory locking enabled, so you can't be sure that the file data won't be modified by another program.
(Then I got bogged down in Unicode handling... so 95% of the code became just about that, and I tired of it)
I hate to be that guy, but did you know about Fresh, Deno's official frontend framework ? [1] If your app wasn't using Deno for extensibility it wouldn't be such a problem but since it is, I think it's gonna make searching for both harder.
Sublime, Atom, VSCode, and now Zed are all GUI-based. That's not bad - but I prefer the terminal (and I find tmux + ssh very convenient). I guess it's a matter of personal taste.
For terminal based, there are also many options but not so much in the direction of "VSCode style". They're mostly focused on being "vi-style". And also the huge file support isn't as good in any of the others that I've tried.
Language server protocol is a huge deal! Without it, I think we'd still see a lot more JetBrains style language bespoke IDE use and a lot less VSCode style text editor + plugin combos.
Since the original post was about a TUI editor, its worth mentioning Helix which supports most modern language out the box. That's amazing and wouldn't have been possible 10 years ago.
Thanks for this cool project ! I was desperate to find more modern terminal editors with CUA mode. There is micro which is already good, but I wanted something more and hope your editor will fill that space.
Which terminal are you using? (I'm not a MacOS user so less familiar). That's a shame, but I guess the only fix is for you to change the terminal shortcuts because the in-terminal programs will just not receive those key events.
Or maybe try using a single tab in your terminal, maybe that will let the key pass through?
Anyway I need to add keybinding UX or maybe a different default set of keys for MacOS? hmm.
"Bun is a new JavaScript runtime built from scratch to serve the modern JavaScript ecosystem. It has three major design goals:
Speed. Bun starts fast and runs fast. It extends JavaScriptCore, the performance-minded JS engine built for Safari. Fast start times mean fast apps and fast APIs.
Elegant APIs. Bun provides a minimal set of highly-optimized APIs for performing common tasks, like starting an HTTP server and writing files.
Cohesive DX. Bun is a complete toolkit for building JavaScript apps, including a package manager, test runner, and bundler.
Bun is designed as a drop-in replacement for Node.js. It natively implements thousands of Node.js and Web APIs, including fs, path, Buffer and more."
- From the homepage[1] - it's a shame they use semantic html but no anchors for direct linking.
"Bun itself is MIT-licensed.
JavaScriptCore
Bun statically links JavaScriptCore (and WebKit) which is LGPL-2 licensed. WebCore files from WebKit are also licensed under LGPL2."
License compatible, probably safe from a rug pull?
One of my long-standing "would make if I had the time and perseverance" themes has been a terminal text editor that's hugely VSCode-like + compatible, so always glad to hear anyone going anywhere near that, and hence I perked up from these:
> Prioritizes standard keybindings and a minimal learning curve.
> Extensibility: Uses TypeScript (via Deno) for plugins, making it accessible to a large developer base.
Because where you are now with Fresh, you're probably really not far from supporting say `settings.json`, `launch.json`, `tasks.json`, `keybindings.json`, `.tmTheme`s and theme `.json`s, and indeed bringing up a VSCode-API-implementing "extension host" that can load up and run/host most `.vsix`es. Now, being terminal-based you'd skip over certain feature subsets such as webviews, custom (non-text) editors and the like... and might postpone Notebooks and such fancies initially, but:
Consider! 1000s of high-value, capable, tech-specific dev extensions out there, all readily supported by your just-spawned new editor. Doesn't that sound pretty exciting?
After all, there's a huge subset of VSCode fans who'd always switch in a heartbeat to a just-simply-non-Electron version (whether native or terminal) of the very same feature-scape & extensions & UI dev experience if only it was made and to max compatibility (and MS won't ever do so).
All that's missing (from screenshot glance) is the other sidebars & panels in addition to File Explorer =)
Will be putting your Fresh on my Github Watch list, but then again, I never really read the GH feed anyway.. but maybe I'll remember to check back in every quarter or so =)
Also, there are nuances like VSCode exposing APIs that force the entire file to be in-memory (which is how VSCode works), this is fine but in my editor I'm trying to get extensions to work well even if the file is huge (encouraging incremental / partial stuff).
But yes, it's a very compelling vision... and part of the reason I chose TypeScript.
Thanks for the input :)
https://www.youtube.com/playlist?list=PL9KpW-9Hl_het1V3_dLhG...
Eventually it'd wangle it's way into homebrew or the unstable branch of another package registry.
But that's me, because I really dislike installing binaries via a language's package manager, because they don't get updated unless I frequently run the upgrade commands for each package manager.
The other thing it gives you is the ability to easily upgrade and uninstall so just a script to copy stuff is not on par.
I wouldn’t, because I might be in a repo and it starts upgrading all my local dependencies, and I’m not gonna add a text editor as a dev dependency. I’ll happily take the binary, or a tar.gz with the binary in it, though.
(Btw I love how it’s following the old DOS aesthetic)
Keep up the good work !
I'm on MacOS and I have remapped the fn and command keys so it can be more like Windows (I can't undo 20+ years of muscle memory, and also I just don't wanna)
Anyway, Fresh seems to ignore the remapping - it's back to the command key for copy/paste and the command palette.
Is there a way to access the dropdown menus by keyboard? I can see F underlined for File but no modifier key seems to make it happen
Also I'm already working on a ui for customizing the key bindings so you could do whatever you wanted. (Currently managed by undocumented json)
Thanks for reporting!
Great work on this! Very good performance but also a very good UX and you really nailed the discoverability / accessibility - basically everything works intuitively and needs very little explanation - this is something that I can't say about really any other editor I've tried.
This may finally replace nano as my default utility editor, if not my main IDE.
Thank you :)
Because configuring an editor that comes with different plug-in systems in a third programming language is a lot of hassle for people who are too focused at getting the job done and don't want to be distracted with a whole another configuration framework in yet another programming language.
Now try opening it in Emacs with vlf [1] ;) Great work overall — looking forward to seeing further development!
[1] https://elpa.gnu.org/packages/vlf.html
It loads instantly, and memory usage is minimal <80 MB.
It does seem like vlf requires configuration and adjustment, e.g. navigation with the normal keys works differently (jumps to beginning/end of current chunk instead of the whole file). Basically it exposes the chunk concept to the user.
In Fresh it's designed into the core and should be more transparent (although there are still limitations).
What are the reasons behind going with GPL-2 instead of a more permissive license like MIT or 0BSD?
You will probably at minimum build some neat helper functions and maximum code reuse is IMHO the best thing for the world.
I would for instance be curious on the ANSI routines but hesitate to invest mental energy when the code has limitations on usage.
Lastly cool to see new open source programs being built with heavy help from a code generation model. Inspiring!
I once started writing a text editor on Linux, and first went down a similar route: a piece table over a mmap()'d file. But I abandoned using mmap, because Linux file systems typically don't have mandatory locking enabled, so you can't be sure that the file data won't be modified by another program.
(Then I got bogged down in Unicode handling... so 95% of the code became just about that, and I tired of it)
So I opted for explicit management of chunks, also gives me more control and consistent cross platform behavior.
[1] https://fresh.deno.dev/
I feel like sublime text got most of it right and every editor since then has been a reskin of the same (just written in a different stack)
For terminal based, there are also many options but not so much in the direction of "VSCode style". They're mostly focused on being "vi-style". And also the huge file support isn't as good in any of the others that I've tried.
Since the original post was about a TUI editor, its worth mentioning Helix which supports most modern language out the box. That's amazing and wouldn't have been possible 10 years ago.
I don't have a particular reason. Maybe I should switch.
I was settled on NVim and VSCode, then I discovered Zed, which is fantastic.
I guess you should not keep your life closed for new experiences. Everybody loves fast and responsive software, what can I say.
Thank you for your work, I will enjoy using it, it isn't for everything but that is how I started with Zed.
Or maybe try using a single tab in your terminal, maybe that will let the key pass through?
Anyway I need to add keybinding UX or maybe a different default set of keys for MacOS? hmm.
Modern developers have lost their mind
For extensions, the choice was either TypeScript (and get this bloat) or go with Lua and a much smaller binary (but less popular language).
But - I just realized stripping it brings it down to 76MB so I guess that's ok! Will push a commit :)
- From the homepage[1] - it's a shame they use semantic html but no anchors for direct linking.
1. https://bun.com/
License compatible, probably safe from a rug pull?