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!
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)
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:
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.
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.
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.
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.
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.
"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:
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.
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.
46 comments
[ 2.7 ms ] story [ 113 ms ] threadHow do those not get blocked by terminal emulators?
e.g. with https://github.com/golang/crypto/blob/master/ssh/terminal/ut...
"<Name> - a text editor written in <new popular programming language>"
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
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.
Why is either of these things bad?
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? :(
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)
However things are starting to get better: https://blog.golang.org/go1.7-binary-size.
If you're on macOS, try running $ otool -L some-go-program, or on linux:
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.
[1] https://github.com/antirez/kilo
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.
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!
https://github.com/micro
editors written in Rust also announce it proudly: https://news.ycombinator.com/item?id=8734307, so do many other projects.
https://github.com/google/xi-editor
https://github.com/jhallen/joes-sandbox/tree/master/editor-p...