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?

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.

I use the CudaText for big files. It is like open source Sublime.

For a text editor, yes, absolutely.

As developers, we rotinely need to work with large data sets, may it be gigabytes of logs, csv data, sql dump or what have you.

Not being able to open and edit those files means you cant do your job.

I work exclusively outside of the windows ecosystem, so my usual go to would be to pipe this through some filtering tools in the CLI long before I crack them open with an editor.

You could make an argument for emacs, but probably not using emacs as a pure text editor.

But are you really trying to do that on a Windows Server? I feel like there are better tools for the job.

"Better tools for the job" isn't always "the tool currently bringing in the $$$$$$$$$$$$$$$". So you live with it.

Sure, maybe by switching to linux you can squeeze out an extra CPU core's worth of performance after you fire your entire staff and replace them with Linux experienced developers, and then rewrite everything to work on Linux.

Or, live with it and make money money money money.

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.

I have FAR installed for the same reason.

less works pretty well if you don't need to edit the files.

Who cares? It’s fun. Programming can be fun.

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.

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.

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.

I don't think a sentence in a big report page is counted as touting.

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.

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? :)

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.

Challenge. Accepted.

That's pretty handy. I was having to use bash -c "vi myfile.txt" which was a bit annoying.

If you were doing that to invoke WSL, note that these days you can do `wsl command arg arg arg...`

Probably more like need to use it. Basically nano for windows