This is just a "because I wanted to" project. And I get that; done a lot of those myself just to understand what the hell was going on. But the rewrite of turbo vision into FPC and compiling to half a dozen targets has been around for 20 years. Turbo vision is probably the best text mode windowing library in existence. The cool fun kicks in when you can map a whole text screen to an array like so:
var
Screen: Array[1..80,1..25] Of Byte Absolute $B800; // or something like that as i recall
What turbo vision brought to the game was movable, (non) modal windows. Basically a lot of rewriting that array in a loop. Pretty snappy. I made a shitload of money with that library.
dleslie · 3h ago
For those curious, here is a modern port of the C++ Turbo Vision that also supports Unicode:
I am curious about how you made money with it, if you don't mind sharing.
jksmith · 4h ago
My first company out of uni was a company that sold a tv advertising application written in dos. It did all the reports, put together spot advert packages, measuring reach and frequency, cost per point, etc. Used Neilsen ratings for data. The company at the time paid commissions along with salary to programmers. The app still lives on in windows, but I've been out of that game for decades. Written in TP for dos, then Delphi for windows.
TheAmazingRace · 3h ago
Honestly dude, this is clever. Good on you for finding an opportunity to make a useful tool and you made out like a bandit in the process. :)
jksmith · 3h ago
That was the toolchain that my company used. Turbo vision was a Borland product, back when Philippe Khan was running the company. We were that ahead of the curve for "shrinkwrapped software development" at the time. That legacy, Delphi and FPC still maintain the standard for desktop, native dev, really for the last 30 years.
`edit` doesn't even support syntax highlighting (atleast, out of the box when I tried it).
Litruv · 2h ago
I think you missed the point of edit.
bapak · 35m ago
I think not. Edit is to edit files in the terminal. What kind of files do you expect people to edit in the terminal? Most certainly files that would benefit from colors, not prose.
anyfoo · 5h ago
Fun. I must admit I don't really know who this is for, but it seems fun.
tim-- · 4h ago
It's for people that want to use the Windows Terminal to edit files. The old `edit` command has been unsupported on Windows since 2006, so there was no Microsoft-provided editor that could be used in the command line since then.
> By writing SIMD routines specific to newline seeking, we can bump
that up [to 125GB/s]
_verandaguy · 4h ago
Is... this a meaningful benchmark?
Who's editing files big enough to benefit from 120GBps throughput in any meaningful way on the regular using an interactive editor rather than just pushing it through a script/tool/throwing it into ETL depending on the size and nature of the data?
magicalhippo · 3h ago
At work we have to modify some 500 MB XML's every now and then, as the source messes them up in non-repeating ways occasionally.
Typically we just hand edit them. Actually been pleasantly surprised at how well VS Code handles it, very snappy.
WD-42 · 4h ago
Who cares? It’s fun. Programming can be fun.
anyfoo · 4h ago
To turn this around, you can have fun and ask if something is meaningful or not outside the fun at the same time. If it is, great. If it's not, no harm.
_verandaguy · 4h ago
I'm not saying that doing this can't be fun, or even good to learn off of, but when it's touted as a feature or a spec, I do have to ask if it's a legitimate point.
If you build the world's widest bike, that's cool, and I'm happy you had fun doing it, but it's probably not the most useful optimization goal for a bike.
WD-42 · 2h ago
Not a great analogy. This editor is really fast. Speed is important, to a point. But having more of it isn't going to hurt anything. It is super fun to write fast code though.
tim-- · 4h ago
As a specific benchmark, no. But that wasn't the point of linking to the PR. Although the command looks like a basic editor, it is surprisingly featureful.
Fuzzy search, regular expression find & replace.
I wonder how much work is going to continue going into the new command? Will it get syntax highlighting (someone has already forked it and added Python syntax highlighting: https://github.com/gurneesh9/scriptly) and language server support? :)
_verandaguy · 4h ago
Right, these are more useful features, IMO, than the ability to rip through 125GB of data every second. I can live without that, but syntax highlighting's a critical feature, and for some languages LSP support is a really big nice-to-have. I think both of those are, in this day and age, really legitimate first-class/built-in features. So are fuzzy searching and PCRE find&replace.
Add on a well-built plugin API, and this will be nominally competitive with the likes of vim and emacs.
tiagod · 3h ago
I have to scroll through huge files quite frequently, and that's the reason I have Sublime Text installed, as it deals with them very well.
anyfoo · 4h ago
Not on the regular, but there are definitely times I load positively gigantic files in emacs for various reasons. In those times, emacs asks me if I want to enable "literal" mode. Don't think I'd do it in EDIT, though.
tomrod · 4h ago
Challenge. Accepted.
cerved · 45m ago
Probably more like need to use it. Basically nano for windows
DrJokepu · 5h ago
It’s right there in the readme actually:
> The goal is to provide an accessible editor that even users largely unfamiliar with terminals can easily use.
scblock · 5h ago
That may be the written goal, but I doubt that's the actual reason the project exists.
cosignal · 4h ago
Yeah ... I don't think there's any overlap between "users largely unfamiliar with terminals" who want something easy to use, and 'Linux users who are sufficiently technical that they would even hear about this repo'.
zamadatix · 4h ago
The title is a bit confusing depending how you read it. Edit isn't "for" Linux any more than PowerShell was made for Linux to displace bash, zsh, fish, and so on. Both are just also available with binaries "for" Linux.
The previous HN posts which linked to the blog post explaining the tool's background and reason for existing on Windows cover it all a lot better than a random title pointing to the repo.
paulfharrison · 3h ago
Here's a scenario. You're running a cluster, and your users are biologists producing large datasets. They need to run some very specific command line software to assemble genomes. They need to edit SLURM scripts over SSH. This is all far outside their comfort zone. You need to point them at a text editor, which one do you choose?
I've met biologists who enjoy the challenge of vim, but they are rare. nano does the job, but it's fugly. micro is a bit better, and my current recommendation. They are not perfect experiences out of the box. If Microsoft can make that out of the box experience better, something they are very good at, then more power to them. If you don't like Microsoft, make something similar.
hulitu · 34m ago
> You need to point them at a text editor, which one do you choose?
mcedit ?
rtpg · 3h ago
I dunno, I spent a lot of years (in high school at least) using Linux but being pretty overwhelmed by using something like vim (and having nobody around to point me to nano).
EDIT.COM, on the other hand... nice and straightforward in my book
kevin_thibedeau · 4h ago
There's no shortage of less technical people using nano for editing on Linux servers. Something even more approachable than that would have a user base.
mikepurvis · 56m ago
Especially noting it's a single binary that's just 222kb on x86_64— that's an excellent candidate to become an "installed by default" thing on base systems. Vim and emacs are both far too large for that, and even vim-tiny is 1.3MB, while being considerably more hostile to a non-technical user than even vim is.
I can definitely see msedit having a useful place.
hulitu · 32m ago
Midnight commander comes with mcedit.
cAtte_ · 4h ago
well the editor was obviously designed primarily for Windows, not sure why the title says Linux
justsomehnguy · 4h ago
My guess would be there are some people at MS who, somehow, still can do something fun. Because they are not assigned on the another project on how to make OOBE even more miserable.
/rant Today I spent 3 (three) hours trying to setup a new MSI AIO with Windows Pro. Because even though it's would be joined to the local ADDS and managed from there - I need to join some Internet connected network, setup a 3 stupid recovery questions which would make NIST blush and wait another 30 minutes for a forced update download which I cannot skip. Oh, something went wrong - let's repeat the process 3 times.
xeonmc · 4h ago
Perhaps those are the things that doesn’t take a Ph.D to develop.
Gormo · 4h ago
There are already plenty of those, such as jed, mcedit, etc.
This particular application is incredibly basic -- much more limited than even EDIT for DOS.
cool_beanz · 4h ago
Nano gang
z3ratul163071 · 1h ago
this is for me, as saner replacement for nano in the terminal, since i hate vi.
iknowstuff · 4h ago
I’ll gladly replace vim with it, especially if it has/gets LSP support or searching via ripgrep. I’m using Helix now but like a good tui.
kgwxd · 3h ago
It's a huge improvement over notepad
pcunite · 2h ago
Back in 1993, I would open up binary files in edit and enjoy seeing hearts.
samplatt · 50m ago
That, the DOS defrag visualisation, and the hex-editing my own savegames is pretty much why I'm a developer today.
LAC-Tech · 4h ago
Needs LSP and Tree-Sitter :)
z3ratul163071 · 1h ago
and scripting :)
1vuio0pswjnm7 · 1h ago
No musl binary. For glibc Linux distributions only perhaps.
90s_dev · 3h ago
I don't understand why they want to go with DLLs for scripting instead of WASM + wamr which is really small. Maybe I'm just really inexperienced in this space.
vunderba · 3h ago
The possibility of using WASM was at least under discussion last month:
It already works? There just isn't an official build yet - just `cargo run` yourself.
xyst · 2h ago
It will take more than nostalgia and rust to tear me away from my neovim setup that has been built up/improved on over the years. Lsp, dap, autocompletion, aliases and bindings for each programming languages. Lazily loaded of course so it’s still snappy.
Manage configuration, and external dependencies such as lsps with nix.
Then have separate nix shells for each project to load tooling and other dependencies in an isolated/repeatable session. Add in direnv to make it more seamless development experience.
watusername · 2h ago
You are not the target audience. This is aimed at casual users and beginners, and it's already in a good shape to replace nano with its user-friendly, mouse-enabled TUI.
kgwxd · 3h ago
Runs on Windows too! It has "Redo", not to be confused with "Undo Undo". Unfixed-width Tabs are a huge leap forward. LF, sans CR, will cut your file sizes in half.
ocdtrekkie · 4h ago
It'd be nice if they didn't recommend winget for installation though. winget is an egregious security risk that Microsoft has just like pretended follows even minimal security practices, despite just launching four years ago with no protection from bad actors whatsoever and then never implementing any improvements since.
easton · 4h ago
disclaimer: I used to commit to winget a lot and now I don’t.
…but is it really less secure than brew or choco? The installers are coming from reasonably trusted sources and are scanned for malware by MS, a community contributor has to approve the manifest changes, and the manifests themselves can’t contain arbitrary code outside of the linked executable. Feels about as good as you can get without requiring the ISVs themselves to maintain repos.
ocdtrekkie · 3h ago
The installers are coming from random people on the Internet. Most software repositories have trusted contributors and a policy of requiring a piece of software be arguably worthy of inclusion. Perhaps because Microsoft is afraid to pick winners, every piece of garbage is allowed on winget, and there's no way to restrict who can make changes to what packages.
There are ISVs that would like to lock down their software so they can maintain it but a trillion dollar company couldn't spare a dollar to figure out a "business process" to do this. As far as I know, Microsoft has a single employee involved who has laughed off any security concerns with "well the automated malware scanner would find it".
The "community contributors" were just... people active on GitHub when they launched it. Was anyone vetted in any way? No.
The Microsoft Store has actual app reviewers, winget has... "eh, lgtm".
90s_dev · 3h ago
The policy of including the author's name next to the project name, along with some indication that it really is the author and not an imposter, I think that's probably the best we're ever going to get, since at that point it just comes down to community trust.
dale_huevo · 2h ago
winget is just Windows developers' version of curl | bash. Yet another example of Microsoft copying Linux features.
ocdtrekkie · 2h ago
Except curl | bash definitely executes code by the author controlling the URL you put in, and if the URL is HTTPS, in a reasonably secure fashion.
There is no validation when you winget whether or not the executable is from the official source or that a third party contributor didn't tamper with how it's maintained.
There is 0 validation that the script that you are piping into bash is the script that you expect. Even just validating the command by copying and pasting the URL in a browser -- or using curl and piping into more/less is not enough to protect you.
bee_rider · 1h ago
>> Except curl | bash definitely executes code by the author controlling the URL you put in, and if the URL is HTTPS, in a reasonably secure fashion.
> It's trivial for a remote server to hand two different versions of a script with the traditional `curl | bash` pipeline.
I’m confused by this; it seems to be written in the tone of a correction but you both seem to be saying that you get whatever the server sends. (?)
tim-- · 39m ago
> you both seem to be saying that you get whatever the server sends
Yes, but I am also saying that you can't verify that the script that is run on one machine with a pipe is the same script that runs on a second machine with a pipe.
The key part of the original statement is the server can choose to send different scripts based on different factors. A curl&bash script on machine 1 does not necessarily mean the same curl&bash script will be run on machine 2.
The tooling provided by a `curl | bash` pipeline provides no security at all.
With winget, there is at least tooling to be able to see that the same file (with the same hash) will be downloaded and installed.
There are ways to do this better, for example, check out https://hashbang.sh. It includes a GPG signature that is verified against the install script, before it is passed to curl.
ToValueFunfetti · 2h ago
The parent is talking about MITM, which is prevented with TLS and curl but not winget. They are saying curl is strictly better, not that it is impenetrable. If you trust the domain owner, you can trust curl | bash, but you can't trust winget
It's easy enough to view the manifests (eg, https://github.com/microsoft/winget-pkgs/blob/2ecf2187ea0bf1...) and arguably, is better then the protection for MITM that you would get using naked cURL & Bash, simply because there are file hashes for all of the installer files provided by a third party.
> They are saying curl is strictly better, not that it is impenetrable
Right. But it arguably is not strictly better.
> You can't trust winget
Again, this is not backed up by anything. I have trust in winget. I can trust that the manifest has at least been vetted by a human, and that the application that will be installed should be the one that I requested. I can not trust that this will happen with curl | bash. If the application that is installed is not the one that I requested, there is tooling a process to sort out why that did not happen, and a way to flag it so that it doesn't happen to other users. I don't have this with curl | bash.
dale_huevo · 2h ago
If you think HTTPS is performing code validation I have news for you.
HTTPS only guarantees the packets containing the unverified malicious code are not tampered with from the server to you. A server which could very well be compromised and alternate code put in its place.
You are drawing an egregious apples-to-oranges comparison here. Please re-read what you said.
You could serve digitally signed code over plain HTTP and it would be more secure than your example over HTTPS. Unfortunately there are a lot of HTTPS old wives' tales that many misinformed developers believe in.
dgfitz · 2h ago
curl | bash is absolutely on my very short list of “things I’ll never do” and I wince when I see it. rm -rf starting from / is another. I watched someone type in (as root) “rm -rf / home/user/folder” once. By the time I realized what had happened it was too late.
What turbo vision brought to the game was movable, (non) modal windows. Basically a lot of rewriting that array in a loop. Pretty snappy. I made a shitload of money with that library.
https://github.com/magiblot/tvision
So good.
1. By the author - https://news.ycombinator.com/item?id=44034961 2. Ubuntu Publication - https://news.ycombinator.com/item?id=44306892
And this post.
--
1: https://micro-editor.github.io/
`edit` doesn't even support syntax highlighting (atleast, out of the box when I tried it).
It's impressive to see how fast this editor is. https://github.com/microsoft/edit/pull/408
> By writing SIMD routines specific to newline seeking, we can bump that up [to 125GB/s]
Who's editing files big enough to benefit from 120GBps throughput in any meaningful way on the regular using an interactive editor rather than just pushing it through a script/tool/throwing it into ETL depending on the size and nature of the data?
Typically we just hand edit them. Actually been pleasantly surprised at how well VS Code handles it, very snappy.
If you build the world's widest bike, that's cool, and I'm happy you had fun doing it, but it's probably not the most useful optimization goal for a bike.
Fuzzy search, regular expression find & replace.
I wonder how much work is going to continue going into the new command? Will it get syntax highlighting (someone has already forked it and added Python syntax highlighting: https://github.com/gurneesh9/scriptly) and language server support? :)
Add on a well-built plugin API, and this will be nominally competitive with the likes of vim and emacs.
> The goal is to provide an accessible editor that even users largely unfamiliar with terminals can easily use.
The previous HN posts which linked to the blog post explaining the tool's background and reason for existing on Windows cover it all a lot better than a random title pointing to the repo.
I've met biologists who enjoy the challenge of vim, but they are rare. nano does the job, but it's fugly. micro is a bit better, and my current recommendation. They are not perfect experiences out of the box. If Microsoft can make that out of the box experience better, something they are very good at, then more power to them. If you don't like Microsoft, make something similar.
mcedit ?
EDIT.COM, on the other hand... nice and straightforward in my book
I can definitely see msedit having a useful place.
/rant Today I spent 3 (three) hours trying to setup a new MSI AIO with Windows Pro. Because even though it's would be joined to the local ADDS and managed from there - I need to join some Internet connected network, setup a 3 stupid recovery questions which would make NIST blush and wait another 30 minutes for a forced update download which I cannot skip. Oh, something went wrong - let's repeat the process 3 times.
This particular application is incredibly basic -- much more limited than even EDIT for DOS.
https://github.com/microsoft/edit/issues/17
Manage configuration, and external dependencies such as lsps with nix.
Then have separate nix shells for each project to load tooling and other dependencies in an isolated/repeatable session. Add in direnv to make it more seamless development experience.
…but is it really less secure than brew or choco? The installers are coming from reasonably trusted sources and are scanned for malware by MS, a community contributor has to approve the manifest changes, and the manifests themselves can’t contain arbitrary code outside of the linked executable. Feels about as good as you can get without requiring the ISVs themselves to maintain repos.
There are ISVs that would like to lock down their software so they can maintain it but a trillion dollar company couldn't spare a dollar to figure out a "business process" to do this. As far as I know, Microsoft has a single employee involved who has laughed off any security concerns with "well the automated malware scanner would find it".
The "community contributors" were just... people active on GitHub when they launched it. Was anyone vetted in any way? No.
The Microsoft Store has actual app reviewers, winget has... "eh, lgtm".
There is no validation when you winget whether or not the executable is from the official source or that a third party contributor didn't tamper with how it's maintained.
It's trivial for a remote server to hand two different versions of a script with the traditional `curl | bash` pipeline. https://lukespademan.com/blog/the-dangers-of-curlbash/
There is 0 validation that the script that you are piping into bash is the script that you expect. Even just validating the command by copying and pasting the URL in a browser -- or using curl and piping into more/less is not enough to protect you.
> It's trivial for a remote server to hand two different versions of a script with the traditional `curl | bash` pipeline.
I’m confused by this; it seems to be written in the tone of a correction but you both seem to be saying that you get whatever the server sends. (?)
Yes, but I am also saying that you can't verify that the script that is run on one machine with a pipe is the same script that runs on a second machine with a pipe.
The key part of the original statement is the server can choose to send different scripts based on different factors. A curl&bash script on machine 1 does not necessarily mean the same curl&bash script will be run on machine 2.
The tooling provided by a `curl | bash` pipeline provides no security at all.
With winget, there is at least tooling to be able to see that the same file (with the same hash) will be downloaded and installed.
There are ways to do this better, for example, check out https://hashbang.sh. It includes a GPG signature that is verified against the install script, before it is passed to curl.
It's not hard to run the `show` command to see what a winget install will do. https://learn.microsoft.com/en-us/windows/package-manager/wi...
It's easy enough to view the manifests (eg, https://github.com/microsoft/winget-pkgs/blob/2ecf2187ea0bf1...) and arguably, is better then the protection for MITM that you would get using naked cURL & Bash, simply because there are file hashes for all of the installer files provided by a third party.
> They are saying curl is strictly better, not that it is impenetrable
Right. But it arguably is not strictly better.
> You can't trust winget
Again, this is not backed up by anything. I have trust in winget. I can trust that the manifest has at least been vetted by a human, and that the application that will be installed should be the one that I requested. I can not trust that this will happen with curl | bash. If the application that is installed is not the one that I requested, there is tooling a process to sort out why that did not happen, and a way to flag it so that it doesn't happen to other users. I don't have this with curl | bash.
HTTPS only guarantees the packets containing the unverified malicious code are not tampered with from the server to you. A server which could very well be compromised and alternate code put in its place.
You are drawing an egregious apples-to-oranges comparison here. Please re-read what you said.
You could serve digitally signed code over plain HTTP and it would be more secure than your example over HTTPS. Unfortunately there are a lot of HTTPS old wives' tales that many misinformed developers believe in.