You dream API for a text editor

Ruby
1

Hi Friends,

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.

I’d be very interested to hear what you guys think.

Many thanks,
Charles

2

Hi Charles,

Jedit can be scripted in various languages. I bet they have JRuby
support.

Vim can be scripted in Ruby.

I don’t know about Eclipse.

Writing an editor is a non trivial task.

And I would not ask what API do you dream of.
I’d ask: Which features do you need and how to get them.

Marc W.

3

Hi Mark,

Thanks for the reply.

On 25/02/2010 08:53, Marc W. wrote:

Jedit can be scripted in various languages. I bet they have JRuby
support.

Vim can be scripted in Ruby.

Are you saying these offer model API’s that we should take a look at? I
already know Vim is a strong influence on the project. RedCar also
offers scripting via Ruby.

Writing an editor is a non trivial task.

Agreed.

And I would not ask what API do you dream of.
I’d ask: Which features do you need and how to get them.

The features are already there - this isn’t a new editor. What we’re
doing is looking at how to make the editor flexible, extensible and fun
as possible without requiring folk to hack on C++. But this isn’t about
the editor itself, as such, but rather about the API: what do people
feel makes a great API for a text editor. Or, put another way, what are
the strengths/weaknesses of other API’s, Ruby or not, you may have used.

Cheers,
Charles

4

On 25/02/2010 09:53, Marc W. wrote:

Good luck - I don’t think I can help you any further - I told you what
is important to me.

Thanks, it’s appreciated. :slight_smile:

5

Hi Charles,

your trying to please everyone. This is not going to work (IMHO).

Here is a list. You can join all mailinglists and ask people what they
like and dislike. Or join their irc rooms.

Eg Vim is a great editor. I’d even say perfect if it wasn’t bad at
talking to external processes. (I’m going to fix this though…)
Also the default Vim scripting language VimL isn’t very fast.
Keep in mind that it was invented before Ruby, Python etc existed.
At at that time it was very cool.

as possible without requiring folk to hack on C++.
The big question is: Why do they start hacking at all?
What features are they missing?

Eg I prefer using vi keys over nice API’s because they make me
productive every day.

Good luck - I don’t think I can help you any further - I told you what
is important to me.
Marc W.

6

On Thursday 25 February 2010 02:23:33 am Charles R. 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.