Microsoft Edit

Fun. I must admit I don't really know who this is for, but it seems fun.

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.

That may be the written goal, but I doubt that's the actual reason the project exists.

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.

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'.

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.

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.

Perhaps those are the things that doesn’t take a Ph.D to develop.

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.

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]

well the editor was obviously designed primarily for Windows, not sure why the title says Linux

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.

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?

Challenge. Accepted.

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.

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.

Nano gang

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

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.

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.

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.

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.

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.

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 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

It's a huge improvement over notepad

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.

this is for me, as saner replacement for nano in the terminal, since i hate vi.

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.

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

> You need to point them at a text editor, which one do you choose?

mcedit ?

Midnight commander comes with mcedit.

I have FAR installed for the same reason.

TIL PowerShell exists for Linux.

But.. why?

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.

It's a windows 11 terminal editor. Don't get confused by the fact that it also works on Linux.

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

Wrongly phrased scenario. If you are running this cluster for the biologists, you should build a front end for them to "edit SLURM scripts", or you may find yourself looking for a new job.

> A Bioinformatics Engineer develops software, algorithms, and databases to analyze biological data.

You're an engineer, so why don't you engineer a solution?

Well why not?

Is there supposed to be a single elected shell for Linux? Powershell on Linux is just one of plenty others.

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

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

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

I'm not against it. Absolutely go for it.

I just wonder what was the reason to port it and then I would like to have a word with a real living person who is actually using that shell.

I believe this was the original announcement https://azure.microsoft.com/en-us/blog/powershell-is-open-so.... I have used it on Linux and it is included by default in Kali and ParrotOS.

"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 dunno, I use edit since I've heard of it instead of figuring out why my vim config breaks on windows

I might use nano via wsl (Or at that point just nvim), but that also has it quirks

It occupies the same space as micro did for me, but it's / it will be preinstalled so it's better (Also a reason I even cared for vi at first)

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.

> make money money money money.

Subject, of course, to Microsoft allowing you to continue to use their software.

Well, parts of it do, anyway.

As with .net, it is not intended to let you easily get away from Microsoft.

https://learn.microsoft.com/en-us/powershell/scripting/whats...

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

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

PowerShell lends itself really well to writing cross-platform shell scripts that run the same everywhere you can boot up PowerShell 7+. It's origins in .NET scripting mean that some higher-level idioms were already common in PowerShell script writing even before cross-platform existed, for instance using `$pathINeed = Join-Path $basePath ../sub-folder-name` will handle path separators smartly rather than just trying to string math it.

It's object-oriented approach is nice to work with and provides some nice tools that contrast well with the Unix "everything is text" tooling approach. Anything with a JSON output, for instance, is really lovely to work with `ConvertFrom-Json` as PowerShell objects. (Similar to what you can do with `jq`, but "shell native".) Similarly with `ConvertTo-Json` for anything that takes JSON input, you can build complex PowerShell object structures and then easily pass them as JSON. (I also sometimes use `ConvertTo-Json` for REPL debugging.)

It's also nice that shell script parameter/argument parsing is standardized in PowerShell. I think it makes it easier to start new scripts from scratch. There's a lot of bashisms you can copy and paste to start a bash script, but PowerShell gives you a lot of power out of the box including auto-shorthands and basic usage documentation "for free" with its built-in parameter binding support.

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

Nano's not CUA and doesn't support mouse control, though.

That's a very good and insightful comment. Thank you!