Re: Anjuta2 editor interface limitations

[Dave Camp <dave ximian com>]

On Tue, 2002-11-12 at 05:41, Biswapesh Chattopadhyay wrote:
> Hi
> 
> It seems that Anjuta2 uses a limited interface for the editor
> (gdl/idl/editor-buffer.idl). Because of this, things like getting
> current word, etc. are extremely inefficient (e.g. in
> anjuta2/libanjuta/anjuta-doc.c, to get a word, you get the whole
> document through CORBA, get the current position and then get the
> current word). 

This is true.  Extensions to the EditorBuffer interface are welcome. 
The original idea was to keep this interface as small as possible to
make implementation easier, but I think it has since become clear that
the client interface needs to be more convenient than the server side.

> Things are going to get worse if we try and port things
> like word completion, etc. since every function would mean getting the
> whole editor buffer from an external process through socket (or whatever
> way CORBA communicates). 

Again, more methods can be added to EditorBuffer.  This isn't cast in
stone.  Additionally, it might be worth considering implementing word
completion in the editor itself.

> Add to this things like marshalling /
> de-marshalling and things will slow down dreadfully, esp. for people
> editing a number of big files.

(remember that glimmer is in-proc, so there is no
marshalling/demarshalling).

> Another problem: there are no interfaces for telling the editor to do
> stuff like show completion lists, calltips, etc. which are pretty basic
> requirements for an IDE.

Not yet.  There can be.

> Further, from what I got from the code, editor
> gutters are implemented seperately from the editor. This, IMO, does not
> make sense since editor gutters are an integral part of the editor GUI
> (e.g. Scintilla).

They are implemented with a seperate interface.  This allows us to do
something like :

component = load_component ();
gutter = get_gutter ();
if (gutter) { /* glimmer, or scintilla, or whatever */
} else {      /* gtkhtml, eog, whatever */
}

This is a pretty fundamental concept of clean component-based
programming.

> So, my question is: are there any plans to extend the editor interface
> or to convert the editor part to a glue tool or a simple widget ?

There are no immediate plans to extend the interface, although you are
free to propose changes and provide patches.

As for making the editor a glue tool, I don't think that will happen
anytime soon.  We converted most of anjuta2 to glue, but left the editor
for a reason.  I'll cover the reasons below.

> I know
> people like using multiple editors but IMO the default editor should be
> as fast and feature rich as possible since that's what 99% of the people
> are going to use (people who already use Emacs/VI can always be given an
> interface to call external editors)
> 
> IMO, the editor part should be a widget deriving from AnjutaDoc. And
> most of the functionality defined in anjuta-doc.c (and more) should be
> provided directly by the editor.

anjuta-bonobo-document.c implements AnjutaDocument, by passing calls
through to a bonobo interface (if one exists).  It would be extended
along with the editor interfaces.
> 
> Please let me know what you think on this issue.

I stand by our decision to use bonobo controls for our editing tasks. 
Bonobo's strong point is loading graphical elements that support varying
degrees of functionality and adapting them to a common interface. 
Already people can use GtkHtml with anjuta2, and use some of the plugins
with it, because bonobo defines a common interface for basic interaction
with document editors.

Yeah, it's a bit more work.  Not a whole lot more work, but more work. 
But it's work that is worth the effort, in my opinion.

-dave