Editor Interfaces

[Arun Tejasvi Chaganty]

Hey,
  I have a few questions regarding the implementation of the Editor intefaces.

1) I'm trying to implement the EditorCell interface for the Vim plugin to
get the language-support plugin to work. However, the way it is being
handled currently will not work with the way the vim plugin is
implemented.

The EditorCell requires me to iterate through the file. However, the
file is not managed by me, but by Vim, and I can't share it's data.
While I can shoot a dbus query to vim to find out what a character at a
given location is (with sufficient granularity), it would just be way
too slow and inefficient.

I've mentioned earlier how the vim plugin works, but I'll just mention
it again. I am embedding Vim into Anjuta using a GtkSocket, and then
communicating with it through DBus.

The only way out I can think of is to store another copy of the file and
use it for this purpose. However, I am wondering if it is worth it, and
whether this would cause too much memory to be used (I've seen some bugs
concerning people trying to open really big files). Does anyone have any
input/advice?

2) On a related note, I am worried about the "changed" editor signal, which
also has to be fired through dbus every time a character has been
changed. Though it's pretty trivial to do, I am worried that it will
cause a lag. I guess I'll have to just implement it and see. Perhaps I
could fire a signal every 10 character changes or something...

3) There are some interfaces that have no implementation, atleast among
the editor plugins in the trunk. For example, Hover, Assist, View and
Zoom. Hover is called by the Debug Manager, Assist has implementations
present in the language-support plugin and View has two callbacks
present in the document-manager (but no implementations), same goes for
Zoom. What are they about?

Cheers,
--
Arun Tejasvi Chaganty (vimzard)
GNOME GSoC Student
Blog: http://arunchaganty.wordpress.com


-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Anjuta-devel mailing list
Anjuta-devel@...
https://lists.sourceforge.net/lists/listinfo/anjuta-devel

[Johannes Schmid-4]

Arun Tejasvi Chaganty schrieb:

> Hey,
>   I have a few questions regarding the implementation of the Editor intefaces.
>
> 1) I'm trying to implement the EditorCell interface for the Vim plugin to
> get the language-support plugin to work. However, the way it is being
> handled currently will not work with the way the vim plugin is
> implemented.
>
> The EditorCell requires me to iterate through the file. However, the
> file is not managed by me, but by Vim, and I can't share it's data.
> While I can shoot a dbus query to vim to find out what a character at a
> given location is (with sufficient granularity), it would just be way
> too slow and inefficient.
>  

It does not make much sense to make prediction about performance. Try if
it works and if not we might have to think about another solution. But
we really will not change that interface.
> 2) On a related note, I am worried about the "changed" editor signal, which
> also has to be fired through dbus every time a character has been
> changed. Though it's pretty trivial to do, I am worried that it will
> cause a lag. I guess I'll have to just implement it and see. Perhaps I
> could fire a signal every 10 character changes or something...
>  
See above - try and see.
> 3) There are some interfaces that have no implementation, atleast among
> the editor plugins in the trunk. For example, Hover, Assist, View and
> Zoom. Hover is called by the Debug Manager, Assist has implementations
> present in the language-support plugin and View has two callbacks
> present in the document-manager (but no implementations), same goes for
> Zoom. What are they about?
>  
Sourceview implements Hover and Assist, scintilla implements view and
zoom, they are all optional.

Regards,
Johannes

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Anjuta-devel mailing list
Anjuta-devel@...
https://lists.sourceforge.net/lists/listinfo/anjuta-devel

[Arun Tejasvi Chaganty]

Hey,
> It does not make much sense to make prediction about performance. Try if
> it works and if not we might have to think about another solution. But
> we really will not change that interface.
Ok. Will do. I wasn't thinking about changing the interface at all.

> Sourceview implements Hover and Assist, scintilla implements view and
> zoom, they are all optional.
Sorry, I apologized, I grepped the plugin directory badly (without case
insensitivity).

--
Arun Tejasvi Chaganty (vimzard)
GNOME GSoC Student
Blog: http://arunchaganty.wordpress.com


-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Anjuta-devel mailing list
Anjuta-devel@...
https://lists.sourceforge.net/lists/listinfo/anjuta-devel