Microsoft Edit

I used to recommend micro[1] to people like those in the target audience of this editor. I wonder if that should change or not.

--

1: https://micro-editor.github.io/

IMO it should not.

`edit` doesn't even support syntax highlighting (atleast, out of the box when I tried it).

I think you missed the point of edit.

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.

A lot of authors, myself included, want a "distraction free" editor. Its a whole over-populated market segment.

Prose thrives in the terminal. Ice and Fire was written in WordStar, as just one popular example.

It might in the future, though, as the main developer has opened an issue about it: https://github.com/microsoft/edit/issues/18

The trick is doing it while keeping the binary size small, so tree sitter is not an option.

Last time I checked, micro should have been called macro based on the binary file size.

Is that why the series ground to a halt

I met someone recently that still uses WordStar. Yes I'm serious. He runs it in QEMU on FreeDOS. He's a writer for a living.

There is also dte[1]. It hits exactly the same notch and offers an extremely lean editor with Unicode support, CUA key bindings and much more. It has replaced nano as my terminal editor.

[1]: https://craigbarnes.gitlab.io/dte/

Rachel Kroll once posted that she writes her posts in nano, with the distraction of syntax highlighting turned off: https://rachelbythebay.com/w/2011/09/24/editor/

I can't find the link but I think at some point she compiled her own nano with some "helpful" feature patched out again.

George R.R. Martin still uses Wordstar as well!

Why are you opposed to learning vi which is already installed everywhere?

as someone who uses CLI text editors frequently, but not often enough to build the muscle memory which remembers VI shortcuts, i really appreciate simple text editors.

i know that i can press like 3-4 arbitrary buttons to mark a block to move it to a different place - how about i just mark it with my cursor and CTRL-X CTRL-V, like every freaking other program out there.

i appreciate that i got VI on freshly installed or secured servers, but for things i use daily, i just want it to be KISS. already counting on people answering 'but vim is easy and simple'. opinions differ i guess.

https://www.youtube.com/watch?v=9n1dtmzqnCU

Well, it is orders of magnitude larger than nano, so...

Because vi has all the usability of a keyboard made out of hedgehogs.

I learned vi a long time ago and use it when no other editor is at hand. In fact, I am using several editors simultaneously, depending on the task at hand and what is availabe. I stumbled over dte because I like to try out new things. And because dte hits many sweet spots for me, I installed it on machines where I often need a terminal editor. Binding myself to only one tool just because I learned to use it at some point in time is not my philosophy. Thankfully, the open source world offers so many alternatives and innovations, so that there is something for almost all tastes and habits. It comes with no costs besides building muscle memory to switch as needed and wanted.

Seriously? We're going to complain about a couple megs in a text editor in the year 2025?

I wouldn't consider vi usability to be overall bad. Sure, affordance ("is it easy grasp which moves i can make without affording much cognitive effort?") is terrible.

Setting up a decent environment is also a huge pain to get started with, but nowadays you can just hop into a prewarmed pool with premade setups like Normalvim or LunarVim.

But usability is not just "is it easy to learn", it's also "once i know it, how hard is it to use"

