Custom document and plugin source code

Hello,

I'm currently developing a plugin to include ANTLRWorks (the IDE for ANTLR) into IntelliJ. I've been able to create an editor by implementing FileEditor and everything seems to work fine. However, there is still an issue with document that I cannot solve: how can a specify a custom document? My editor receives the VirtualFile object that it must edit but this file already has a document associated with it. ANTLRWorks has its own document management: I currently need to synchronize the changes made in AW's document to the IntelliJ document using these lines:

Document doc = FileDocumentManager.getInstance().getDocument(AWEditor.this.file);
doc.replaceString(0, doc.getTextLength()-1, container.getText());

This is quite ugly... can I specify to IntelliJ which kind of document to use for a particular file/editor?

Concerning plugin source code: where can I find source code to learn more about plugin architecture? The plugin repositery only contains compiled classes...

Thanks for any help..

Jean

0
11 comments
Avatar
Permanently deleted user

It sounds like it would not be fun to implement Document. You should file a request at http://jetbrains.net/jira for it if you want it though.

Why is the current replaceString method ugly? Maybe if you explain more, we could come up with a better solution.

About plugin source code, many plugins have websites which contain the source code. You can search for the plugin name on google to find them probably.

0
Avatar
Permanently deleted user

It sounds like it would not be fun to implement Document. You should file a request at http://jetbrains.net/jira for it if you want it though.

Why is the current replaceString method ugly? Maybe if you explain more, we could come up with a better solution.

About plugin source code, many plugins have websites which contain the source code. You can search for the plugin name on google to find them probably.

0
Avatar
Permanently deleted user

Yes, re-implementing Document is not fun, that's why I'm wondering if there is any example code for that or any adapter class provided by IntelliJ.

I wasn't really specific about what was ugly, sorry: it is not the replaceString() but the fact that I have to synchronize the changes occurring in my plugin document with the IntelliJ's document. What I want is to be able to beneficiate from the reloading/saving feature of IntelliJ (like the fact that Ctrl-S saves all documents) in my plugin. Because my plugin uses its own internal document, I don't know how to 1) either intercept these IntelliJ event (save, reload) or 2) register my document as THE document for the plugin.

In other word, how can I implement or replace the document object associated with the plugin virtual file?

Thanks a lot!

0
Avatar
Permanently deleted user

This sounds hard, but I don't think implementing a custom Document is what you want. It sounds like you want to listen for changes to the IDEA document, and listen for changes to your custom document, and propagate the changes between them when you receive those events.

0
Avatar
Permanently deleted user

Do you have any idea how to register to listen to those events?

0
Avatar
Permanently deleted user

I guess there's a DocumentListener. Maybe you can add it through the FileDocumentManager. If not, you could try adding VirtualFile listeners and watching fileContentsChanged events.

0
Avatar
Permanently deleted user

Thanks. My current solution is working as follow:

1) I register a file document listener:
FileDocumentManager.getInstance().addFileDocumentManagerListener(...)
2) I implement in fileContentReloaded(), fileContentLoaded() and beforeDocumentSaving() the actions needed to synchronize the document provided by IntelliJ and my internal document.

I think this is the most straigthforward way to do that, right?

There is still some little problems. For example, the isModified() method of FileEditor does not seems to be taken into account when asking IntelliJ to close all editors except those modified: mine is always closed, even if I return true in this method. Any idea?

0
Avatar
Permanently deleted user

I think this is the most straigthforward way to do
that, right?


It sounds right. I've never done something like that.

There is still some little problems. For example, the
isModified() method of FileEditor does not seems to
be taken into account when asking IntelliJ to close
all editors except those modified: mine is always
closed, even if I return true in this method. Any
idea?


It must be a bug. Either the method is incorrectly documented (or not documented at all), or it doesn't work. You should come up with a sample project that reproduces the problem and file a bug at http://jetbrains.net/jira.

0
Avatar
Permanently deleted user

Thanks. But the basic problem still remains: IntelliJ maintains its own instance of document that I have to synchronize with my internal documents. Any idea how to specify my own document instance or how to disable IntelliJ document managment for files handled by my plugin?

0
Avatar
Permanently deleted user

There is still some little problems. For example, the
isModified() method of FileEditor does not seems to
be taken into account when asking IntelliJ to close
all editors except those modified: mine is always
closed, even if I return true in this method. Any
idea?


You have to inform IDEA that the modified flag has changed:
implement addPropertyChangeListener() and removePropertyChangeListener() of the FileEditor interface and fire a PropertyChangeEvent for property FileEditor.PROP_MODIFIED when the modified state changes.

You should select the "Mark modified tabs with asterisk" option in the Editor settings (tab Appearance).
Then you can see whether IDEA has noticed that your editor is modified or not.

0
Avatar
Permanently deleted user

I don't understand why synchronizing is such a problem so I don't know how to help you. It seems to me that listening for document modified events would be enough to synchronize. There is no builtin support for custom documents as far as I know and I think trying to circumvent that would result in an unmaintainable, brittle plugin.

0

Please sign in to leave a comment.