First reaction: Congrats, looks great!

Second reaction: Yet another, completely different syntax highlighting implementation/definition list... https://github.com/zyedidia/micro/tree/master/runtime/syntax

Couldn't pick any of the hundreds that already exist? :(

Looks like these are just nanorc files. so reusing nano's definitions? The project name also checks out.

They look similar, but definitely not the same:

https://github.com/zyedidia/micro/blob/master/runtime/syntax...

https://github.com/nanorc/nanorc/blob/master/csharp.nanorc

Looks like they were s&r'd. Which kind of makes the case: why not just make it compatible with nanorc? (Or anything else really, just, something that doesn't create yet-another uncountable set of syntax highlighting files that has to be maintained to support just one more editor)

What is the best syntax highlighting implementation/definition format out there ?

8.5Mb is a little too much for editor named micro. Whole DD-WRT/OpenWRT Linux Image is twice smaller.

That's because Go hasn't been historically very good at keeping binaries small.

However things are starting to get better: https://blog.golang.org/go1.7-binary-size.

I think the name is a play on the other popular editor 'nano'.

Allowing it a comfortable 1000-fold growth factor! :-)

For a comparison, my /usr/share/atom folder is >200Mb - just the main Atom executable alone is over 54Mb.

The binary is unstripped. Strip it, and it loses ~3 MB.

also statically linked, at least on osx.

All go binaries are statically linked. It's supposed to be one of the selling points of the language.

Go packages are statically linked into Go executables, yes. That doesn't mean that C libraries are, though -- and I think it's that level of static linkage that the parent meant.

If you're on macOS, try running $ otool -L some-go-program, or on linux:

  $ ldd ./team-service
        linux-vdso.so.1 (0x00007ffe492af000)
        libpthread.so.0 => /nix/store/9xsjqbsldr86vvs7p5ps4qlkjv9dhc0k-glibc-2.23/lib/libpthread.so.0 (0x00007f47ef267000)
        libssl.so.1.0.0 => /nix/store/v9mq9iv2sg017r7i0fpw8qlifvlpvlks-openssl-1.0.2h/lib/libssl.so.1.0.0 (0x00007f47eeff6000)
        libcrypto.so.1.0.0 => /nix/store/v9mq9iv2sg017r7i0fpw8qlifvlpvlks-openssl-1.0.2h/lib/libcrypto.so.1.0.0 (0x00007f47eeba4000)
        libc.so.6 => /nix/store/9xsjqbsldr86vvs7p5ps4qlkjv9dhc0k-glibc-2.23/lib/libc.so.6 (0x00007f47ee803000)
        /nix/store/9xsjqbsldr86vvs7p5ps4qlkjv9dhc0k-glibc-2.23/lib/ld-linux-x86-64.so.2 (0x00007f47ef484000)
        libdl.so.2 => /nix/store/9xsjqbsldr86vvs7p5ps4qlkjv9dhc0k-glibc-2.23/lib/libdl.so.2 (0x00007f47ee5ff000)

So go libraries can't be GPL'd?

And on x86_64 and ARM.

The compressed binary is only ~2.6mb.... Whereas nano is only 141k on my system uncompressed.

And kilo[1] is 28k but it doesn't have as many features. Also a "keyboard" vs "keystroke" editor, editors built before ginormous keyboards became ubiquitous use various keystrokes for commands, ones that came to exist in an assumed presence of a ginormous keyboard use special keys for commands. (example, if the only way to move the cursor up in your editor is the cursor up arrow key, you are a "keyboard" based editor. Not that either choice is better or worse just something I find an interesting distinction.

[1] https://github.com/antirez/kilo

That's weird, I didn't know keyboards used to be smaller. I assumed they started with the space cadet and kept shrinking.

You are right, that isn't the correct analysis. Initial programming editors like EMACS, vi, EDIT, TECO, FINE, SOS, and KED tended to keep cursor motion and edit commands bound to key combinations that would be available on most (if not all) terminals. This minimized the use of "special function" keys, even if they were there, because they weren't there for all terminals. So the working set of keys was smaller even though the keyboards themselves were of nominally average size.

