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.
