Community
Participate
Working Groups
When I type tabs in the normal Java editors, tabs are replaced by spaces because I have set the following preference: Java | Editor | Typing | Insert space for tabs The compare editor however does not seem to use this setting: it keeps the tabs I type in.
I have this same problem 3.1m2, can we have this re-targetted to 3.1 please?
The same is true for C/C++ editors.
I just noticed this in the production release of 3.2 as well. It's a pretty painful one for me. I have to manually spacebar in the compare editor instead of using tabs as we can't have tabs in our Java source.
The problem is that the viewer used in a comparison is not a Java editor so it has none of the niffty Java features.
*** Bug 154306 has been marked as a duplicate of this bug. ***
Re comment 4 --- I have seen this on a regular txt file.
The same applied to txt (i.e. compare makes use of a SourceViewer which has different capabilites than a text editor).
Dani, can you give me some idea of what would be involved in moving the tabbing behavior down from the Java editor into the source viewer configuration that comapre uses?
I suggest to wait because I plan to push this (see bug 82296) down to Platform Text anyway. If all goes well you should be able to simply configure this in the configuration.
Sounds good to me.
The support is now available and can be configured directly on the text viewer (see ITextViewerExtension7.setTabsToSpacesConverter(IAutoEditStrategy)). Create a TabsToSpacesConverter and configure it as outlined in: AbstractTextEditor.installTabsToSpacesConverter() Here's how to find out whether the conversion is enabled: AbstractTextEditor.isTabsToSpacesConversionEnabled() IMPORTANT NOTE: general text editors and the Java editor DO NOT share the same preferences when it comes to tabs width and inserting tabs/spaces. Take a look at the above methods in CompilationUnitEditor for details.
We will investigate for M7, time permitting.
Dani, I've had a quick look at the places you suggested and it looks like the only way I could possibly do this right without adding API is to add the behavior to the source viewer configuration. For basic text files, I would need to subclass SourceViewrerConfiguration and for Java I would need to subclass the JavaSourceViewerConfiguration. Is there any reason why the editor behavior was implemented at the editor level and not in the SourceViewerConfiguration (i.e. do you know of any reason why the approach I just outlined wouldn't work)?
>Is there any reason why the editor behavior >was implemented at the editor level and not in the SourceViewerConfiguration That's not true for the behavior: the work is done by the TextViewer where you can call setTabsToSpacesConverter(...) and there is a TabsToSpacesConverter in jface.text. Now when it comes to the setup/configuration you're right. The main reason I've put it into the editor is because on/off and space size depends on preference and project properties, but I agree that it would also fit well into the SVC. Please file a feature request if you want this for 3.4. Now, I don't see your point regarding subclassing the SVCs: can't you simply check the preference(s) and then call setTabsToSpacesConverter with a TabsToSpacesConverter? Keep in mind that your (Java) compare editor has to update the settings if the input changes as these settings can be project specific for CUs.
What I was trying to say was that I need to implement it in TextMergeViewer in such a way that the JavaMergeViewer can override it without providing API (or have a compare specific setting which is not good). The only point in the current API where this is possible is the TextMergeViewer#configureTextViewer which registers the SVC. Therefore, one approach would be to implement the behavior in the SVCs (one for Text and one for Java). I don't think I could just do it directly in the configureTextViewer method since we need to react to preference changes. I just wanted to make sure there was no technical reason why it could be done in the SVC. I'm starting to think that the right way to do this is to log the request for Text to put the preference handling in the SVC. Without this, it becomes very difficult to describe to compare providers how get the behavior (i.e. they would get it for free if they don't use there own SVC but would need to implement it themselves if they use their own). I've logged bug 179975 against Text for putting the preference handling in the SVC and will defer this enhancement.
I am having the same problem: I'm using eclipse 3.3.2 M20080221-1800 I've changed the global preferences for editors to use spaces rather than tabs General > Editors > Text Editors Displayed tab width: 3 [x] Insert spaces for tabs However, when I reformat an XML file using editor, it replaces all of the spaces with tabs. I have also enabled this option to visually see the tabs: [x] Show whitespace characters.
John, your problem is either wrong XML formatter preferences in your workspace or a bug in the XML formatter but definitely unrelated to the compare editor.
This seems to be working fine, at least in Java compare since we started to embedded a Java editor (see bug 169386). The pref is no longer available under "Java | Editor | Typing | Insert space for tabs" but when I played with "Java | Code Style | Formatter" I did manage to get a result when tab gets replaced with spaces. Could someone verify if my finding is correct, I'm not 100% what expected behavior should be. Text compare doesn't use a text editor so far (see bug 259410), so the pref won't work when comparing txt .
(In reply to comment #18) > This seems to be working fine, at least in Java compare since we started to > embedded a Java editor (see bug 169386). I can confirm that it works the same in the java compare and java editor.
This is fixed in the java compare. It still remains in the text compare, however this is covered in bug 259410.
