On Wed, May 27, 2015 at 04:54:53PM +0200, Laurent Bercot wrote:
> On 27/05/2015 12:12, Hendrik Boom wrote:
> >I'm in the process of writing (yet) a(nother) editor and output formatter,
> >and on reading this, I started to wonder -- just how could one separate
> >a command-line version from the UI? I can see that the output
> >formatter can be so separated (and very usefully), but the actual
> >editing?
>
> Maybe I'm misunderstanding the question, as I'm unfamiliar with the
> internal of editors. But IIUC, an editor is, by definition, a user
> interface, so the command-line / UI separation looks impossible or
> irrelevant to me here.
> However, there are still some separations that you can perform when
> designing an editor. Right off the top of my head:
> - Core functions vs. actual interface, which could be terminal-based
> or X-based. Think vim vs. gvim, or emacs -nw.
> - programmable editor commands vs. interface to enter those commands.
> Think the sed engine in vi, or the LISP engine in emacs.
>
> If you factor your work correctly, it should be trivial for a program
> to get access to your editor commands via a library function call - and
> you can make a command-line tool to wrap useful calls. Also, there could

nvi (the Berkeley rewrite of vi, after abandoning their first version)
uses a shared backend (vi-ipc) connected to the frontend via pipe().
There are about four frontends: terminfo-based (curses was derived
from the code for this), tk, motif, and gtk.
I ended up finding out this as a result of making the motif frontend
build/work again.

Thanks,
Isaac Dunham