Show HN: A simple, tiny Vim and kilo-inspired editor
github.com
github.com
That strongly dissuades me from writing plugins in anything other than Vimscript. It might work for the guy who recompiles his Vim often, but it will not work on that vim instance running in your server. Ubiquity is one of Vim's main points.
The structural regular expressions are also pretty interesting.
Having even basic support, for key-bindings, and reacting to events, is very useful.
I wrote a console-based mail client which is configured and scripted via Lua, and would love to see Lua added to "all the things".
let [file, line, col] = split("hello.c:39:10", ":")
This is the sort of feature I just assumed it didn't have, because few enough real programming languages have it.The main issue I think is that there are lots of different contexts where you can put vimscript, and different bits of vimscript are legal in those contexts, or at least seem to be.
I did a similar thing, but it's more or less vi with some subtle differences that would make any vi user mad.
Is your editor available on Github?
Nah my editor is not on github. I figured that I'm only writing it for myself anyway; any rational people should be happy with nvi or vim or one of a few dozen other editors. And the few stubborn ones like me will want to write their own editor anyway. :-)
> Part of what curses does is optimize cursor control sequences so (for example) to backspace all the way to the beginning of a line, instead of writing out a bunch of back-space characters, it can issue one command to move the cursor to the beginning of the line, and one more to erase to the end of the line.
For more detail, there's the source code.
I don't have my code handy right now but all the screen handling amounts to maybe a couple hundred lines of code, out of many thousand.
I don’t believe I could do better than curses/ncurses. What I do believe, however, is that replicating the work isn’t always bloat. If you’re only going to use a small subset of the library anyway, replicating a bit of it might actually be less bloaty than including the whole thing. That said, when in doubt using pre-made solutions surely is better _if_ you’re working in a professional/production-grade environment. I on the other hand am just playing around and seeing how far I can take this.
Projects like these are always welcome on Hacker News. I am saddened to see comments like the parent's (that are too eager to discourage any technical decision that does not conform to their opinion) popping up in this community often.
The very purpose of the "Show HN" prefix is to show off fun projects like these to the HN community and the more such projects we have (regardless of what technical decisions were taken to create the project), the better it serves that purpose.
If people really insist on using some weirdo terminal that doesn't support ansi, they are free to run a terminal emulator such as screen between the application and their terminal.
Worrying about every legacy glass terminal from the 70s is an awful idea.
Good stuff!
tested on Ubuntu Linux
GNU Zile (https://www.gnu.org/software/zile/) is another one I really enjoy with a more emacs focus (i.e. modeless) (but again, changeable in any direction you want with Lua).
Will work on it when I find time.
And when I think about having to adhere to my "as few dependencies as possible" standards, which basically means I’d have to implement a bunch of image file parsing, I think I’d rather not. I just saw imgcat uses CImg for that, which seems like a smart move.