▲ 146 points
back
26 comments
Nice work by the author. Honestly, though, it doesn't scratch an itch for me personally, since I'm pretty happy with https://github.com/fatih/vim-go ... This is like the ultimate vim plugin for Go and includes the kitchen sink, remarkably via included go tools for the most part:
- More colors than a christmas tree
- Autocomplete via gocode
- Auto-gofmt and auto-goimports
- Safe refactoring / renaming support
- Follow references / callers / callees via go oracle
- Show test coverage
- Show godocs
- golint, go vet,
As someone else had pointed out, this new editor has pointed me in the direction of https://github.com/gdamore/tcell which looks mighty interesting indeed...
This project, a simple to use console editor, doesn't really overlap in intended functionality with a go package for Vim.
agreed! it's all in the name, micro :)
nano is a much better comparison. When comparing the two micro seems like the better tool.
Huh, hadn't heard of tcell:
Oh thank god -- from the description of internal testing, it sounds like tcell Did It Right in avoiding absurdly global references to the tty, something that's quite painful in termbox. If it's as good as it sounds, I can't wait to change my applications over to this.
This is not a command line interface (this term could be applied to line editors like edlin), this is a text user interface.
Agreed the hacker news title is misleading, should be "zyedidia/micro: A modern and intuitive terminal-based text editor".
Good idea, nano IMO should support common shortcuts. It is more complicated save and exit from nano than from vim.
Looks like a great replacement for nano.
I've been wanting to try my hand at implementing an Acme inspired editor in Go. I'm very curious to look at their work.
You might be interested in https://github.com/eaburns/T
Ooh, very interested indeed. Thank you much.
Another text-based editor from hisham.hm (author of htop2) http://hisham.hm/dit/.
I totally agree, nano is due for a replacement.
I appreciate that the source code is really well annotated!
The implementation of checking if a buffer is dirty seems a bit... odd. It compares the saved text with the buffer text. Seems like a bool should do fine based on other operations I saw in that file.
https://github.com/zyedidia/micro/blob/master/src/buffer.go#...
The reason I do the check that way is because if the user adds a character, and then deletes it, the buffer has not been modified, but if you just set a bool to true when an insert event happens, it will think the buffer has been modified.
If there is a better way to do this please let me know.
In general, you should optimize for common use cases. In a file editor, you will be modifying the file and when you go to save it, it will be different.
What do you gain by doing it this way?
What about setting the dirty bit with a boolean while you're working, but then before saving, do the diff to check if the file really needs saving?
There is also a termbox based editor that works on Windows as well: https://github.com/nsf/godit
--edit-
This works on Windows as well...
Looks pretty nifty! Are there any plans for future development or is it just a toy?
$ micro/micro
terminal entry not foundWhat does this do that nano doesn't?
Only things I saw unless nano already does them:
* Execute commands (edit: to manage the editor settings).
* Support for shortcuts we're all very accustomed to in other software C+S to save, Ctrl+c to copy, Ctrl+v to paste, etc
* Mouse Support
Nano serves it's purpose but sometimes I need something that feels "modern" so I use TextAdept (works on the terminal as well). I might give Micro a try though.
In addition to those features, micro also supports colors better. You can make colorschemes for it so that syntax highlighting is consistent across filetypes, and it supports 256, and true color, while nano only supports 16 colors.
Micro can also easily interface with the system clipboard (Ctrl-c, Ctrl-x, Ctrl-v).
Why not call it Micrgo?????? COME ON PEOPLE.