Vim Editor Plugin - Questions regarding DocumentManager

[Arun Tejasvi Chaganty]

I've reached a point where I have start working around the
AnjutaDocumentManager. I'd like some feedback/advice on how I should go
forward.

The Problem:
a) Vim handles multiple documents.
   Both the previous editors were text widgets, however, Vim is a
complete program. Closing up vim so that it's not possible to open other
files is hard because it is very flexible, and there are always ways. A
(vim) plugin somebody loads or something else might open a file, and
screw things up. Further more, I think this is a bad solution, because
one reason people use vim is because it is fast and convinent to move
and copy/paste between open files.
  Another feature a lot of Vim users use is to use ctags or cscope (I
think we may be able to hook something here), and navigate through tags
across files. Technically, this could be handled from outside, by firing
DBus signals to tell Anjuta what vim's doing. I just think that it'd be
reimplementing something Vim already does extremely well.

Solution #1:
   What I would like to do would be to make the vim widget a singleton
of sorts, and generate dummy notebook tabs. When you click on a tab, it
would tell vim to change files. Similarly, when you change files in vim,
it tells Anjuta to change the current buffer. It sounds a bit hackish,
but it's the only idea I have.
   In trying to implement this, I've run into a simple issue, how do I
create dummy tabs. The editor_factory_new_editor function returns a
'editor widget', that subclasses a container, and implements the
functions.
Solution #2:
   Make the vim widget a singleton completely, and send anjuta a copy of
the same. Handle the deletion of when the tabs are closed.

The Problem:
b) Vim lets you view multiple files at once.
   You can split your view into multiple widows, where you can either
open the same file or another. This is genuinely useful, and used
(generally if you have two functions you want to look at the same time).
Solution #1:
I don't know anyway to support this from Anjuta, other than changing
Anjuta's 'current-buffer' to the file in which the cursor is.

Waiting for feedback.

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

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


-------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php
_______________________________________________
Anjuta-devel mailing list
Anjuta-devel@...
https://lists.sourceforge.net/lists/listinfo/anjuta-devel

[Arun Tejasvi Chaganty]

Johannes spoke to me on IRC, and suggested a reimplementation of the
document-manager. I've gone through the existing code, an while it is a
bit, I think I may be able to justify this on the grounds that such
functionality would no doubt be required by a hypothetical emacs plugin.

However, I would like to ask if I could create another interface,
IAnjutaEditorMulitple, which is a editor that can handle multiple
documents. The editor would need to 'manage' these files, i.e.
adding/saving/removing, them (though that can be done per document as
well, via the IDocument and IFile interfaces); essentially a subset of
the functions that the DocumentManager already has. The only difference
being that you could have single documents and a group of documents
handled by the same DocumentManager. Single documents include Glade
files, <insert future special documents here> (I think this would
happen). The document 'group' would be handled by the VimEditor (and the
EmacsEditor), i.e. anything with the EditorMultiple interface.

