Community
Participate
Working Groups
I have a custom text editor that enters LinkedModeUI for existing text when the <TAB> key is pressed. It seems to work pretty well. I can tab through the "fields" of my text, but as soon as I type a character, the LinkedModeUI seems to exit (all the "boxes" or "fields" disappear and I am left with my plain old text again). When invoking a template, the LinkedModeUI doesn't exit until the user presses <ENTER> or <ESC>. I have compared the code in TemplateProposal.apply() and it seems very much like mine (in fact I used it as a model for mine). The only difference I can see is that there is the use of ensurePositionCategoryInstalled() which uses the InclusivePositionUpdater (which the javadoc instructs the mortal programmer not to use because it is only public for testing purposes). It also adds a position to the document for each potential value for the template variable. I have built a sample which will demonstrate the problem and I will attach it to this bug. Thanks for the help.
Created attachment 25305 [details] Sample plugin to reproduce the problem This .zip file contains a deployable plugin (with source) that should demonstrate the problem.
The attached plugin was built using the wizard and selecting the "Plug-in with an Editor" template. It contains a simple XML editor (generated by the wizard) that I modified to enter LinkedModeUI when the user presses the <TAB> key. This is all done in the createPartControl() method. I simply create positions for the LinkedModeUI for every 5 characters. You should be able to use any .xml file with this editor. Just press <TAB> to enter the LinkedModeUI and then you can tab through the positions. <ESC> and <ENTER> work as expected, but as soon as you type a character in any of the positions, LinkedModeUI exits. Again, thanks for the help and let me know what more information you need. Keith
I am upgrading the priority/severity on this bug, because I have not seen any action on it whatsoever. Let me know if there is anything you need from me. I would love to get this resolved, even if it is something silly I'm doing (or not doing, as the case may be). Thanks, Keith
Tom, please comment.
Oh, I see what you mean now, thanks for the example plug-in. Note that modifying a linked position works when the change is strictly contained within a single position. When adapting linked positions to document changes, currently any change overlapping with a linked position or *occurring at its borders* is considered to modify the position. See InclusivePositionUpdater. This is so in order to include characters typed in at the begin and end offsets of a linked position. In your example, typing a character to replace the contents of one linked position results in three positions being updated: the selected one, and the positions to its left and right. Note that ajacent linked positions do not behave well when a change occurs on their common offset. It is not clear to which position a character belongs that is inserted at the join. Therefore, adjacent linked positions are not supported. We could, however, be a little smarter: if a document change has a length greater than zero and does not overlap with the position (i.e. replaces a document range adjacent to a linked position), we could savely consider the change to not touch the position. This would help you in the described scenario of comment 2. Other scenarios would still not work, though: if you tab to a linked position and press Delete, you end up with a zero-length linked position between two other positions. Inserting characters in that situation would be ambiguous. Are adjacent positions absolutely required for what you are trying to do? What are the semantics that you would suggest for dealing with adjacent positions? Closing as won't fix as there is not much we can do as long as the semantics of adjacent positions are unclear. Please feel free to reopen to continue the discussion.
Thanks for the reply. You have cleared up for me a little of the problem. Let me continue in more detail with my issue. Our text editor basically deals with editing a text file composed of records. Each line is a record with fields defined at certain offsets and lengths. The issue you mentioned where if the user were to delete all text within a linked position and then start entering text again is a problem because there were the three adjacent positions, the one in the middle now has 0 length, so when the user starts entering text again, each of the three linked positions is confused as to whose characters those are. Really, in a fixed width record, the problem is much simpler. Each linked position is defined to occupy a fixed range (unless it is the last in the line, and then it may shrink as the line shrinks). Therefore, the linked positions are only allowed to accept characters within their defined range. If I type some characters at some position in the line, they belong only to the linked position that owns that position, if I keep typing and run into the range of another linked position, then those characters belong to the second linked position. Does this make any sense? We are simply dealing with fixed-width semantics here, not variable width.
I don't think that the described scenario will work well when implemented via linked mode. The entire point of linked mode is that its positions (offsets & lengths) are dynamically updated as you type. In contrast, you want the positions to have a constant length. This is not something we are planning to support - I think it would be better to implement your own solution, possibly by copying and modifying the code of linked mode. Closing as works for me as linked mode works as expected (no bug).
I think copy+paste coding is about the worst approach to solving problems there is , especially when "reusable" object exist. The problem with the current solution on the linked mode is that the classes are not terribly "reusable." I could copy the existing LinkedModeModel class and replace instances of InclusivePositionUpdater with my own version but that sure seems a waste of duplicated code. I could subclass the LinkedModeModel and just override the methods where the InclusivePositionUpdater is used, replacing it with my own position updater again, but then I run the risk of "not keeping up" with changes that are made to the base class. It seems to me that the best solution would be to allow the user to (get this) "plug in" their own position updater, or whatever they like. The comment that you will not support unintended functionality is like saying that Eclipse was intended as a Java IDE and therfore you won't support any functionality that has nothing to do with Java. I have encountered a number of key locations where the "intended" functionality is so locked down that one has to completely reinvent the wheel. This seems contrary to the goals of Eclipse. Open up and let the users/develpers decide how they want things implemented. They can keep the wheel as it is or they can provide their own customizations, or entire reimplementations.
No bug, but an enhancement request then - changing severity accordingly. There are currently no plans to work on this, but a high quality patch (and tests) would be welcome.
.
I agree that copy/paste code is bad but as Tom said, we currently don't plan to work on this unless we receive a good patch.
Get rid of deprecated state.
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant.