My observation was around the use of the PC's special keys used in "generic" editors because the authors of those editors have chosen to assume that everyone it typing on a keyboard that matches, or emulates, the 101 or 108 key keyboard that the PC made standard.

Relative to: Atom, VS, Sublime Text, the mac Notes app, and modern hard drive sizes - it's pretty small.

No, it's not as small as Nano, but I have a hard time getting my hackles up over a single binary I can download in under a second.

The Notes app executable is 2.4MB uncompressed and Notes handles a whole bunch of stuff this thing doesn't. Sublime is 12.5MB.

Leave it to HN to complain about an 8Mb go binary.

> Common keybindings (ctrl-s, ctrl-c, ctrl-v, ctrl-z...)

How do those not get blocked by terminal emulators?

Presumably they respect that the running program has put the terminal into "raw mode"

e.g. with https://github.com/golang/crypto/blob/master/ssh/terminal/ut...

This looks amazing. Finally an editor that will work for an ssh session, yet doesn't demand you learn a bunch of unnatural incantations that are completely contrary to all of your everyday muscle memory. And cross platform too. Win, win, win.

I've compared the performance of Micro with some other editors, see:

https://github.com/jhallen/joes-sandbox/tree/master/editor-p...

just curious -- what motivated you to write a new text editor?

I know people for whom Vim was overwhelming to learn and they gave up or didn't use it properly. I'm trying to make an terminal-based editor which gives them as much as possible of the power of Vim or Emacs, while making it dead simple to learn and use.

It's AWESOME.

I have used emacs, vim, micro-emacs, sublime, notepad++, wscite, etc etc. This might not be so feature rich, but in my first try, this felt just right!

This is great work. I hated the usability of both Vim and Emacs coming from a Windows background. I knew it could be more intuitive. You've definitely accomplished that. One problem I ran into is figuring out how to close current document but keep editor open. I didn't see it skimming help tutorial or help commands. In most editors, it's called "close" (with "quit" as separate option) or "new." I suggest adding that if the command doesn't exist or putting it in help near "save" and "quit" if it does exist.

Any way to bind the mac command key (⌘)?

Unfortunately it is impossible to bind the mac command key because the terminal does not forward those key events to the applications (for example pressing Cmd-Q closes the terminal, not the app running in the terminal). See this issue: https://github.com/zyedidia/micro/issues/19.

Why does it seem like Go programmers need to include "in Go" on the tail end of product announcements?

because it targets a specific audience. people not interested in editors may look it up because they're interested in Go, and vice versa.

editors written in Rust also announce it proudly: https://news.ycombinator.com/item?id=8734307, so do many other projects.

"in language X" tells me, "I'm comfortable hacking in language X, I'm happy with the idea of using a product written in something I can hack". A pretty good reason, I think.

Go is hype and people think that because it's done by google it's cool meanwhile people at Google are using more and more Rust they even made their own editor with it:

https://github.com/google/xi-editor

There's also already a reasonably-popular Go project called "Micro," though honestly both projects could have picked better names.

https://github.com/micro

Yes it's unfortunate that there is already a popular Go project called "micro." The name here is a play on "nano" editor and I had already started the project by the time I saw https://github.com/micro. Oh well, I still like the name.

They cracked some vulnerability in HN ranking algo. "Go" is a magic word

This is false by the way. There are only four other HN submissions following this pattern. And of those, only one of them got more than 100 points.

Show HN: Iota – a text editor written in Rust (github.com) 221 points by gchp 628 days ago https://news.ycombinator.com/item?id=8734307

It just felt like there is at least one HN submissions each week about a new text editor written in X on the front page. Seems like writing a new text editor in a new language is the new Hello World!

Unlike niche programs, text editors are a necessary tool for any developer. And unlike most programs, you can use them to further develop them, an almost instantaneous feedback loop.

Because of these and other properties, text editors are some of the most attractive programs to study and practice for new language learners. It should not be surprising that they are popular with newer languages.

> It just felt like there is at least one HN submissions each week about a new text editor written in X on the front page. Seems like writing a new text editor in a new language is the new Hello World!

Why is either of these things bad?

useful