The EditorMultiple would just hold a list of the files it has opened.
When a file is opened, the DocumentManager checks if the current editor
is a  EditorMultiple, in which case, it calls a add_document on the
editor (which would add this document to it's list). Otherwise, it
treats the file normally. Largely most document functions will not need
to be touched, only those which modify the document list (add, remove).
The current document will still point to the right document (the
EditorMultiple must see to this), saving documents is still the same.

This interface might have the following:

---
/* properties */
"document-list" -> GList<IAnjutaDocument>

/* signals */
"document-added"
"document-removed"

/* methods */
add_document ()
remove_document ()
---

The changes to the existing document-manager would be addons (and not
that many) and shouldn't affect existing usage of the plugin.

Comments?

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


-------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php
_______________________________________________
Anjuta-devel mailing list
Anjuta-devel@...
https://lists.sourceforge.net/lists/listinfo/anjuta-devel

[Sébastien Granjoux]

Hi Arun,

Arun Tejasvi Chaganty a écrit :
> However, I would like to ask if I could create another interface,
> IAnjutaEditorMulitple, which is a editor that can handle multiple
> documents. The editor would need to 'manage' these files, i.e.
> adding/saving/removing, them (though that can be done per document as
> well, via the IDocument and IFile interfaces); essentially a subset of
> the functions that the DocumentManager already has.

It seems interesting. But couldn't it possible to reuse the already
existing IAnjutaDocumentManager interface instead of creating the
IAnjutaEditorMultiple ?

So the vim plugin will implement IAnjutaEditor and
IAnjutaDocumentManager. We need to allow a IAnjutaDocumentManager to
include editors and other document managers. It's just an idea that I
have just had, I haven't though a lots about this and I have perhaps
miss something obvious.


Then, I don't know how it's planned. But for an user point of view, when
I open a new buffer with the vi plugin, I would like to get a new tab
for it like with other editor. So I can switch to another buffer using
the normal vi command or  just clicking on the tab.


For the multiple view of one file, I think it would be an useful
feature. So you should keep it in the vi plugin, but it would be even
better if we can get it with other editors too.

Best Regards,

Sébastien

-------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php
_______________________________________________
Anjuta-devel mailing list
Anjuta-devel@...
https://lists.sourceforge.net/lists/listinfo/anjuta-devel

[Arun Tejasvi Chaganty]

Allo Sebastien,
Merci beaucoup pour votre replie (And that's the extent of my
french). Please bear with my long reply.

> It seems interesting. But couldn't it possible to reuse the already
> existing IAnjutaDocumentManager interface instead of creating the
> IAnjutaEditorMultiple ?

In short, yes and no. This is infact what jhs had initially
suggested. Just a brief detour. So far, a lot of problems (infact all)
I face are due to the fact that the DocumentManager implicitly assumes
that every document is *also* an editor. This makes sense in the cases
of GtkSourceview or Scintilla, but not in the case of emacs or vim,
where the editor is a seperate program.

Back to the DocumentManager/EditorMultiple discussion, there is the
problem of integrating both *kinds* of 'documents', namely those that
are managed by an editor (vim), and those that are editors themselves,
as in the case of the GladeUI Designers (I think you referred to this
problem in para 2 of your mail). I didn't know what else to do so I
thought I'd introduce an interface that tells the document manager that
the 'editor' is a seperate program (this is part of the implementation
details of an EditorMultiple). That and there would be a lot of
reimplementation with creating the DocumentManager.

Please tell me what you think of this.

> So the vim plugin will implement IAnjutaEditor and
> IAnjutaDocumentManager. We need to allow a IAnjutaDocumentManager to
> include editors and other document managers. It's just an idea that I
> have just had, I haven't though a lots about this and I have perhaps
> miss something obvious.
Yes, this would be an alternative solution. I'm not sure how to proceed
with such a solution. I'm worried because there are lots of places where
we have IAnjutaShell->get("IAnjutaDocumentManager"), which would now
break, as there'd be a list of DocumentManagers. If you can give me some
direction on this, maybe we could work this out instead.

> Then, I don't know how it's planned. But for an user point of view, when
> I open a new buffer with the vi plugin, I would like to get a new tab
> for it like with other editor. So I can switch to another buffer using
> the normal vi command or  just clicking on the tab.
Though I've tried to do this (and not fully succeeded), I'd like to
first mention that there is a very nice plugin that displays all the
tabs on the top of the vim page. This doesn't look nearly as beautiful
as the GtkNotebook tabs, but it works great.

I tried to see if this was possible by handling the "page-added" and
"switch-page" signals. I ran into two issues, the first being that I
can't have an empty notebook page (say just a GtkFrame), because the
DocumentManager assumes that each page is a Document and an Editor. I
also tried reparenting the same widget on each page, but throws a lot of
errors, and acts very unpredictably (segfaulting sometimes). I believe I
can get this to work, but given the vim plugin, I thought it was
unneccesary.

> For the multiple view of one file, I think it would be an useful
> feature. So you should keep it in the vi plugin, but it would be even
> better if we can get it with other editors too.
Yup :-). Actually, it's very hard to *stop* vim from doing something, so
the feature is in :-P. Implementing it in other editors would require
some changes to the parent widget (that gets put into a notebook page).
It should be possible if we can have the same thingy that Anjuta has to
dock widgets, only for just this window.

A bien tot!

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


-------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php
_______________________________________________
Anjuta-devel mailing list
Anjuta-devel@...
https://lists.sourceforge.net/lists/listinfo/anjuta-devel

[Sébastien Granjoux]

Hi Arun

Arun Tejasvi Chaganty a écrit :
> Merci beaucoup pour votre replie (And that's the extent of my
> french).

