Community
Participate
Working Groups
Eclipse Platform Version: 3.1.0 Build id: 200412162000 Starting from 3.1 M4 it is no longer possible to control the displayed tab width in the preferences. This breaks backward compatibility and makes it really hard to edit code written in legacy editors (vi). We can not do away with this setting, it is still needed and it should be put back either in the code formatter preferences or where it used to be in the editor preferences. The Eclipse environment I work in is configured so that tabs are treated as 4 spaces and spaces are inserted, however, if I edit code written in vi, I want tab characters to be treated as 8 spaces for formatting to look predictable. I can no longer do this.
You can control it: General > Editors > All Text Editors
Alright, so the setting is available, but it seems it doesn't do anything. If I set displayed tab width to 8 spaces in all editors and in java formatter I set tab to be 4 spaces, and open a java file edited in vi with tabs used, the displayed tab width is 4 not 8 as my settings says it should be.
Please note that this only happens with java files, i.e. if I open a plain text file, its tab chars will be treated as 8 spaces as expected (with the above settings). Tab characters in java files are treated according to java formatter preferences, which seem to override all editor settings, but they shouldn't. I still want my tab to be replaced by 4 spaces when I edit in Eclipse, but I want existing tab characters be treated as 8 spaces (those tab characters are from vi files).
So you want this: - a preference that controls the visual size of tab characters - which overrides whatever you have specified in the formatter preferences If bug 73104 makes it into M5, you could have what you request by setting tabSize=8, indentationSize=4, useTabs= false. Please correct me if I am wrong. Marking as dependendent on bug 73104 - we'll find out in the next couple of days whether it will be in M5 or not.
Fixing bug 73104 fill fix this bug - marking as dup. *** This bug has been marked as a duplicate of 73104 ***