7 ms·

Show HN: A console-based editor with Lua support, based on antirez's project

85 points by stevekemp 10y ago

aktau 10y ago
Just like the original kilo.c, I liked reading this. Thanks!
- stevekemp 10y ago
  Thanks.
cschmidt 10y ago
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
- sdegutis 10y ago
  As another person writing an Emacs-like Lua-based fork of antirez's original text editor, I'm not convinced that's the right way to go. The vast majority of language definitions will work fine with antirez's much simpler solution. And even if something more complex is needed, I'm not sure that requiring language authors to learn LPeg is a good idea.
- stevekemp 10y ago
  Belated update, but thanks for the tip. In the end I did indeed add syntax-highlighting via the use of the LPEG library.
stcredzero 10y ago
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 10y ago
  The point seems to be size and minimalism (under 1k lines), not to compete with vim.
  - stcredzero 10y ago
    This would make it a good candidate for embedding.
    - gkya 10y ago
      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 10y ago
        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.
    - stevekemp 10y ago
      That will be my end-goal; an editor I can ship with my (lua-based) mail-client.
- sdegutis 10y ago
  I disagree with ajacksified's interpretation of the significance of stevekemp's project. See my comment above for a different perspective.
- stevekemp 10y ago
_vya7 10y ago
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 10y ago
  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.
  - 10y ago
greenspot 10y ago
A screenshot would have been so nice.
- childintime 10y ago
  With something this small a binary would be nice. Really nice.
AstroJetson 10y ago
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!
diaz 10y ago
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

85 points by stevekemp 10y ago

aktau 10y ago

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

stevekemp 10y ago
Thanks.

cschmidt 10y ago

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

sdegutis 10y ago
As another person writing an Emacs-like Lua-based fork of antirez's original text editor, I'm not convinced that's the right way to go. The vast majority of language definitions will work fine with antirez's much simpler solution. And even if something more complex is needed, I'm not sure that requiring language authors to learn LPeg is a good idea.
stevekemp 10y ago
Belated update, but thanks for the tip. In the end I did indeed add syntax-highlighting via the use of the LPEG library.

stcredzero 10y ago

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 10y ago
The point seems to be size and minimalism (under 1k lines), not to compete with vim.
- stcredzero 10y ago
  This would make it a good candidate for embedding.
  - gkya 10y ago
    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 10y ago
      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.
  - stevekemp 10y ago
    That will be my end-goal; an editor I can ship with my (lua-based) mail-client.
sdegutis 10y ago
I disagree with ajacksified's interpretation of the significance of stevekemp's project. See my comment above for a different perspective.
stevekemp 10y ago

_vya7 10y ago

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 10y ago
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.
- 10y ago

greenspot 10y ago

A screenshot would have been so nice.

childintime 10y ago
With something this small a binary would be nice. Really nice.

AstroJetson 10y ago

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!

diaz 10y ago

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