Thanks for your effort. replie exists in french but hasn't the same
meaning, the right word is rather "réponse". Anyway, I don't care that
much, I'm probably writing more than 95% of my mails in english here and
at work.

> Please bear with my long reply.

No problem neither, you can see in the mailing list that I'm writing
rather long mail myself.

> So far, a lot of problems (infact all)
> I face are due to the fact that the DocumentManager implicitly assumes
> that every document is *also* an editor.

Ok but in this case, perhaps it makes sense to break this assumption and
by example add to IAnjutaDocument, one function like
IAnjutaEditor * ianjuta_document_get_editor (IAnjutaDocument *doc,
GError **err).

This will need quite some changed in other plugins, those directly
convert a IAnjutaDocument to a IAnjutaEditor. But if it solves your
problem, I think it could be a solution. For the moment, I prefer to
make something cleaner at the expense of changing an already existing
interface. But I don't know the opinion of Naba and Johannes about this.

> Back to the DocumentManager/EditorMultiple discussion, there is the
> problem of integrating both *kinds* of 'documents', namely those that
> are managed by an editor (vim), and those that are editors themselves,
> as in the case of the GladeUI Designers

I'm thinking a about this....
...I'm not sure that IAnjuteEditorMultiple is the best solution as it
makes the use of the IAnjutaDocument interface more difficult.

By example, in the debug manager plugin if I need to set some
breakpoints in all open files.

Currently, I'm listing all documents inside the document manager, find
if each document contains breakpoint or not and if it contains
breakpoints, I get the corresponding editor and set the breakpoint.

With your new interface, I need to get all documents, if it's a simple
editor and I can continue as before, but if it's a multiple editor, I
need to get all documents handled by this editor (is it possible ?) and
continue.

I find this a bit annoying because every plugin having to do this kind
of operation need to take care of the difference between a normal and
multiple editor. I think it would be better handled inside the document
manager or even better inside the editor plugin.

I have reread your first mail, I think your first solution seems fine.
You can still have document objects implementing IAnjutaDocument and
IAnjutaEditor but most of IAnjutaEditor functions will be done by
forwarding the request to a common vi object.

You probably need to add some functions to create dummy tab though. It's
probably more work to pass all message between Anjuta and vi to keep
both synchronized. But on the other hand, if the vi plugin is able to
change the displayed buffer without warning Anjuta, I'm pretty sure that
some things will not work.

> Yes, this would be an alternative solution. I'm not sure how to proceed
> with such a solution. I'm worried because there are lots of places where
> we have IAnjutaShell->get("IAnjutaDocumentManager"), which would now
> break, as there'd be a list of DocumentManagers.

Yes, you're right. After writing the comments above, I think that having
more than one document manager is not necessary and will give some troubles.

> Though I've tried to do this (and not fully succeeded), I'd like to
> first mention that there is a very nice plugin that displays all the
> tabs on the top of the vim page. This doesn't look nearly as beautiful
> as the GtkNotebook tabs, but it works great.

Sometimes, I don't care much about the appearance of graphical interface
but I think I have already seen these tabs and they looks really odd. I
think it's much better if we can get the exactly the same tab (with the
same behavior) than with other editor.

Then, you are doing the work so it's up to you to decide. Here is just
my own idea.

>> For the multiple view of one file, I think it would be an useful
>> feature.
> Yup :-). Actually, it's very hard to *stop* vim from doing something, so
> the feature is in :-P.

Fine, but I think it needs some changes in the document manager, because
with this you can display several editor at the same time which is not
possible currently.

I think in particular about the "document_manager_current_editor"
variable that give the current editor. I think we should keep it as the
editor where is the cursor.

But, in some part of my code, it is used to know which editor is
displayed and it will be a problem for vi. So I think we need to add
some signal by example "editor-shown" and "editor-hidden" in order to
track which editor are displayed. We can add "editor-current" signal to
avoid using the "document_manager_current_editor" variable which I find
not very easy to use.

> Implementing it in other editors would require
> some changes to the parent widget (that gets put into a notebook page).

OK, let this alone for the moment.

Regards,

Sébastien

-------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php
_______________________________________________
Anjuta-devel mailing list
Anjuta-devel@...
https://lists.sourceforge.net/lists/listinfo/anjuta-devel