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.
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).
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.
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.
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
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.
> 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.
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.
Goood stuff!
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.
Thanks for the input :)
Looking forward to giving this a try, especially on my first gen Raspberry Pi! :)
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!
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:
https://www.youtube.com/playlist?list=PL9KpW-9Hl_het1V3_dLhG...
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.
That (security ) is something I also worry about. I'd like to get off npm if only for this reason. It's a hack to get started.
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.
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)
The npm distribution here is just the binary, you run npm install again and it upgrades to the latest binary. That's convenient
I did it because not everybody has cargo installed. I'm using cargo-dist to create this npm package.
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.
Artifactory exists. It's not hard to store packages and metadata somewhere.
Is there a way to install it with cargo instead? I won't install npm on my machine just to install a Rust package
Sure, cargo install fresh-editor
consider wget or curl if possible (why not if npm was...)
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).
Keep up the good work !
Thanks and if you encounter any issues (even minor annoyances) let me know (e.g. open a github issue), I want the experience to be smooth
I love a new editor as much as the next guy but has there been any real new/novel features in text editors over last 10 years?
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)
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.
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.
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
I'll need to look into this, not sure what remapping does to the incoming key events.
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!
> I did a quick benchmark loading a 2GB log file with ANSI color codes... Emacs: Load Time: ~10 seconds | Memory: ~2 GB
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
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.
> 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 considered using mmap to help manage the caching but what if your file is hosted on S3 or whatever? (Something I'm planning to support eventually)
So I opted for explicit management of chunks, also gives me more control and consistent cross platform behavior.
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.
[1] https://fresh.deno.dev/
Interesting license choice, would why did you choose version 2 instead of 3?
Honestly it reflects on my, uh, experience - I still think of GPLv3 as a "new" license.
I don't have a particular reason. Maybe I should switch.
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.
The look reminds me of Turbo Pascal. Without the bright blue color.
Check out the nostalgia theme, built in: https://raw.githubusercontent.com/sinelaw/fresh/refs/heads/m...
I took a look--it seems like you can pass a path on the command-line to open to. Can you pass a line number, also?
No, but that's a good idea, I'll add that
Also--cool editor!
selection is broken on mac eg cntrl+shift+right switches terminal tabs
love me a new text editor, here for this!
400mb executable for a terminal text editor?
Modern developers have lost their mind
Is it 400mb? Could be V8 for plugins.
Thanks for reminding me. Unfortunately yes, it's because of v8 (for Deno).
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 :)
Great! Just wondering maybe Bun (different JS engine) could do the job for plugins.
Anthropic Bun? :) I didn't realize it was an engine as well. I can take a look but we should wait and see where the acquisition takes it