Re: [dev] ved (was: Suckless word processing solution?)

From: markus schnalke <>
Date: Tue, 06 Oct 2009 17:39:12 +0200

[2009-10-06 10:43] pancake <>
or better
[2009-10-05 03:04] pancake <>
> Vi is the visual ed, but I have never seen any implementation using
> ed. They just embed it inside the 'GUI' .
> I think that having all the editing engine implemented in ed is
> simple to wrap it into a GUI based on X11 or ncurses.

Okay. Now I see a difference. But also difficulties.

What about unlimited undo for example? Ed does not provide this. Thus,
if you want it (We *do* want it.), you have to put it in the UI. But
that's the wrong place.

We also should do performance experiments first, because it's important
that the editor responds directly. Splitting it into two processes might
cause bad performance.

What I like, however, is the idea of having one UI and several eds
behind -- one for each file you edit.

> Vim supports launching apps to filter text, but it is not the main
> way to work. Because is more optimal and easy to port to other os
> like dos or w32.
> Syntax highlighting is something that can be implemented in a
> filter program.

Syntax highlighting is bad on terminals. Seems there is no sane way to
have it. Don't know about X applications.

> The same for indent, line numbering, text
> alignment, etc..

The question is: Do you really want this stuff to be outside the
editor? You'd need constantly a whole lot of forks.

> I love vim, but I feel that most of the capabilities it supports
> are embedded in the editor instead of using a unixlike design based
> on pipes and filters.
> Autocompletion, ctags, searchs,,.. Can be implemented outside the
> GUI without much pain.

I think search (read: RegExp) is crutial to be a core part of the
editor. Ed already offers it.

For the other stuff, I agree. If one needs them (at all) then through
external programs.

> We just need a GUI that supports X11, ncurses, sdl or OpenGL that
> allows to bind some keybindings to run commands at Ed level or
> change the filters for example.

We probably don't want sdl and OpenGL.

> The main problem in this application is to find the good
> simplification of the design to allow good flexibility, performance.

> Any proposal?

Have a look at sam. That's what the former users of ed use today.
You'll probably find interesting approaches there.

First try to get a prototype ready, which excludes the extreme parts.
You'll may notice that some of the ideas simply don't work. But if the
design holds, go on in a second iteration.

In other words: Don't try to get a micro kernel right on the first try
... i've heard of some guys who still work on it. :-)

I'm looking forward for the project

Received on Tue Oct 06 2009 - 15:39:12 UTC

This archive was generated by hypermail 2.2.0 : Tue Oct 06 2009 - 15:48:02 UTC