[erlang-questions] erlang for programming a text editor

[Alpar Juttner]

On Sun, 2009-11-01 at 15:54 +0100, Joe Armstrong wrote:
> A text editor hardy needs concurrency it should be way fast enough on one core -
> there is no "natural concurrency in the problem" - emacs used to run
> blindingly fast
> on a 40Mz PC with 128KB of memory - it's *not* a difficult problem making
> something like emacs run fast enough (unless you want to use emacs to search
> through GBytes of data, in which case you're probably should not be
> using emacs anyway)

An editor like emacs does not need multicore, but it _does_ need
concurrency, as it could provide much better responsiveness. When emacs
blocks for a couple of seconds, it is already annoying. When it blocks
for tens of seconds, it can be a considerable pain.

      * Several years ago, I had gave up using a Emacs-RMAIL, because
        fetching new mail took a long time on our environment and this
        process blocks the whole emacs.
      * Emacs can open remote files through ssh/ftp. A wonderful feature
        but opening and (auto)saving may take quite a while through the
        net and these processes also block whole emacs.
      * Emacs-w3 is also practically unusable due to its blocking
        behavior.

In some important cases the non-blocking processing are solved in emacs
(such as in case of the compile command or the gdb interface) but with
complex design and sometimes with dirty hacking.

An inherently concurrent design would immediately eliminate all of these
issues.

Regards,
Alpar


> 
> I wrote a simple emacs editor years ago - it's in the widgets subdirectory
> of http://www.sics.se/~joe/ex11/download/release-2.5.tgz
> 
> The only tricky part was not the emacs logic, but the screen display
> and catching the
> keystrokes and mouse events.
> 
> /Joe
> 
> >
> > I wouldn't bet that Erlang's good distribution / parallelization would
> > offset the rest of the trouble.  I'm unsure how production-ready it is, but
> > Reia might make certain bits easier, just due to its string handling alone.
> >
> > JRuby or Clojure might be a better fit just because Java has MUCH more
> > mature Unicode handling and syntax highlighting.  I don't know of anything
> > for Erlang that even tries to do syntax highlighting, although you could
> > probably get a good start on the parsers with Neotoma.
> >
> > In any case, I wish you the best of luck.  It's good to see people trying to
> > tackle useful problems with the right tools.
> >
> > On Nov 1, 2009, at 12:31 AM, Ted Henry wrote:
> >
> >> With 100 core chips probably coming to desktop computers in the near
> >> future,
> >> I wonder about writing a multiprocess vi-like or emacs-like text editor
> >> (probably more emacs-like in implementation.) Sometimes single threaded
> >> editors really bog down when searching multiple files, syntax highlighting
> >> multiple files. I'm not that knowledgeable in the Erlang world. It seems
> >> like Erlang's fault tolerance and ability to upgrade code without
> >> restarting
> >> would not be big advantages for a text editor. Also a text editor isn't
> >> usually distributed across multiple physical machines. I think the main
> >> advantage would be Erlang's processes for concurrency. Would Erlang offer
> >> a
> >> good advantage over a programming language with software transactional
> >> memory (e.g. Haskell, Clojure)? Would *you* use Erlang to program a text
> >> editor or desktop application?
> >>
> >> Very interested to read your thoughts.
> >>
> >> Ted
> >
> >
> > --
> > Jayson Vantuyl
> > kagato@REDACTED
> >
> >
> >
> >
> >
> >
> > ________________________________________________________________
> > erlang-questions mailing list. See http://www.erlang.org/faq.html
> > erlang-questions (at) erlang.org
> >
> >
> 
> ________________________________________________________________
> erlang-questions mailing list. See http://www.erlang.org/faq.html
> erlang-questions (at) erlang.org
>