"feels like Vim, just different enough for you to be frustrated" is true, but I like the Lua built-in: it's a fantastic language for this kind of thing, and feels more inviting to a new plugin-writer than, say, Vimscript might.
A lot of those languages don't come activated by default on the packaged versions of Vim - Lua is one of them, at least on osx/homebrew.
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.
Yeah, the comment was a little tongue-in-cheek. I didn’t think just writing yet another Vim clone would be very interesting, whereas trying to keep it minimal yet usable would be an interesting challenge.
I actually really like Vimscript. It has features that many popular languages lack or have only recently got, like destructuring
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.
It's nice to see another editor that uses straight ansi escapes instead of the bloated legacy database of glass terminal incompatibility & its associated clumsy library. :-)
I did a similar thing, but it's more or less vi with some subtle differences that would make any vi user mad.
I really think curses causes more problems than it solves, today. It made sense back when terminals were hardware, and communications with them were really slow. Today? Explain to your friend what he needs to do when he connects to the solaris server on his campus, using rxvt-unicode, and all curses-using applications are completely broken. How to compile & install the terminfo file, where to get it, where to put it, and what to do because "rxvt-unicode" is too long a name for the implementation. Then explain to him why software won't use ansi standard codes that would just work.
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. :-)
But the escapes aren't actually standardised to particular values, as far as I remember. The terminfo database exists for a reason. Assuming every terminal is 'xterm' is an awful idea.
I said ansi because there is an ansi standard. Deprecated, admittedly. Practically all terminals you're going to come across do support a reasonable subset of that standard. Assuming the terminal supports these is more likely to work than some random implementation of curses that might or might not have your terminal in the database.
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.
It's bad to see someone ignoring previous work done and assuming that doing things by hand necessarily means doing it better or more efficiently. ncurses has optimization routines in it, and replicating them in your own project is bloat and, frankly, not something you're likely to do better.
I neither ignore it or assume I can do it better. I just did it because it was fun and satisfying.
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.
> 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.
Indeed. There really is not much screen update "optimization" to do in implementing an editor. It's really quite a no-brainer to keep track of updates to a line, and only update the tail that changed. And that's pretty much all it takes to keep it running smoothly over serial.
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.
Without looking at the source code, I wonder to what extent it succeeds at that goal. Does it actually contain a platform-independent state machine, and diff the current state against the last-known state in order to issue updates, or does it use heuristics to figure out how to reduce control sequences?
I asked for a point, not for a pointer to source code. I can RTFS myself, but after 20+ years of reading and writing code relevant to the question: again, do you have an actual point?
cloned the source and tried to build....failed.
had to add -lm -ldl and remove -Werror in the Makefile in order to get it to even build.
After that I got a binary "e" but running it just exits right away without any output.
Seems like a bit more work needs to go into this editor before it is ready for the public :-)
How hard is it to run it modeless? Also I love projects like this, so thanks!
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).
It shouldn’t be too hard: [kilo](https://github.com/antirez/kilo), the editor on which this is partially based, is modeless. All of the modes are thus addons that I’ve built. You’d have to tweak a bit of the code to make it usable as a modeless editor, but it could definitely work!
I actually didn’t know wasd weren’t always in the same place and hjkl were. Do you know any of these layouts at the top of your head? It might come in handy next time when I think about typing UX.
I'm typing on an AZERTY keyboard (used mostly in France and Belgium, and a few other countries according to Wikipedia). I'm not suggesting not to use wasd by default if people like it, just try and make it customizable for people with a non-QWERTY keyboard.
But people understand what is meant. I guess I'll spend another 20 years saying "hjkl" instead of "right hand in base row position", trading "being right" for "being understood". What exactly is your point?
Heh, that actually sounds like a fun thing to implement. But no, as of yet it can’t.
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.
