Community
Participate
Working Groups
It would be nice to have an Ant formatter and auto-indent as you type in new subelements.
*** Bug 44710 has been marked as a duplicate of this bug. ***
I too would like to see this - becomes very important as your scripts scale.
*** Bug 49385 has been marked as a duplicate of this bug. ***
I have added the infrastructure required to add a "Format XML" option the 'edit' menu and to configure a formatter for the ant editor. I have spent most of my time reading code for the other formatters in the SDK, exploring the interworkings of ContentFormatter and ContentFormatter2, and experimenting with various implementations of ContextBasedFormattingStrategy. I have a prototype working which formats the entire document by putting each element on its own line and correcting indentations; however, it is dependant on GPL'd code. I now have enough understanding to begin work on the formatting in earnest. The approach I'd like to take is to create at least two different formatting strategies. The master strategy will handle moving elements to their own line, the indentation. A slave strategy will be responsible for formatting individual elements, moving formatting attibutes to their own lines if the element is longer than allowed by the margin, etc. In order to make this work I'll write a SAX handler so that individual regions can be formatted (my current implementation requires a complete DOM). Depending on how things go I may not have time to write the preferences pages for this, so there we have at least one opportunity to multi-thread this project.
I can help on the preference pages. I would need you to indicate the configurability of your formatter...what preferences will it support?
Minimally I'll need a line length (this could be the same as what is now called 'print margin'), tabs vs. spaces, and tab width (if spaces are used). I believe there is already a bug report open on this somewhere. We may want to make the element wrapping optional so you could have a check box for that as well. What other options / functionality are we looking for in the formatter?
I can implement the formatter preferences on an Ant "Work in Progress" page. Of course the goal would be to mimic the formatter for the Java editor. We could start with your set and then spend some time reviewing what the Java editor can do and see what makes sense to have in the context of the Ant Editor.
Created attachment 7625 [details] ant formatter, first cut This is a very rough cut at a formatter for ant. Particularly dicey is the XmlElementFormatter which was hastily thrown together. Note that this patch does not include an auto-indent strategy as is requested by the original reporter of this bug. Of the source I've read for various xml formatters, using a Sax Handler is probably the most common approach. This has the advantage of an established API. On the downside, while SAX 2 does provide an interface for most of what you'd need a few things are still missing--and writing a good handler that covers everything is fairly involved. I've opted for a lighter weight, albeit error-prone approach that doesn't require the document to be fully-well formed before it attempts to parse it. Long term, if the ant formatter is to be robust, giving users the sort of flexibility which exists in JDT, we really should write a full blown model for it. This would require a significant effort. Known limitations: - Newlines for Mac, Unix, & DOS are probably not handled correctly - I may not be using the appropriate definition of whitespace for XML / Unicode - There appears to be a bug in the partitioner which prevents the formatter from correctly formatting elements that have a > inside an attribute value. I believe at least one of the ant committers likes to say: <target description="--> my description"/> so we will want to fix this. - No allowance is made for CDATA sections - I intentionally avoid touching text nodes since whitespace inside a text node may be significant. As a result closing tags for a text node may appear to be incorrectly indented. This is a feature not a bug :)
Clarification: The patch contains no GPL'd code. Both the code and the approach are my own (which is not necessarily to my credit :p).
Created attachment 7682 [details] formatter patch updated for I20040203 Live from EclipseCon...
Patch has been released.
Added the formatter action to the context menu. Added the Ctrl-Shift-F accelerator Added a mnemonic for the action. We should create a "Source" menu for the Ant Editor to be consistent with the Java Editor and move the format action to this menu.
Changes to AntEditor, AntEditorActionContributor and AntEditorMessages.
Thanks for putting the patch up so quickly. I'll try to get some tests in by this time next week. Work remaining: - tests - formatting for comments (in progress) - preferences page - source menu w/ formatting action - auto indent strategy - partioner bugs (see dependencies)
Complete this new feature in M8
Created a new bug report for the Ant formatter preference page: bug 52076
Created attachment 8117 [details] fixes for preferences page and some supporting functionality I'm dashing this off in case I don't get another chance to look at this tonight. This patch cleans up a bit on the preferences side, though it is by no means complete, entirely functioning, etc. In particular the XmlCommentFormattingStrategy is unfinished and broken. Take a look and apply what parts of this look worth-while.
Thanks. I applied the patch. Changes to AntEditorSourceViewer, FormattingPreferences, NonParsingXMLFormatter, XmlCommnetFormattingStrategy, XmlElementFormattingStrategy, AntCodeFormatterPreferencePage, AntPreferenceMessages. Made a small change to handle a StringIndexOutOfBounds in XmlElementFormattingStrategy. Note that with big build files formatting the comments ran out of memory. I marked "Delete blank lines" and "Format comments" as works in progress in the preference pages.
One of the things I am trying to do with the comment formatter is clean up block comments just as the one below. <!-- - - - - - - - --> <!-- my target --> <!-- - - - - - - - --> One difficulty I've had in doing so is that the partition scanner places each comment (e.g. <!-- --> ) into its own partition. This requires my FormattingStrategy to glue partitions together or work with them together--which is rather awkward since the CommentFormatter2 API and ContextFormatttingStrategy APIs assume that only one partition is formatted together and that they are formatted relatively independently from one another. This works fine if the same basic rules apply to each partition, but if--for example--the length the block's top and bottom comment lines were driven by the length of text inside the middle comment, it begins to feel like I am working against the API. My questions are then #1. Does it make sense to redefine our comment partition as beginning with a <!-- and ending after the last --> in a sequence of comments and whitespace with no intervening XML_TAG partitions? #2. Is is possible to define such a partition with the existing rules framework?
Created attachment 8236 [details] minor fix to FormattingPreferences for the sake of tests
Patch applied and released.
Created attachment 8258 [details] ant.tests.ui submission - rough cut at tests I'd appreciate feedback regarding these tests. The tests I read about in Contributing to Eclipse actually check to be sure that contributed actions are in place, etc. Do you want this sort of thing as well? Also I don't test anything besides the engine really responsible for the formatting. Is this acceptable or would you like to see more of the framework tested?
We currently do not check for contributed actions etc. in our other UI tests. I will attempt to look at this more tonight.
Patch applied and released. The tests look like a great start to me. I modified the names of the test methods to reflect what they are testing. I added the tests to the AntUITests suite so that they will be run as part of the Ant UI test suite. As such there was no need for the AntEditorFormatterTests class. I think that the test could be improved by making use of manipulating the AntUIPlugin preferences instead of using a fake FormatttingPreferences class. This way the default settings as indicated in the "real" formatting preferences are tested as well as the formatter correctly adapting to preference changes within the AntUIPlugin preference store.
In preparation for closing this bug in M8 I created the following additional bugs to tackle in M9. bug 54452 ant formatter should handle DOCTYPE and entities bug 54453 ant formatter should format comment blocks bug 54455 ant formatter should have option of removing blank lines bug 51215 fix partioner to handle angle brackets in attribute values. bug 54461 add an AutoIndentStrategy to ant editor bug 54458 formatter swallows text when attribute values include --> bug 54462 ant formatter should respect CDATA sections Work which remains before I close this (hopefully by I20040316): - complete tests for element formatter - finish rewriting the element formatter so that elements are always parsed and formatted. This allows a user to uncheck the "wrap elements" preference and have elements appear on a single line. Originally I intended to give users the option of not having elements formatted at all so as to allow them to preserve their own custom wrapping. I now plan to see if we get an enhancement request before adding this support. - improve tests for preference page
Created attachment 8595 [details] tests for new functionality
Created attachment 8596 [details] now tag formatting has its own model With these changes tags are always parsed and reformatted. This allows one to alter preference settings for tag formatting and have the tags reformatted appropriately. In previous versions, once the user elected to wrap elements, they could not be 'unwrapped'. This also cleans up many other outstanding issues of XML compliance including handling of single and double quotes, tolerance for whitespace, support for xml namespaces, etc. (The antlib functionality uses namespaces).
Can we close this?
I will apply the patches, review the code and do some sniff testing. Then I will pass this bug to another committer for final review (likely DarinW who logged the bug report...the reporter gets the final say on whether the bug is fixed or implemented :-) ) Then the bug will be marked as verified.
I have released the patches.
BTW I have not profiled the code yet.
DarinW please verify that a basic formatter has been implemented. We will log other bugs as the need arises.
To be verified.
Verified.
