Re: Anjuta2 editor interface limitations

[Jeroen Zwartepoorte <jeroen xs4all nl>]

Hi Biswapesh,

On Tue, 2002-11-12 at 11: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). 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). Add to this things like marshalling /
> de-marshalling and things will slow down dreadfully, esp. for people
> editing a number of big files.

IIRC, the EditorBuffer interface was adopted from a Bonobo interface in
the past. You are correct in that this interface is rather limited in
what it supports. Things like "getWord" sound like a good addition to
it.

> 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. 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).

The big difference between anjuta1/scintilla and anjuta2/glimmer is that
in anjuta2 the editor is only a runtime dependency. The idea is that
glimmer can be used by other containers as well (moleskine2 plans to use
glimmer example. Also nautilus (used to) allow files to be viewed with
glimmer (doesn't work anymore afaik because of changes in nautilus)).

Perhaps the functionality you mention such as completion lists, calltips
etc. could be part of a specific editor interface, since they're very
specific to IDEs.

About the EditorBuffer & Gutter being separate interfaces: that's
because this way, a developer isn't forced to implement the gutter
interface if all he wants to do is make an editor control (does
gvim/xemacs support gutters?).

> 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 ? 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)

Feel free to propose any additions/changes to the interface. Dave & I
are largely responsible for the document-manager code and the glimmer
interface code.

People are also free to write an editor control based on scintilla.
Having more than 1 editor should make for better testing etc. gIDE had
such an editor control, but when it was ported to gnome2, it was dropped
because scintilla wasn't ported at that time. It should still be in some
Attic in the gdl module somewhere.

> 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.

You don't want to derive the editor directly from anything in anjuta2
itself (that would limit it's usability only to anjuta2). I'm quite
happy with the current architecture where editors are only a runtime
dependency and can be changed on the fly. You're right however in that
the editor/gutter interfaces need to be extended to allow for more
functionality.

> Please let me know what you think on this issue.

Thanks for bringing this up.

Jeroen