This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.
- Jalopy's configuration is extremely high-granularity which is great for a code-formatter. - Our internal code formatter has been stagnent for a while. So I propose we simply integrate Jalopy as *the* standard formatter. This should be pretty easy except for one thing: - If the code is not in a compilable form, Jalopy complains; we should retain the internal-formatter's silent behavior and handle this condition gracefully.
Changing subcomponent to formatting.
Tried it out in Netbeans 5.0 and Mustang :- 1) It is far too complex to comprehend, esp since all its presets are different (and intrusive enough) from what I am used to, hence I am forced to look through the settings one by one; and with all its terminology and settings I am all the more confused. 2) May be I have not figured out a way to do this, but I cannot get jalopy to leave blank lines between Class brackets and the rest of the code, but not to leave blank lines between Method brackets - so although it is high-granularity (hence perhaps a valid excuse for its user-unfriendliness) it is not good enough.
Are all stakeholders satisfied that this is fixed by the new 6.0 code formatter? If I don't hear otherwise I plan on closing this issue as FIXED in the near future.
I guess I am not a "stakeholder". But to me this should not be closed until this matching feature in Jalopy is implemented in the new formatter: 103830 That is the one key feature that makes the Jalopy formatter "surgical" enough to re-organize "totally messed up" classes in terms of format: It re-organizes the entire class purely based on the format configuration while ignoring user specific touch. This is very useful if one needs to present a company's entire code base in a uniformed manner - no developer specific formatting. Of course this had better be an option that can be turned on and off in case some users/shops prefer not to have it that way.
wqtnetbeans, Are you asking for a way to batch-reformat files across an entire file based on some external formatting configuration file? I tried looking up issue #103830 but it was unrelated. Is there an open RFE for this?
gtzabari, Sorry if I was not being clear. No, I did not mean a batch formatting on multiple files (although that is a desired feature that exists in other IDEs). What I asked for is just the RFE 103830 itself ("sense-making line wrap"). It's very crucial to have that feature in order to format one Java file purely basing on format configuration while eliminating all developer specific touches: All developer typed wrapping will be ignored/eliminated, and the whole Java file wrapping is re-done based ONLY on pre-set configurations. Thanks!
wqtnetbeans, I thought the new code formatter already does this. That is, so long as you set your configuration to anything other that "leave as is" it will always reformat the code regardless of the original format. Isn't this what you are asking for? FYI: I'm not a Netbeans developer, I'm just a normal user.
I see. If the new format really does that already (last time I checked with M10? it still didn't), that's great news. Yes, I'd be satisfied with that feature available: Rest of the unmatched features can be taken care of by individual RFEs, as long as this key feature is in place.
Please check the latest dev build and let us know whether it meets your requirements.
Yes, I checked and it does that already. That's great. I'd be nice to have the option of "removing extra blank lines" if there are more than 1 (or any configured threshold number) blank line between 2 statements/expressions. But that's something I can live with for now compared to the line wrapping feature. Thanks for opening this RFE. I think it's a great one although it was never implemented - It might've saved some effect on the dev side compared to write something new as in 6.0. Anyways...
Can we close this FEATURE in light of the 6.5 feature-set?
I'd say close it as it evidently will not be done. However there are a large number of features that Jalopy provides that have no equivalent in the current formatting feature set. Netbeans own formatting features are reliable but basic. It seems a pity that this module which provides an excellent basis for extending this is left behind. I have attempted to work on it myself from time to time but haven't the requisite skills or experience on the NB platform to be successful.
@Dusan: I propose to close this issue as invalid/wontfix. The OSS variant of jalopy is stuck in 2005. [1] Even the commercial jalopy is stuck in 2010. [2] [1] http://jalopy.sourceforge.net/index.html [2] http://www.triemax.com/products/jalopy/history.html So neither will currently support the new syntax elements (diamond syntax in JDK7/lambdas in JDK8)
I agree, mostly because Netbeans' built-in formatter has advanced by leaps and bounds over the past 10 years. I think it's good enough now to forget about Japoly.
I'm going to go ahead and close this issue for the aforementioned reasons.