Community
Participate
Working Groups
The most important ones here would be settings for the Java formatter and "save actions". Import statements and whitespace always tends to augment the size of a patch. Different contributors from the community have different workspace settings so it is probably not unheard of for these lines to change back and forth after applying one person's patch and another. Having unified settings will help reduce the number of changes to eyeball in the future.
I'm surprised. We are supposed to have project specific settings for this (with it being set to the default eclipse formatter). PW
Last time I ask (it's a while ago) I was told that the UI team could not agree on a common setting and thus we have none. We should try again, and talk about this at the next UI team meeting. I'd vote for the default Eclipse formatter, and the save action being to format the changed lines only.
*** Bug 261077 has been marked as a duplicate of this bug. ***
copied from bug 261077 comment 0: "Related thoughts: (*) Do we really need that 80 char limit for line wrapping in the formatter? (*) Can we enable the Save Actions and do the Organize imports and format the edited lines?" I'd be OK with 100 or 120 characters. Also, +1 for Save Actions to organize imports and format the edited lines.
(In reply to comment #4) > copied from bug 261077 comment 0: > "Related thoughts: > > (*) Do we really need that 80 char limit for line wrapping in the formatter? Yes, standard java coding conventions: http://java.sun.com/docs/codeconv/html/CodeConvTOC.doc.html > (*) Can we enable the Save Actions and do the Organize imports and format the > edited lines?" I'd be interested in this if it would restrict itself to the changed lines ... I don't think we want to introduce differences into CVS that aren't necessary. PW
I'm ok with using the standard but would like to change the 80 column setting to something like 100 or 120. (In reply to comment #5) > Yes, standard java coding conventions: > http://java.sun.com/docs/codeconv/html/CodeConvTOC.doc.html The document says "Avoid lines longer than 80 characters, since they're not handled well by many terminals and tools." and was written in 1999. Not sure which terminals and tools they refer to, but we're using the Eclipse SDK which handles longer lines just fine. > I'd be interested in this if it would restrict itself to the changed lines ... > I don't think we want to introduce differences into CVS that aren't necessary. Yes, agree. Remy suggested using the the "Format edited lines" option.
(In reply to comment #6) > The document says "Avoid lines longer than 80 characters, since they're not > handled well by many terminals and tools." and was written in 1999. Not sure > which terminals and tools they refer to, but we're using the Eclipse SDK which > handles longer lines just fine. handles, yes. displays, not so much. I stretch out my eclipse on my screen, but activating the 80-char print margin tells me I can see about 91 chars in an editor ... If you'd like to move it up to 88 chars, then I couldn't complain :-) PW
(10:30:11 AM) Francis Upton: i don't like horizontal scrolling, but i think 100 avoids that for me (10:31:03 AM) Francis Upton: borisb6i: i think with a reasonable size font and monitor (i use monospace 9) and have only a 17" monitor, 100 is fine (10:31:12 AM) Francis Upton: i think 120 is too long (10:31:25 AM) Francis Upton: and if i had to chose between 120 and 88 i would pick 88
> I'd be interested in this if it would restrict itself to the changed lines ... > I don't think we want to introduce differences into CVS that aren't necessary. > Yes, agree. Remy suggested using the the "Format edited lines" option. +1 for this
Background Info: We have coding conventions linked through http://www.eclipse.org/eclipse/platform-ui/ and we follow the eclipse coding conventions, http://wiki.eclipse.org/index.php/Development_Conventions_and_Guidelines PW
At least when it comes to compiler and formatter settings they are often less aggressive (e.g. set to 'ignore') than they should be due to compatibility reasons. You might want to take a look at JDT project settings. Though quite strict we had very good experience so far. We also use the Save actions but did not yet store them per project because especially formatting changed lines had some issues, however most of which are now solved in latest 3.5 builds.
(In reply to comment #11) > strict we had very good experience so far. We also use the Save actions but did > not yet store them per project because especially formatting changed lines had > some issues, however most of which are now solved in latest 3.5 builds. I would like to try the per-project formatting with formatting auto-applied to changes, if the feedback would be useful. PW
>I would like to try the per-project formatting with formatting auto-applied to >changes, if the feedback would be useful. If you mean regarding formatting, then yes: feedback is always welcome ;-)
Created attachment 130570 [details] workbench settings v01 Released to HEAD PW
Line wrapping at 80 chars is really annoying. Any increase to that limit would make me happier. Is 100 fine with everyone?
>Line wrapping at 80 chars is really annoying. Any increase to that limit would >make me happier. Is 100 fine with everyone? We even have this set to 200, so I'm all in ;-)
(In reply to comment #15) > Line wrapping at 80 chars is really annoying. Any increase to that limit would > make me happier. Is 100 fine with everyone? +1
(In reply to comment #15) > Line wrapping at 80 chars is really annoying. Any increase to that limit would > make me happier. Is 100 fine with everyone? You need to update the coding conventions as well (some links in comment #10) and hold a vote (remember, in eclipse one -1 is a veto :-) So you can post this bug to platform-ui-dev PW
(In reply to comment #15) > Line wrapping at 80 chars is really annoying. Any increase to that limit would > make me happier. Is 100 fine with everyone? +1 from me. We don't use punch cards anymore; it's a mystery why there is a forced line length limit at all.
(In reply to comment #19) > We don't use punch cards anymore; it's a mystery why there is a forced line > length limit at all. Because it shows up in my terminals and annoys me ... but I'm willing to let it slide :-) +1 PW
(In reply to comment #15) > Line wrapping at 80 chars is really annoying. Any increase to that limit would > make me happier. Is 100 fine with everyone? +1 from me for longer lines. The longer the better, but 100 would be a great improvement. I also like the Format+Organize Imports save actions. I am so used to this from the core+equinox projects that I never remember to do it manually anymore when I touch projects that don't have this enabled. If you want to avoid bigger patches you could always run the format+organize over all the projects one weekend to get them all aligned with the settings. Paul: you need to try a variable-width font in your editor!
(In reply to comment #15) > Line wrapping at 80 chars is really annoying. Any increase to that limit would > make me happier. Is 100 fine with everyone? In principle +1, except I'm wondering about how this will affect maximized side-by-side editors or the compare editor.
(In reply to comment #22) > In principle +1, except I'm wondering about how this will affect maximized > side-by-side editors or the compare editor. Well, it won't be as pretty as now. But 98.345% of the time, we use the Java Editor and only the rest of time we use Compare Editor (see, you didn't believe when I said statistics are always cooked :-)) So far there aren't any -1s, which means, I'll be doing the change by tomorrow.
Created attachment 153802 [details] Patch for changing the line width to 100 I've created a new profile and the only change in it is the line width. If we need additional changes, we have to modify this profile.
Patch released to HEAD.
(In reply to comment #24) > I've created a new profile and the only change in it is the line width. If we > need additional changes, we have to modify this profile. Why does it say "Unmanaged profile 'Platform UI'" ? Wouldn't we want the profile saved in the project? PW
Thanks for making the change, Prakash. We should make it for all our projects, though, not just for one. Can we use this opportunity to check that all our project-specific settings are consistent across our projects?
(In reply to comment #26) > Why does it say "Unmanaged profile 'Platform UI'" ? > > Wouldn't we want the profile saved in the project? The profile is actually saved in the project. I guess when JDT says Unmanaged profile - it means the profile is not shared. Not sure of it though. Dani can explain it. Before this, I tried to create a new profile, but that would result in exporting the profile to elsewhere and every one have to import to have the profile. I checked how JDT UI project has done (this unmanaged profile) and followed the same
(In reply to comment #27) > Thanks for making the change, Prakash. We should make it for all our projects, > though, not just for one. Can we use this opportunity to check that all our > project-specific settings are consistent across our projects? Sure.
>Dani can explain it. F1 can too ;-)
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.
