aretext
orbiton
aretext | orbiton | |
---|---|---|
3 | 4 | |
240 | 427 | |
0.4% | - | |
8.3 | 9.8 | |
about 2 months ago | 6 days ago | |
Go | Go | |
GNU General Public License v3.0 only | BSD 3-clause "New" or "Revised" License |
Stars - the number of stars that a project has on GitHub. Growth - month over month growth in stars.
Activity is a relative number indicating how actively a project is being developed. Recent commits have higher weight than older ones.
For example, an activity of 9.0 indicates that a project is amongst the top 10% of the most actively developed projects that we are tracking.
aretext
-
Incremental Parsing in Go
Look at the current Makefile:
https://github.com/aretext/aretext/blob/main/Makefile
Build is literally a `go build ...` and install is `go install`. Adding any other language to the mix would make this a polyglot project and not be "equally easy to set up". The other question is, do both parsers exist? In this write-up they point to tree-sitter as a possibility which is a JS program that produces C code. This would be viable, but here's the author's take:
> I considered integrating tree-sitter, an incremental parsing library with parsers for many existing languages. However, running JavaScript to generate parsers and linking to a C library would have greatly complicated the build process. Today, aretext can be built on almost any platform using a single go install command. I’ve had users install aretext on ARM laptops, FreeBSD servers, Chromebooks, and Android phones. To maintain portability, I wanted a pure Go implementation.
So this wasn't some casual decision, but something they at least considered long enough to describe here.
And the parsing library itself is only around 1200 lines total (comments, blanks, and code). The parsers for each language add a lot more, of course, but should be roughly equivalent given the same library and interface. I imagine that if this project really takes off and performance becomes a real problem they can do the rewrite at that point. Right now, the code works, seems to work fast enough for its author and primary users, and it's trivial to install on any platform supported by Go. So yes, it would have been a premature optimization to complicate the build process, probably reduce the number of supported platforms (or greatly increase the effort to support the same number of platforms), just to have a slightly faster parser.
- aretext - Minimalist text editor with vim-compatible key bindings.
orbiton
- Orbiton 2.65.1 Is Out
-
Micro – A Modern Alternative to Nano
Another small TUI ide/editor to try is Orbiton [0] also written in go has can do clang-lint, compiling, and has gdb debugging support, though I believe it lacks plugins. I tested it on an old 2012 kindle fire and it works great.
[0] https://github.com/xyproto/orbiton
- Orbiton: A slim configuration-free text editor for VT100
-
What are some useful tips and tricks for general game development or productivity tips, that you personally use?
Here's one plugin https://github.com/jkramer/vim-checkbox Also this editor supports it https://github.com/xyproto/o
What are some alternatives?
Squircle-CE - 👨💻 Squircle CE is a fast and free multi-language code editor for Android
micro-editor - A modern and intuitive terminal-based text editor
scc - Sloc, Cloc and Code: scc is a very fast accurate code counter with complexity calculations and COCOMO estimates written in pure Go
mg - Micro (GNU) Emacs-like text editor ❤️ public-domain
mangadesk - Terminal client for MangaDex 📖
uapi - Unix API
ntfy - Send push notifications to your phone or desktop using PUT/POST
mangal - 📖 The most advanced (yet simple) cli manga downloader in the entire universe! Lua scrapers, export formats, anilist integration, fancy TUI and more!
tut - TUI for Mastodon with vim inspired keys
micro-acme - Acme style editing plugin for micro editor
vim-checkbox - Vim plugin for toggling checkboxes.
haste - A small and modular text editor written in bash