This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.
When a file has been opened by an external editor, and the user selects the Open action on a node in the Explorer that corresponds to that file, the file gets opened again, rather than reusing the existing buffer. If the Editor were to provide something like a "vetoable Open listener" interface, an EditorKit could register an interest in Open actions and thus get its OpenListener called on every Open action. If the pathname matches a file that the EditorKit is managing externally, it could return false, which should abort the Open. The EditorKit would then create a JEditorPane for the external file and ask the Editor to display that instead. The current behavior is particularly confusing when the external editor has modified, but not written, the file in question -- you get two copies of the file opened, one with your edits and one without.
IMHO this is rather for openide.text than editor module itself.
Moving to openide.text ovner.
To manage the opening, etc, things from editor seems to be too obscure for me. I guess there should be another solution found. But first I need exactly to know what you need. You means just nothing to be happened when the action is invoked, like if the action would be disabled? Do you need the similar behaviour also for other actions? Please, specify. Yarda what do you think about it, I mean the vetoable listener?
"When a file has been opened by an external editor, and the user selects the Open action on a node in the Explorer that corresponds to that file, the file gets opened again, rather than reusing the existing buffer." Unbelievable: How that can happen, I lived in ilussion that CloneableEditorSupport remembers all references to the CloneableEditors it creates and if open is called one of them is "requestFocused". Does the CES exist in memory or is it garbage collected, etc.?
There seems to be some confusion here so let me try to clarify as much as I can: 1) When the user opens a file (/home/bar/foo.txt) inside external editor (e.g XEmacs), the IDE has no idea that this file is opened in XEmacs (except the external editor module). That's why it's normal that CloneableEditorSupport is unaware of this file. 2) Once opened, the user can edit the file content in XEmacs w/o saving the buffer. 3)If he then goes to the Explorer and double-clicks (opens) the foo.txt in /home/bar tree, IDE will open a new JEditorPane in the source editor window and populate it with the file content from the disk. 4) Subsequently this will cause two bugs to occur: i) XEmacs will open a new buffer with the content of JEditorPane the IDE has created ii) the content of that new buffer doesn't match the content of the previously opened unsaved buffer. Now to fix this we need two things from NB: 1) vetoable Open listener (see Dave's comments): i) External editor kit will register to this listener. This way, in step 3 above, when the user tries to open the file, IDE will iterate over the listeners, and ExtEdKit will return false. Then the IDE will abort as if no OpenAction request has been processed. ii) At that point the externaleditor is responsible of creating a JEditorPane and populate it with the up-to-date content from the XEmacs buffer. 2) A new API to be able to add this JEditorPane to the IDE. Once the IDE has the pane, it can get the editor kit and the document from that pane and then does the some process (as in CloneableEditor, CloneableEditorSupport etc) to add it to the source editor window.
I still think the API change you require is too big attack to current state and too obscure. Yarda what do you think about it? Also I think you don't need it.To the first points. 3) Why let you IDE open the JEditorPane with the original content of the file, you are returning the custom component thru document showing just the label, don't you (as you told us in #20647). 4) Why you open the new buffer with the original content if you don't want to and have already the changed one, you can just show the already changed buffer. From my point I think that's sufficient, please clarify more what I'm missing here? Thanks. Peter
Peter, You are right, implementing NbDocument.CustomEditor for issue #20647 might give me a handle to fix this problem too. When we filed this issue, I wasn't aware of that interface yet. I'll try it and let you know if it works. Thanx.
Melih, how it is with your try?
Peter, I've been working on this bug, modifying a lot of my code as we discussed before and it looks like with those modifications I may not need a vetoable Open listener afterall. I need a few days more to verify that everything is working properly. Afterwards, you can go ahead and close this issue. Thanx.
I am closing this bug since my changes seem to work OK.
verified
*** Issue 19871 has been marked as a duplicate of this issue. ***