On Thursday 25 February 2010 02:23:33 am Charles Roper wrote:
> I am doing a bit of research for a project I am helping out with - a
> text editor - and the following question has been asked: what would your
> dream API look like and be capable of? Obviously, the API will be
> scriptable via Ruby.

First, make a low-level API. Then, join us in trying to build a "dream API" on 
top of that.

I'm not sure what it would look like, I have no idea what it's like to hack on 
a text editor. I'd say, let's look at the capabilities you have now, build 
that low-level API, and document everything, then we can start to talk about 
how you might improve it.

As for that higher-level API...

You may want to brush up on some Ruby idioms. For example, Ruby tends to 
support the more flexible idiom of returning an object representing some sort 
of handle in a longer operation (like reading a file or looping over a list):

file = open 'foo'
line = file.readline
file.close

That's needed in order to have full functionality, but we also expect tricks 
like this:

open 'foo' do |file|
  file.each_line do |line|
    ...
  end
end

(Note: The 'file' variable is identical in both cases, it's just that the loop 
automatically handles closing the file for us, probably ensuring it happens no 
matter what kind of exceptions are thrown, etc.)

The same works for generating output. Look at Builder, Erector, etc, for some 
examples of how that can look.

So without knowing your editor's capabilities in detail, and without ever 
programming an editor, I don't really know. You'll at least want to provide a 
low-level API, in case people disagree with your approach, or in case someone 
else comes up with a better idea. But if you want a higher-level API, 
something that'll blow us away, something like Hpricot but for text editors... 
That takes artistry.