Once the moves are ingrained in your (muscle-)memory it becomes so incredibly efficient. di{, dat, yaf etc. are just the low hanging fruit, once you start with regex, macros and plugins the fun really begins.

Isn't the relatively large binary just because it's written in Golang? Go executables each ship their own copy of the Go runtime. That alone accounts for a big chunk of small programs like this.

Nano also links against ncurses, which is about as big as the compressed tarball for micro. I'm looking at the dependency closures of each right now in nix-tree[1], and micro's closure's total size is 15.04 MiB while nano's is 12.78 MiB-- not really "orders of magnitude" (as a sibling commenter suggests) when you look at it like that.

Admittedly, nano's dependencies (`file` and `ncurses`, on my system) are likely to ship as part of the "base system" of any Linux distro anyway; the real size it adds to any distro is negligible. But there's no indication to me that micro is meaningfully "bloated", as the meme goes; it seems like what is required to run it is reasonable and comparable to other tools that serve the same purpose.

--

1: See: https://github.com/utdemir/nix-tree ; Try `nix run nixpkgs#nix-tree -- $(nix build --no-link --json nixpkgs#nano | jq -r .[0].outputs.out)`

Sure, there are always exceptions but they're only that, exceptions.

I'd recommend everyone to take a look and read some of dte's source code. It's a great example of beautifully written modern C code.

Yes, couldn’t use on my router because of its size. No reason for a TUI to be so big. Advanced features outside of syntax highlighting not useful. Should have a light version.

I installed nano with CUA keybindings instead.

Learning CUA once is more realistic/convenient for most people.

Vim (and so many other editors, too) supported syntax highlighting for decades before TreeSitter even existed. Let’s not act as if this is a novel challenge.

I think you missed the question I was answering in my comment.

I like vim a lot, and I use vim-style bindings wherever I can.

But before I learned to ride a bike, I used training wheels, and before I learned enough vim to enjoy using vim, I leaned on nano.

When someone is first learning to explore GNU/Linux, or even to dig into the Unix guts of macOS, they're learning a whole new world, not just a new text editor. For some people, strategic bridges to what they know (like CUA or Windows-like shortcuts) can make this process more fun and less fatiguing. Sometimes that difference is decisive in keeping someone motivated to learn and explore more.

Anyway, I think vim is worth learning (and maybe some of the quirks of old-school vi, if you expect to work on old or strange systems). It's not a matter of if I recommend that someone learn vim, but when. And until it's time for them to explore an editor deeply, micro seems like a great fit for most people.

I also want to say: as enthusiasts of Unix-like operating systems, or as professionals who appreciate some of their enduring strengths, should we really embrace a "because it's there" doctrine? Isn't that same kind of thinking responsible for huge, frustrating piles of mediocrity that we work with every day and resent?

ss someone who loves an ecosystem built first by volunteers as "just a hobby, nothing big and serious", I will it's sad, if not hypocritical, to dismiss software projects just because they aren't already dominant players. Most software I love was once marginal, something its users went to lengths to install on the systems they used because they enjoyed it more than the defaults. We should, to the extent practical, try to leave a little room for that in the way we approach computing— even as we get older and grumpier.

vi isn’t usable. it sucks. but the facts are it’s installed everywhere and you can learn how to use it in 10-15 minutes. easier to patch your ignorance of basic vi than it is to install software on every machine you’ll ever edit on.

And you can get it on Windows with just "winget install zyedidia.micro". Reminds me of 8 & 16-bit editors of a similar era.

There's an underlying assumption about "target audience for this editor" that you both share, that others, I suspect quite a few others, do not.

For starters, there's your assumption that there is "syntax" to be highlighted. Not every text file is something written in a computer programming language.

The reason may help understand why but it is not really interesting from the point of view of the user or those packaging it with their OS.

Like my mother say. Small stream makes huge rivers.

Not caring about a couple of megs here and there is what makes some modern systems so bloated.

You realize that you're asking this in a discussion of a tool that is intended to be installed out of the box on Microsoft Windows, where vi is not installed out of the box, right? Your "everywhere" doesn't include the primary use case for what is being headlined here.

You're right, I do assume most (90+%? of) people that are looking for a terminal editor are likely developers.

In fact I'd put money on it, but sadly do not have any evidence to back it up.

If you have evidence to the contrary I'd be intrigued!

Micro is a great editor to replace stuff like nano. I think it would be a bad replacement for edit though, edit is very barebones, and micro is very "upgradeable" through lua. It also handles large files quite well also

> “I’m 12 years late on this damn novel, and I’m struggling with it,” he said. “I have like 1,100 pages written, but I still have hundreds more pages to go. It’s a big mother of a book for whatever reason. Maybe I should’ve started writing smaller books when I began this, but it’s tough.”

He's averaging a hundred pages a year. Maybe not the fastest, but certainly not the slowest writer. With the size of his books... Cut the guy some slack.

You might not be wrong about percentages, but there are famously some Emacs users who for into it for Org mode or academic writing, including even some who learned to program long to better customize their Emacs setup and eventually became contributors.

But these are amateur geeks or geeks in the making who probably don't mind having the capability of syntax highlighting built in, even if for some purposes they want it turned off.

why would the binary size be big to support this? Scintilla has been doing syntax color for decades -- it's pretty small.

I think you're assuming people who are thinking of going beyond the original "point" of edit missed that point. We didn't. We're looking new directions it can go.

> 12 years late

Seems like people have cut him a lot of slack already. Of course he doesn’t really owe anything to anybody, but at some point he and everyone else has to face the reality - which is that if that book is ever published, it’ll be posthumously, finished by a ghostwriter.