
Show HN: A console-based editor with Lua support, based on antirez's project - stevekemp
https://github.com/skx/kilo/
======
_vya7
Some of the comments here are really missing the point.

antirez's original text editor was a _full featured_ text editor -- meaning
fully customizable (and fast!) syntax highlighting, and a very intuitive
search feature -- written in pure C, with no dependencies, not even ncurses,
and written in less than 1,000 lines of C code. And he wrote all this in _a
matter of hours._

This showed that fundamentally, a terminal-based text editor is trivial to
build. Keep in mind, the text-editor market space is currently _very_ sparse,
with only a few real choices: Nano, Vim, Emacs, Notepad, TextMate, Sublime
Text, and lately Atom, are the big players. antirez's work shows that,
honestly, there's no real reason for the sparsity of choices. Writing a usable
text editor is just _not that hard._

And stevekemp's fork shows that it's _still_ pretty trivial to add the kind of
editor customization previously only thought possible in projects like Vim and
Emacs. Think about it. Emacs came out in 1976! 40 years ago! But when people
want an editor that's fully customizable, they go to that. Or to Vim, which,
again, came out in 1991, 24 years ago! And trust me, setting up your
environment so that it's actually _usable_ , takes days to weeks.

Ironically, stevekemp and antirez's work, combined, shows that it actually
takes _less_ time to make an editor from scratch, than to customize Emacs or
Vim to your liking! Granted, that's kind of a stretch, since most of us won't
want to dive into implementing the concept of buffers.

More to the point than that, though, is that the top players in the terminal-
based text editor slash IDE space, were written so many years ago, that the
Internet was barely a thing at the time, that there wasn't yet a
standardization on keyboards or terminals or even operating systems.

Things have changed. A LOT. It's time our terminal-based text editors caught
up. But that doesn't inherently mean we have to start building everything on
top of Electron. Terminals still work, and they're fast & efficient as hell.

~~~
gkya
The point you miss is: there are thousands of packages for Emacs and Vim
already. Emacs has all sorts of useful programs that you can run, a list too
long to even summarize. There is an emacs version in common lisp, I guess it
was called Hemlock. MIT Scheme has it's own Emacs version. But you don't have
Gnus, elfeed, EMMS, flycheck, Org-mode, etc., on them, and you don't have the
time to write them all from scratch.

~~~
sdegutis
Those programs exist because people wrote them. And many are rewritten every
day to replace those. Emacs does _not_ have 40 years worth of plugins
available. If one single person rewrote the ones you use on a daily basis, it
wouldn't take very long. Divide that up by the number of people willing to do
it, even shorter.

Don't believe me? Look no further than Atom. That's _exactly_ what they did.

~~~
technomancy
Atom did this with the backing of a very well-financed company, and it still
doesn't fare all that well with niche languages.

I agree with the general gist of your first post, but I think it's important
to recognize that unless you can build on some portable standard method for
defining editor support for programming languages, there is going to be a cost
to living in the niche; it is going to make you more hesitant to experiment
with new languages. (This is speaking as someone who has also implemented
their own Lua-based text editor.)

~~~
sdegutis
Oh hey Phil. Didn't see you there.

Sure, Atom has Github paying for it, and they still don't have CIDER.

But you know what? Emacs users came up with CIDER _from scratch_. It barely
builds on top of any existing Emacs plugins. That _exact_ same thing could
have been done in an editor like kilo if it had the right scriptable
foundation.

~~~
gkya
But why did they not build CIDER on Hemlock with Common Lisp available instead
of Emacs Lisp? Because you need more than possibilites to get working without
wasting time. Apart from plugins, Emacs has the core environment to build such
a thing, and then there are many libraries that pile up in creating the
plugins, that others wrote, so that you don't need to implement a networking
library and a string processing library and a syntax definition library and
subprocess management library and whatnot in order to build sth. like CIDER.
Not that that's impossible, but certainly a waste of time when the tech and
the community is already there. It's of course on one's self to choose whether
to spend that time or not, and it's not bad or stupid to choose to create
one's own editor, but it's undebatable that some time that instead could've
been used productively for something else is spent duplicating others' effort,
if a brand new idea is not being implemented.

------
cschmidt
Interesting. You should look into adopting Lpeg to do your syntax parsing and
coloring, rather than defining all languages yourself.

[http://www.inf.puc-rio.br/~roberto/lpeg/](http://www.inf.puc-
rio.br/~roberto/lpeg/)

[http://peterodding.com/code/lua/lxsh](http://peterodding.com/code/lua/lxsh)

[http://foicica.com/scintillua/](http://foicica.com/scintillua/)

[http://leafo.net/guides/parsing-expression-
grammars.html](http://leafo.net/guides/parsing-expression-grammars.html)

~~~
stevekemp
Belated update, but thanks for the tip.

In the end I did indeed add syntax-highlighting via the use of the LPEG
library.

------
greenspot
A screenshot would have been so nice.

~~~
childintime
With something this small a binary would be nice. Really nice.

------
diaz
Another interesting editor I found recently previously mentioned on HN is howl
editor - [http://howl.io/](http://howl.io/) . Lua, lpeg lexing, fast.

Another one is textadept -
[http://foicica.com/textadept/](http://foicica.com/textadept/) . Also Lua

------
AstroJetson
I like this. Take something useful like antirez's tiny editor, decide that it
needs to have the ability to customize it, add Lua as a scripting support and
off it goes. Two small things working together to make a slightly bigger, but
much cooler software package. Very nice work!

------
aktau
Just like the original kilo.c, I liked reading this. Thanks!

~~~
stevekemp
Thanks.

------
stcredzero
So why this, instead of Vim with Lua scripting? Is this meant to be embeddable
in the same sense Lua is meant to be?

~~~
ajacksified
The point seems to be size and minimalism (under 1k lines), not to compete
with vim.

~~~
stcredzero
This would make it a good candidate for embedding.

~~~
gkya
If you need vi for embedding, there are the ex-vi and the nvi projects, BTW.
The latter with nex "are intended as bug-for-bug compatible replacements for
the original Fourth Berkeley Software Distribution (4BSD) ex and vi programs."
On my FreeBSD 10.3 it weighs in at 448K.

~~~
stcredzero
I could see an advantage in a Lua embedded implementation. If Lua is going to
be embedded anyway, there could be considerable memory savings. Also, many
features/packages could be left out and loaded dynamically only as needed.

I'm not sure how it works for Lua, but scripting languages on VMs often
compile down to very compact bytecode. An entire Squeak Smalltalk image has
been pruned down to 384k. I'd expect an entire vi clone in Lua to wind up only
a small fraction of that.

