Community
Participate
Working Groups
Using tabs for aligning columns in deep indents is problematic because when a user with another tab setting opens the file it will be a mess. The formatter should instead have an option to use tabs only for leading indents but do deep indents with spaces. IE: public class SomeClass { public void foo() { if ((x.getSomeLongValue == 100) || x.getSomeOtherValue == 200)) { y = 5; } } } The line up of the or clause in the if is done with three leading tabs to the level of the if statement and then 4 spaces to line it up with the parenthesis. Hopefully bugzilla will preserve this.
Will reconsider post 3.0.
This one and Bug 68369 appear to be duplicates - probably should mark one or the other as such. I agree with this request - part of the reason so many people choose spaces instead of tabs (an otherwise silly decision), is because of crap like this behavior of the Eclipse formatter. If tabs are used to line up params, it will looks ugly in some editor configurations and the user will assume that "tabs are bad."
Found another duplicate - Bug 45160
I think this should be considered now. Perhaps Oliver doesnt use tabs for formatting source so he doesnt understand that this is a MAJOR issue for those of us that do. As it is, the whole formatter is near useless to me merely because of this one issue.
I wanted to bring this back up as a goal for 3.1. This is really important for those of us that use tabs for indentation. I dont feel it should be sidelined just because some people on the team dont use tabs. I would REALLY like to see this in 3.1.
Reopened as this is post 3.0 and is really important for tab users.
*** Bug 45160 has been marked as a duplicate of this bug. ***
*** Bug 68369 has been marked as a duplicate of this bug. ***
*** Bug 80348 has been marked as a duplicate of this bug. ***
Any idea, whether this could be done in 3.1? Otherwise we will not be able to use Eclipse in real production code.
Created attachment 19282 [details] Apply on HEAD Tom, could you please review the changes?
*** Bug 73189 has been marked as a duplicate of this bug. ***
/** * <pre> * FORMATTER / Option to use tabulations only for leading indentations * - option id: "org.eclipse.jdt.core.formatter.use_tabs_only_for_leading_indentations" * - possible values: { TRUE, FALSE } * - default: FALSE * </pre> * <p>This is used only if the {@link #FORMATTER_TAB_CHAR } is set to {@link JavaCore#TAB}.</p> * @see #TRUE * @see #FALSE * @since 3.1 */ public static final String FORMATTER_USE_TABS_ONLY_FOR_LEADING_INDENTATIONS = JavaCore.PLUGIN_ID + ".formatter.use_tabs_only_for_leading_indentations"; //$NON-NLS-1$ If the implementation can be reviewe in time for M6, it will get in. Otherwise it will be released after M6. But we need to add the API before M6.
Created attachment 19288 [details] Apply on HEAD Updated patch once the constants have been added to HEAD. No need to push for M6. This can be released after M6.
Just trying out the formatter, I have two cases that don't give me the expected result - but as you said, the implmementation can always be tweaked in M7. -- Example (tab_size=4, indent_size=4): classic example: tab_char= SPACE class Example { ....void foo(int arg1, int arg2, .............int arg3, int arg4, .............int arg5, int arg6) { ........return; ....} } -- ONLY_FOR_LEADING_INDENTATIONS= true tab_char= TAB class Example { --->void foo(int arg1, int arg2, --->............int arg3, int arg4, --->............int arg5, int arg6) { --->--->return; --->} } but should be class Example { --->void foo(int arg1, int arg2, --->.........int arg3, int arg4, --->.........int arg5, int arg6) { --->--->return; --->} } -- ONLY_FOR_LEADING_INDENTATIONS= true tab_char= MIXED class Example { --->void foo(int arg1, int arg2, --->--->--->.int arg3, int arg4, --->--->--->.int arg5, int arg6) { --->--->return; --->} } but should be the same as with tab_char = TAB
For the latter case, ONLY_FOR_LEADING_INDENTATIONS= true tab_char= MIXED, this won't work. This new option would only be enabled in the tab_char is TAB.
(In reply to comment #16) > this won't work. This new option would only be enabled in the tab_char is TAB. why? It makes sense both for TAB and MIXED. The idea would be that the mixed style would only be used for the leading indent, while only spaces would be used for the alignment.
ok, I will reconsider post M6.
(In reply to comment #17) > (In reply to comment #16) > > this won't work. This new option would only be enabled in the tab_char is TAB. > why? It makes sense both for TAB and MIXED. The idea would be that the mixed > style would only be used for the leading indent, while only spaces would be used > for the alignment. This would work fine. There definitely needs to be an ability to use spaces for tabs (although I personally would never use it) but tabs for leading indents is a necessity. I favor this combination of two options.
(In reply to comment #15) > Just trying out the formatter, I have two cases that don't give me the expected > result - but as you said, the implmementation can always be tweaked in M7. Tom, What size do you use for the page width in your example?
Fixed and released in HEAD. Regression tests added in FormatterRegressionTests.test567/568/569. Tom, I tried your code snippet in comment 15 and it works fine now.
Verified for 3.1 M7 using build I20050512-2035 + jdt.core HEAD.
Reopening because "Mixed" mode tabs is still indenting improperly in RC3. The whole point of mixed mode indenting is to make sure that code indented with tabs appears the same on every machine no matter what the tab setting. Consider: public void classifySet(final Set<?> objects, final int value, final long other, final int device) { for (final Object element : objects) { System.out.println(element.getClass().getName()); } } Note that the second line of the argument list is lined up using spaces after the initial tab that lines it up with the numbers. There are no more tabs after the first one. I have my tab size set at 4 but this editor has a tab size of 8 and you can see if I paste in the "mixed" formatted text: public void classifySet(final Set<?> objects, final int value, final long other, final int device) { for (final Object element : objects) { System.out.println(element.getClass().getName()); } } It doesnt line up because of the varied tab size. However my first example will ALWAYS line up. The rule is simple. The phrase is inented to its block level with tabs but then spaces are used to line things up.
The whole point of tab-space mixture is to make the code looks well-aligned independently of the defined tab-size. There are some rules: - use tabs ONLY for leading indentation (convert all mid-line tabs to spaces) - when lines are wrapped, like in Robert's example, tabs must be used like for the first line of the wrapped statement, all further indentation must be spaces Robert's example with ---> as tabs and . as (leading) spaces to illustrate: --->public void classifySet(final Set<?> objects, final int value, final long other, --->........................final int device) { --->--->for (final Object element : objects) { --->--->--->System.out.println(element.getClass().getName()); --->--->} --->}
Entered separate defect for extra comments, see bug 101996
Philippe, could you please describe *what* is fixed with this issue? Thanks in advance.
I would like to know that as well because as far as I can tell, this issue has not changed at all since its inception except that now extra spaces will be added to code to make it line up under one specific tab size. That certainly doesnt address the root issue: namely that leading tab indents are good yet developers often have diferent tastes in tab size. If tab size is 3 and using '-->' to denote a tab, the following code will be the result with the current formatting algorithm: -->public void classifySetTwo(final Set<?> objects, final int value, final long other, -->-->-->-->-->-->-->-->--->..final int device) { -->-->for (final Object element : objects) { -->-->-->System.out.println(element.getClass().getName()); -->-->} -->} However, the result SHOULD be the following: -->public void classifySetTwo(final Set<?> objects, final int value, final long other, -->...........................final int device) { -->-->for (final Object element : objects) { -->-->-->System.out.println(element.getClass().getName()); -->-->} -->} This bug is NOT fixed. Not even slightly fixed.
Regrettably bugzilla cut my example to bits. I think its clear but let me restate. -->public void classifyIt(final Set<?> objects, final int value, final long other, -->-->-->-->-->-->-->-->..final int device) { -->-->for (final Object element : objects) { -->-->-->System.out.println(element.getClass().getName()); -->-->} -->} Should be -->public void classifyIt(final Set<?> objects, final int value, final long other, -->.......................final int device) { -->-->for (final Object element : objects) { -->-->-->System.out.println(element.getClass().getName()); -->-->} -->} To say that this bug is fixed is simply WRONG. The original report quite clearly lays this out in detail. This is the 5th or 6th time this has been made clear in this bug. If this bug is marked fixed again without being actually repaired then this bugzilla system might as well be so much scrap for all the good it does. I dont mean to be hostile but some things just cross the line of ludicrous.
The feature got added, therefore it got fixed from a feature request standpoint. As I understand, you have some grief about the current implementation, and did not raise them in almost 3 months. Given we are closing on 3.1 now, it is too late to change it at this stage. This is why I entered a separate issue to record your last comments. Reopening old bugs is not appropriate here.
Not that I am not disagreeing there is a gap in between request and solution chosen, simply disagreeing the old bug should be reopen.
I just don't understand, IIRC, this issue is no bug, but a RFE. And since it is not solved, it cannot be marked as fixed. Moving it to a new Target Milestone 3.2 (or something like that) would be more appropriate.
This is what the other defect is meant for. This one, as the original one, will remain since it triggered some evolution in 3.1 codebase. The new mode isn't what you asked, but it is definitely mixing tabs/spaces, not quite as you'd like, but some do find it useful anyway. By reallocating the bug to 3.2 target, we would miss the fact that it belongs to 3.1 as well (on release notes etc...). Reopening would have been appropriate within the 3.1 timeframe, but now it is way to late.
This bug wasnt worked on 3 months ago to my knowledge and has never been fixed. it has never once even been altered. Whatever was added to the bug was not what the bug requested. The original post states the issue quite clearly. Moving this bug to another milestone would have merely indicated that the repair of the bug did not make the other milestone. Second of all, you can not dump it on us that the bug wasnt complained about. Someone set to work on this bug and modified code. They didnt read it carefully enough, didnt implement the requirement, didnt test with output given in the post. In short, the attempt to fix the bug was a half measure at best. If any developer working for me tried that .... well ... they just wouldnt out of self preservation. Third of all in Tom P. Eicher's post of 2005-03-30, he once again reiterates the defects that remain after the supposed fix. These comments were patently ignored. Finally, you cant tell me that there is no way to change code at this point. If so then why bother calling it a release candidate and just drop it on the market as done. What is the nature of a release candidate? Simply to say "hey, we think we got it but let us know what is missing and we will fix it for the release." You have just turned eclipse's bug system into a stupid joke. If I tried such a thing with one of my clients they would fire me oh so fast. I can see it now. "Mr. BMW guy, it is fixed because I say it is fixed ... so there. ... :P~~. Just forget about the fact that none of the requirements of the issue were satisfied, it was fixed darnit!" That would be rich; and EXACTLY what is happening here. I re-opened this bug in a friendly spirit of informing them that the bug has not yet been repaired and we are instead fed a line of political BS more suitable for a fortune 500 company than an opensource community effort. Just because you have an IBM email does not give you license to distort the facts to suit your mood. To anyone that uses tabs, this bug makes the eclipse formatter UNUSUABLE. REPEAT ... the formatter is UNUSABLE. A lot of worthless code.
Clarification: this bug wasnt in a stream build three months ago. I cant affort to attempt to use source control builds in professional develoment.
I don't think the preference ever made into the preference page UI - did you enable the preference by editing the preference store by hand to try it out? Otherwise, there is no way you could have tried it out! I filed bug 102007 against jdt-ui to add it after 3.1 ships.
I certainly wouldnt have edited the preference store by hand. And the fact is the continuing defects were in fact reported in MARCH. In my opinion this is a serious credibiltiy issue for eclipse.
After rereading all messages I agree with Robert and Tom, that this (and maybe bug 102007) should be fixed in 3.1. On 30th March you were notified that the implementation does not solve this issue. Maybe it was broken after Olivier reported it as working (comment 21). It is not our task to check the implementation or the regression test. Robert, you as the reporter should be able to reopen this issue.
Oops. I apologize, I got confused with bug 73104. Thanks Tom for pointing at the UI glitch. So to make the story short, the infrastructure has the support you need, but the UI doesn't reveal it. So if you programmatically use the formatter you will find the feature implemented. Still it can be consider as FIXED from the JDTCore standpoint. Sorry Thomas&Robert for taking so long to realize. Resistance is not futile ! <g>
As to fixing anything in 3.1 at this stage, it takes a stop ship defect to block a release. This one wouldn't be considered as such, but I agree that if the feature wasn't implemented, we couldn't still tag it as fixed.
(In reply to comment #37) > [...] I agree with Robert and Tom, that this [...] > should be fixed in 3.1. Just to be clear: I never said I wanted this fixed for 3.1, but rather that bug 97918 (of which 102007 is a dup) is what you are complaining about, while this bug actually has been fixed.
It doesn't seem that the UI has exposed this preference from the code formatter (see bug 97918). As far as I know, this issue is fixed in the code formatter. I added regression tests that cover the test cases in comment 15 and I also checked that your test cases in comment 0 and comment 27 work fine. I spent some time to implement this and from my point of view it works as expected. So I cannot really say that I appreciate your comment 33. "Second of all, you can not dump it on us that the bug wasnt complained about. Someone set to work on this bug and modified code. They didnt read it carefully enough, didnt implement the requirement, didnt test with output given in the post. In short, the attempt to fix the bug was a half measure at best. If any developer working for me tried that .... well ... they just wouldnt out of self preservation." Once bug 97918 is fixed, let me know if you find a bug. It will be a pleasure to fix it. Till then, I consider this issue as fixed. The new options works fine in MIXED or TAB mode.
Verified with I20050627-1435
If I understand correctly, there are two problems: - enhancing the formatting engine to support "smart tabs" - add an option to the preferences dialog to enable this "smart tab"-mode The first one is covered by this issue, the second one with bug 102007. If I understand bug 97918 correctly, it exactly describes the same as this issue which is the same as my reported one (bug 80348). Hence I'm a little bit puzzled, that a) bug 102007 is marked as duplicate of bug 97918 and b) this one is marked as fixed, whereas bug 102007 isn't. How can we (as plain *users* - not as Eclipse developers) try whether mixed tabs work as expected?
Sorry, another note: why is it that hard to finally make us happy by adding the option to the UI (bug 102007)? This IMHO is a very small change and should be possible in a RC.
This is too late for 3.1. It can however be done for 3.1.1. Doesn't mean you have to wait till 3.2 to get it. To clarify, mixed tabs is different from this issue. Mixed tabs is used to replace spaces with tabs when there is enough spaces to make a tab. This issue is not the same problem than mixed tabs. This is why it is a new option and that option is not exposed in the code formatter preference page.
(In reply to comment #45) > This is too late for 3.1. It can however be done for 3.1.1. Doesn't mean you > have to wait till 3.2 to get it. OK, I accept this. > To clarify, mixed tabs is different from this issue. I assume, with "mixed tabs" you mean class Example { --->void foo(int arg1, int arg2, --->--->--->.int arg3, int arg4, --->--->--->.int arg5, int arg6) { --->--->return; --->} } OK, "mixed tabs" are fixed, but they are not covered by THIS issue. We are talking about "smart tabs". "Smart", because the engine needs to know, what line is wrapped and what line is not. The above "mixed tabs" example is a 5-minutes task to implement and should be the default for using tabs (I don't see a need for adding a UI option for "mixed tabs").
(In reply to comment #46) > I assume, with "mixed tabs" you mean > > class Example { > --->void foo(int arg1, int arg2, > --->--->--->.int arg3, int arg4, > --->--->--->.int arg5, int arg6) { > --->--->return; > --->} > } Yes, this is exactly what I mean. > OK, "mixed tabs" are fixed, but they are not covered by THIS issue. I know and this is why I said that this is fixed with a new option called: FORMATTER_USE_TABS_ONLY_FOR_LEADING_INDENTATIONS. > is wrapped and what line is not. The above "mixed tabs" example is a 5-minutes > task to implement and should be the default for using tabs (I don't see a need > for adding a UI option for "mixed tabs"). Not possible. This would break existing clients that rely on previous code formatter behavior. We cannot change such settings without breaking them. This is why there is a new option. It takes about 10 seconds to set it to MIXED and you can define a new profile based on an existing profile. So to conclude all this thread. There is nothing we can change on the JDT/Core side. The next step is on JDT/UI side. THIS issue is fixed and verified with I20050627-1435. It won't be the default as this would also break existing clients. So you will need to create your own profile to change it once it is exposed in the UI.
