Community
Participate
Working Groups
hello, I would suggest the following feature ; be able to rearrange the source code. Why this feature? For instance you sorted your method view in the java browsing perspective to have the methods in alphabetic order. You add then a method . Presently, it will be inserted in the source code where you write the code. The rearrange feature would enable the user to place its method automatically in the right place. regards Xavier
is it like a reformat, or just a different view of the file?
I think it is like a reformat feature applied on all the source file. It is rearranging all the methods and variables. Example : I had : public void toto(... public void albert(... public void zozo(... I would like to have after the processing : public void albert public void toto public void zozo
agreed, that this is a useful formatting option. Some Java formatters provide this kind of support - not for 2.0
Reopening
Will the new formatter consider this
*** Bug 20253 has been marked as a duplicate of this bug. ***
*** Bug 22897 has been marked as a duplicate of this bug. ***
I would really love to see this one also since I prefer to order my methods in alphabetical order. A suggestion for a very fast and easy implementation of the GUI for it: Simply add the setting "oder methods alphabetically" in the Java + Code Formatter preferences. Carl
*** Bug 23209 has been marked as a duplicate of this bug. ***
Another solution maybe to sort the methodes like defined in the preferences. You can configure the order for the outline view. Simply use this settings. It should go into 2.1
I disagree. The formatter doesn't have any knowledge about the outliner. We might add a option to sort alphabetically the body declarations inside a type, but I don't see why we would rely on some outliner settings.
Well, I not really mean the outliner. There are settings for the member sort order. Go to "Window->Preferences->Java- >Appearance->Member Sort Order". The Code Formatter should use this settings if the user wants it. Thus, there is no need to add an additional preference page. Or simply ignore that and only provide alphabetical ordering (statics first).
The new formatter I am working on has much more options than the actual one. Therefore we might need to change the preference page of the formatter and this is a good thing to add on this preference page. For me the appearance and the code formatting need to be clearly separated. A code formatter can be provided through an extension point and therefore we cannot make any assumption on the formatter option through a different preference page.
ACK. Didn't know about your design.
*** Bug 26426 has been marked as a duplicate of this bug. ***
*** Bug 13538 has been marked as a duplicate of this bug. ***
Will this be in M5?
I don't know. The code needs to be integrated within the Java core operations. I will release it as soon as we have something reliable enough. When the support is ready on the JDT/Core side, we still need to add it on the JDT/UI side. So I really don't know if this will be ready in time for 2.1 M5.
The code is released on the JDT/Core side. See the new org.eclipse.code.util.CompilationUnitSorter. The corresponding javadoc might be improved in the next integration build, but the implementation is pretty stable. Fixed and released in 2.1 stream. Regression tests added. Move to JDT/UI for adding the proper UI for this new API. I think we need: 1) A way to map the actual sorting in the outliner with the new API. If I sort the outliner contents I should end up with the same result after sorting using this new API and the default comparator properly initialized (categories values). 2) Provide more predefined comparators (visibility, syntactical order, ...) 3) A new action on IJavaProject, IPackageFragmentRoot, IPackageFragment, ICompilationUnit, on the compilation unit editor.
Martin, you know best what to do.
Working with Jim on the javadoc, we realized that we might need to slightly change the API. Instead of working on ICompilationUnit, it is more flexible to work on IWorkingCopy. So the API might change from using ICompilationUnit[] to IJavaElement[] which will be required to be working copies. Please defer any work on the UI side till we completely finalize this API. NOTE: You might want to prepare all the UI actions anyway.
Move back to JDT/Core till the API is clearly specified.
ICompilationUnit is an IWorkingCopy, so I don't think there is a change needed.
The API is as follows: package org.eclipse.jdt.core.util; public final class CompilationUnitSorter { public static final String RELATIVE_ORDER = "relativeOrder"; public static void sort(ICompilationUnit compilationUnit, int[] positions, Comparator comparator, int options, IProgressMonitor monitor) throws JavaModelException; } We opted to not provide any standard implementation of a Comparator at this time because it's difficult to come up with anything of long-term API value. The DefaultJavaElementComparator from previous iterations of the API will be moving up into the JDT UI, but not as API. This arrangement will allow us to expose a new action for 2.1 based on existing "Window->Preferences- >Java->Appearance->Member Sort Order", which we can easily evolve and improve in subsequent releases. The options parameter on the sort API method allows the functionality to be expanded in a non-breaking way.
Fixed and released in 2.1 stream. Regression test added.
Verified.
Bugzilla Bug 13538 Would like to move fields together (and to the top) was marked as a duplicate (subset) of this Bugzilla Bug. I can not, however, find an option to move fields together at the top of a source file. Can you please provide additional information regarding how Bugzilla Bug 13538 was fixed?
If you go in: Preferences>Java>Appearance>Members Sort Order you can set where you want the fields to be. Then select the compilation unit you want to sort, Right click>Source>Sort Members should do the job.
