Community
Participate
Working Groups
If I'm looking at other people's code or my own, and I want to control the width of a tab, it is not intuitive to go digging around in the settings for a feature that I never invoke directly (the formatter). The display width of a tab is not a formatting preference since it has no effect on the actual output (except in the rare case of converting spaces<--->tabs). "Workbench/Editors/Text Editor" preferences shows displayed tab width which is the obvious place for this preference. The formatter value still makes sense, but it should be labeled as a conversion amount, and not the display size.
IMO the tab display size is very close to the formatter prefs, as if the tab display size is not the same than what the formatter thinks it should be, you get the output all garbled as soon as you use any non-tab indents: - deep alignments of parameters etc - tab-to-space conversion as you mentioned In fact, the formatter preferences are not just used by the formatter when it is inoked directly, but also affect any source-relevant actions such as generating methods, auto-indent, quick fix / assist, refactorings etc. The fact that the value on the text preference page is not respected by the Java editor is misleading, I agree (however, any editor may choose not to respect the text editing settings). Dani, what's your take on this?
> generating methods, auto-indent, quick fix / assist, refactorings etc If I am viewing someone else's code loaded as binary, none of those actions apply. The file is read-only. My own code *never* has anything other than TABs in it, so the displayed width does not affect the output of any of those actions you mention. This is not true for all formatter preferences, but I think it's true for the default "Eclipse 2.1" style. Again, I'm not saying the value is not needed in the formatter, I'm just saying its hard to find, and the formatter value could be set to "inherit" and pickup this new preference, which could also be set to "inherit", and inherit the text editor's preference.
We should add the display tab with to the Java > Editor preference page, at least read-only with a link to the formatter preferences and at best editable with a hint that formatter preferences are changed by changing this value.
The formatter could maintain a separate value. Since the default formatter is read-only, this is probably required anyway. If you want to keep them from getting out of sync, a value of "-1" in the current formatter setting could indicate that the new value on the Editor page should be inherited/picked-up by the formatting settings. That way the read- only formatters would inherit the users preference.
The -1 trick doesn't work because the formatter prefs are JDT Core and can be used without any knowledge of JDT UI.
(In reply to comment #5) > The -1 trick doesn't work because the formatter prefs are JDT Core and can be > used without any knowledge of JDT UI. I think it could still work. CORE would have a setDefaultTabWidth method that UI would call. Any formatter prefs with -1 would call core's getDefaultTabWidth (). The value could be 4 by default.
Related to this bug is the fact that the formatter's Line Wrapping settings does not inherit the displayed Print Margin. So if I increase the print margin to 100, my code still gets wrapped mysteriously to 80. Requiring the user to clone the built in formatter just to get the formatter's line wrap to agree with the displayed print margin is also not very obvious.
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. -- The automated Eclipse Genie.
