5 ms·

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!

by _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.
- sdegutis 10y ago
  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.
  - gkya 10y ago
    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.
  - technomancy 10y ago
    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 10y ago
      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 10y ago
protomikron 10y ago
> 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.
stevekemp 10y ago
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.)
ploxiln 10y ago
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.

by _vya7 10y ago

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.

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

protomikron 10y ago

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

stevekemp 10y ago

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

ploxiln 10y ago

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.