Hacker News new | comments | show | ask | jobs | submit login
Show HN: A simple, tiny Vim and kilo-inspired editor (github.com)
120 points by hellerve on Sept 5, 2017 | hide | past | web | favorite | 42 comments

"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.

"It isn’t widely known that Vim has interfaces into several popular scripting languages: Python, Ruby, Perl, Scheme, and Tcl."


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.

Doesn't Vim have Lua support too?

Neovim does, and it will be a first class scripting citizen in 0.3.


I know there are plugins for the lua file type (syntax highlighting, etc.). I don't know if you can write plugins in lua.

Lua is a valid language to write plugins.

My own fork of Antirez's kilo was created specifically to add Lua support:


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".

If you're after something lightweight, similar enough to be vim to be useable, and lua built-in checkout vis: https://github.com/martanne/vis

The structural regular expressions are also pretty interesting.

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 was actually scolded—by a friend—for not using curses, but I honestly prefer working with escape sequences.

Is your editor available on Github?

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.

"Frankly", I'm always willing to learn: Any facts to back up your claims?


> 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.


ANSI can do it in one escape sequence: "CSI2K".


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?

I made my own Kilo and have wanted to eventually build it into something like this (Vim-ish and Lua extensible.) Eventually, I will find the time.

Good stuff!

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 :-)

tested on Ubuntu Linux

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!

"wasd" keybindings got my vote!

Not all keyboards have a qwerty layout.

You can shoot pretty much any keybindings down with that argument, though. hjkl makes about as much sense on Dvorak as wasd.

I was referring to some stock non-US keyboards, not alternative layouts like Dvorak. hjkl is lined up the same way on most keyboards I have seen.

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.


Thanks for telling me. Github issue is filed: https://github.com/hellerve/e/issues/10

Will work on it when I find time.

Nice, thank you.

I fixed it now! You can script it through Lua. (through `set_left(<char>)` etc.)

Azerty, it's used in France and Belgium and maybe some other places too.

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?

can it display images, like imgcat?

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.

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact