Community
Participate
Working Groups
The formatter should format comment blocks such as appear in the comment below. This means aligning the block itself (done), aligning the text within the block and making sure that each line of the comment is the same length. We could do this a couple of different ways: 1. The comment block width is determined by the text within the block (upto a certain length at which point wrapping begins), or 2. The comment block is always a standard width (specified via a preference) and additional text is wrapped inside the block. Some allowance should be made for a comment block before the project element which is full page width.
Comment from bug 40255. (This ought to be posted to the text newsgroup). --- 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?
I'll do this for M9.
> Is is possible todefine such a partition with the existing rules framework? It is possible to write a partition scanner this way as I learned in the fix for bug 51215, unfortunately this isn't going to happen in time for 3.0
As of now 'LATER' and 'REMIND' resolutions are no longer supported. Please reopen this bug if it is still valid for you.
