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

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

github.com

85 pointsstevekemp29 comments

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.

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.

It's a curious thing, programmers tend to not write their own editors/IDEs... everything else is reinvented, NIH syndrone, but not that.

I don't think it's external packages (actually, internal packages eg syntax colouring, various completions, are a stronger argument), nor the related maturity quality of being debugged, and feature-gaps/annoyances filled, buffed, polished. I think it's:

(1) once you get adapted to finger bindings, you're reluctant to lose that investment by switching.

(2) when you first start coding, you have to use an existing editor. It takes some time before you are able to write an editor, or that you start looking at the editor, rather than looking through it. By then, see (1)

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.

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

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.

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.

Emacs users came up with Cider, but they were able to do it because there were a whole ton of them. Cider has had 154 contributors: https://github.com/clojure-emacs/cider/graphs/contributors

I won't say that it is impossible to have something like Emacs out, and get people to make the relevant packages, with a list of them just as long. It has to catch on, though. Many Emacs packages are full-fledged application programmes, and there is a large set of both core and external libraries powering them. But certainly if this Kilau or sth. else gets a big traction, everything is possible.

I appreciate your thoughtful comment. As somebody who's spent the past year writing console-based applications with Lua it was immediately obvious to me that antirez's code was both clean and useful - and that it could be a lot better with "scripting".

I've seen a few other forks which are also going down that round, perhaps yours is the most interesting of those!

Although I've never thought to write an editor having this functional base upon which to build allowed me to get started and I've been enjoying the process.

(I write code in emacs, and reply to email in vim. So I use both editors. Nothing else though.)

There's a bunch of maintained terminal text editors out there.

  joe    http://joe-editor.sourceforge.net/
  elvis  http://elvis.the-little-red-haired-girl.org/
  vile   http://invisible-island.net/vile/
  mg     http://homepage.boetes.org/software/mg/
  uemacs http://git.kernel.org/cgit/editors/uemacs/uemacs.git
  nvi    https://sites.google.com/a/bostic.com/keithbostic/vi/

There's also "sam" and "acme" from plan9, which are not text-terminal, but super minimal X11.

Anyway, there's a bunch of text editors out there, most people who care have found one that works well enough for them.

> This showed that fundamentally, a terminal-based text editor is trivial to build.

I do not agree. There is a big difference between a proof-of-concept terminal-based text editor and a state-of-the-art development editor like vim or emacs. I really encourage people to write a proof-of-concept "self-hosting" editor (i.e. writing the later parts of your text editor in a reasonable stable version of your text editor) as it is a fun project.

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://peterodding.com/code/lua/lxsh

http://foicica.com/scintillua/

http://leafo.net/guides/parsing-expression-grammars.html

Belated update, but thanks for the tip.

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

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.

A screenshot would have been so nice.

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

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

Another one is textadept - http://foicica.com/textadept/ . Also Lua

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!

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

Thanks.

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

I'm actually looking for an editor to embed inside my lua-based mail-client.

Given the history of kilo (being inspired by nano, and that in turn coming from PICO & PINE) it is pretty ironic.

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

This would make it a good candidate for embedding.

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.

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.

That will be my end-goal; an editor I can ship with my (lua-based) mail-client.

I disagree with ajacksified's interpretation of the significance of stevekemp's project. See my comment above for a different perspective.

Reply on news.ycombinator.com