Community
Participate
Working Groups
I like code formatter in eclipse very much - but I think one more feature wiuld be useful. Sometimes I have some parts in my code - for example several constant declarations which I would like to remain formatted as I entered them. For example not to be wrapped to max line length and all assigments remained in one column. I can format my code part by part, but I was thinking if it would be possible to create some tags in comments which would turn on/off code formatter. Here goes my example: /* here goes my constants: @@formatter:off */ public static final int FIRST = 1; public static final int SECOND = 2; public static final int AND_THE_LAST_ONE = 3; /* @@formatter:on */ Best regards to whole team, Piotr Gawronski (happy eclipse user)
Nice suggestion. Will keep for later
Resurrecting for 3.0
Reopen for 3.0 consideration.
No plan to add such ad-hoc comments.
*** Bug 76435 has been marked as a duplicate of this bug. ***
*** Bug 91902 has been marked as a duplicate of this bug. ***
We really need this feature to prevent the code formatter from reformatting the change log we have in every source file.
*** Bug 103302 has been marked as a duplicate of this bug. ***
*** Bug 193498 has been marked as a duplicate of this bug. ***
*** Bug 239473 has been marked as a duplicate of this bug. ***
*** Bug 282187 has been marked as a duplicate of this bug. ***
(In reply to comment #5) > *** Bug 76435 has been marked as a duplicate of this bug. *** (In reply to comment #6) > *** Bug 91902 has been marked as a duplicate of this bug. *** These two bugs are in fact duplicates of bug 198074...
I am a refugee from https://bugs.eclipse.org/bugs/show_bug.cgi?id=282187 which has just been marked as a duplicate of this, which is in a WONTFIX status. I am myself a developer and we also have a bug tracking system run by Bugzilla. What we mark as WONTFIX is: - a feature that's been misunderstood by a user and considered by them as a bug - something that is caused by some code we are not responsible for and we can't/don't want to fix - a problem that's beyond product scope - a feature request that appears as insane (99% of these are also out of scope) In any case, the bug report is blatantly either irrelevant or whimsical. My background language is C++ and aligning constant values is practically tradition. I kept that habit when I moved to Java and I'm sure that even people who have never written a single line in C or C++ are in need of this feature. I'll attach screenshots of file defining an enum type as it is currently and after I hit Cmd+Maj+F for formatting. Please take a look at it and reconsider your decision. How does that deserve a WONTFIX ? I can read (https://bugs.eclipse.org/bugs/show_bug.cgi?id=27079#c4) that supporting such "ad-hoc comments" is not an option. OK. What are annotations for ? How different would a "@formattoggle" or "@formatoff" be from a "@deprecated" ? or from a "@parameter" in a Maven plugin ? How different would a '@JavaFormatter("off")' be from a '@SuppressWarnings("unused")' ? I'm not a technical expert at Java/JVM/Java Compiler but to me, these are pretty much alike, aside from some being standard and contextualized. The editor comes across a @deprecated in Javadoc and marks the class/function/field. The compiler comes across a @SupressWarning and avoids outputting a warning. The formatter comes across whatever annotation toggles/deactivates:activates formatting and takes the appropriate action. Which, as far as some users are concerned, is not formatting. Is it consistent ? or does the "won't fix" really mean "we don't want it to be done" or "we don't have time" ? I have a proposition: the formatter should leave any "internal" tab alone. By "internal" I mean "that is neither leading nor trailing". Anyway, why does the formatter remove those tabs? OK, they are not significant for the compiler but it's not a reason!
Created attachment 159311 [details] Screenshots of an enum type definition
Created attachment 160613 [details] Proposed patch + doc We will finally try to address this requirement for 3.6 :-) This patch implements our proposed solution for disabling/enabling the formatter in a code section...
Created attachment 160659 [details] New proposed patch + doc This version allow only one disabling tag and only one enabling tag. The doc has been updated accordingly and some typo and inconsistencies have also been fixed... Thanks Dani for having taken the time to review it :-)
(In reply to comment #17) > Created an attachment (id=160659) [details] > New proposed patch + doc > Released for 3.6M6 in HEAD stream.
The current wording in the Javadoc of the new options in DefaultCodeFormatterConstants would not allow us to support multiple tags in the same property in the future, since the contract also applies for clients that *read* the property. To keep this open , you could write: * <li>The tag currently cannot contain newline characters but it can * contain white space.<br> * E.g. "<b>format: off</b>" is a valid disabling tag.<br> * In the future, newlines may be used to support multiple disabling tags.</li> ... and when you read the tags, stop at the first newline, so that if we add this support later, shared preference files won't break old clients. Furthermore, * - default: <code>null</code> looks strange to me. Shouldn't the default be ""? And this also wouldn't hurt: * - possible values: String, with constraints mentioned below
> This version allow *only one* disabling tag and *only one* enabling tag. Hi, I suppose this decision comes from technical limitations. In fact, I'm sorry to see that this solutions won't suit us for instance... Our use case is the following: we use a code generator that lets us modify some code part identified by some //START ... // END tags. And there can be a lot more that just one start and end tag... And I'm pretty sure I'm not an the only one who will run in this limitation. What's the rationale or the technical limitation that led to this choice of allowing only one disabled formatting section? Thanks a lot. Cheers.
Reopening for Javadoc clarifications (comment 19). (In reply to comment #20) > > This version allow *only one* disabling tag and *only one* enabling tag. > > [..] this solutions won't suit us [..] The current solution will fit your needs perfectly. You can have multiple sections in your code where formatting is disabled. The limitation is just that you can only define a single START and a single END tag. E.g. you cannot configure the formatter to not touch code surrounded by //START <no-go-area> //END and in the same project also use //BEGIN <no-go-area> //STOP
(In reply to comment #19) > The current wording in the Javadoc of the new options in > DefaultCodeFormatterConstants would not allow us to support multiple tags in > the same property in the future, since the contract also applies for clients > that *read* the property. To keep this open , you could write: > > * <li>The tag currently cannot contain newline characters but it can > * contain white space.<br> > * E.g. "<b>format: off</b>" is a valid disabling tag.<br> > * In the future, newlines may be used to support multiple disabling tags.</li> > > ... and when you read the tags, stop at the first newline, so that if we add > this support later, shared preference files won't break old clients. > I agree to let the door opened for multiple tags, but I'm definitely not convinced that newlines is a good separator for multiple tags. I'd rather use the comma as separator because I think it should be the same than for task tags... Olivier, what is your mind about this?
For now let's go with the current approach and allow all chars except newline. If we go for multiple tags in the future we also have to decide whether we allow any combination of disable/enable tags or whether they have to be provided as pairs. Frédéric, please clarify the Javadoc.
(In reply to comment #23) > For now let's go with the current approach and allow all chars except newline. > If we go for multiple tags in the future we also have to decide whether we > allow any combination of disable/enable tags or whether they have to be > provided as pairs. > > Frédéric, please clarify the Javadoc. Done
Thank you for the addition. It's more than I was expecting since I did not even think of the possibility that users get to define what the enabling/disabling tags would be.
Added the UI.
Hi, Just spent some time having a look at the 3.6M6 integration build, and something bugged me. Actually, I'd like the logic of the disabling feature could be optionally reversed (adding a simple checkbox in the UI could do, btw). In fact, the feature is currently described in the UI: [...] - At the beginning of the file, the formatter is enabled [...] What we do in our code is generating something like this: package ... // generated import list import ... //[START:imports] Here you can add your own imports //[END:imports] public class ...{ //[START:somecode] //[END:somecode] } But the place where you're allowed to put your own code is IN the sections identified by START/END couple, not outside. With the current feature, we would be forced to reverse the logic by ourselves by 1) adding a fake //[END tag at the beginning of the file, and another fake //[START] tag in the end of the generated 2) setting Off tag as the //[END one, and On as the //[START one. Though it seems feasible, I hope you'll the quite illogical aspect for this :-). To sum up, here's what I hope will be done: "add a reverse attribute to the formatter, so that the identified sections will be the only sections to be formatted". Thanks in advance for your opinion about this.
(In reply to comment #27) Hi Baptiste, there's something that I don't quite get in your comment but after reading it several times, I still can't put my finger on it. Why would the 'illogical' aspect of starting the generated file with the "formatter off" tag would bug anyone ? Since we got to choose the string that would trigger the off status, you can use something quite "plain" if the actual contents of the string is your concern. In your sample code below, what are the sections you want to NOT format ? Is it the "package" + "generated import list" + "public class ...{" ? or is it the rest ? > > package ... > // generated import list > import ... > //[START:imports] > Here you can add your own imports > //[END:imports] > public class ...{ > //[START:somecode] > //[END:somecode] > } > I don't see the point in not formatting the package+import+class because there is nothing in there that I would like to have formatted by myself. The second option is just as pointless in my eyes because it's some user code if I understood things correctly. If they want to disable formatting at some point, they'll manage it themselves. If I were one of the developers, I would implement your request since it looks like "just" an initialization issue. But I am still uncomfortable with your comment. > But the place where you're allowed to put your own code is IN the sections > identified by START/END couple, not outside. Is that START/END couple a marker for non-generated code or is it a marker for format ON/OFF ? Or does it serve both purposes ? I'm confused.
Hi Amenel, thanks for answering (In reply to comment #28) > (In reply to comment #27) > > Why would the 'illogical' aspect of starting the generated file with the > "formatter off" tag would bug anyone ? Since we got to choose the string that Hope I didn't hurt anyone about the "illogical" word. If so, please excuse me. I was not speaking about the feature, but what we would be doing. > In your sample code below, what are the sections you want to NOT format ? Is it The parts we want to format are the user code parts. The rest is generated, and formatting would be scratched next time (we can regenerate on the same files, preserving the "user code"). > I don't see the point in not formatting the package+import+class because there > is nothing in there that I would like to have formatted by myself. You wouldn't in our case. As this is a generated part, no one is supposed to touch it. > > But the place where you're allowed to put your own code is IN the sections > > identified by START/END couple, not outside. > Is that START/END couple a marker for non-generated code or is it a marker for > format ON/OFF ? Or does it serve both purposes ? I'm confused. OK, I guess I understand what I didn't explain well. START and END marker are *already existing* tags we currently generate in the code to identify the user code, the one that can be formatted. Outside is not. So what our developers do currently is manually selecting the code inside the tags before doing CTRL-Shift-F. So, with this, the part that have to be formatted, or NOT formatted was already clearly identified. That's why I was trying to find a way to use the disabling formatter feature without modifying the generated code, just using the current and present tags to identify code portions. > If I were one of the developers, I would implement your request since it looks > like "just" an initialization issue. But I am still uncomfortable with your > comment. Sure. As I said, I think I can workaround my problem by modifying our templates and generating an additional END at the beginning of each file. But I really just felt this is more like a workaround than a clean solution. But if you think this is an acceptable solution, then I'll go this way. I just wanted to trigger a potential small limitation of the feature, considering that the formatter is always on at the start of the file. I hope I'm being clearer than previously. Thanks again. Cheers.
(In reply to comment #29) > (In reply to comment #28) > > (In reply to comment #27) The current logic is either do not format the code or format it... Really simple logic which allows, for obvious performance reason, not to scan the file when user does not want to format it... If the code is not scanned, there's currently no chance to detect a tag to re-enable the formatter inside it :-( Changing this logic will need to introduce another new API change and unfortunately this is too late as M6, which is the API freeze milestone, is almost done! So, I'm afraid that for this version, you'll have to use the documented way to do it (see the DefaultCodeFormatterConstants.FORMATTER_DISABLING_TAG javadoc comment): put a disabling tag at the beginning of the generated code... You can still open a new requirement to add this new functionality in the next version.
(In reply to comment #30) > (In reply to comment #29) > > (In reply to comment #28) > > > (In reply to comment #27) > too late as M6, [...] [...] > > You can still open a new requirement to add this new functionality in the next > version. Ok, I perfectly understand. I'll add a separate issue for this and add a link to this one. Thanks for your answers.
Verified for 3.6M6 using build I20100305-1011.
> I think I can workaround my problem by modifying our templates > and generating an additional END at the beginning of each file. Would it also be enough if we just added the possibility to define multiple On and Off tags? Then you could add a word from the header comment (e.g. 'Copyright') as Off tag, and we could avoid yet another preference. Or maybe the formatter could change its behavior based on the first tag it sees. If it's an Off tag, format everything from the beginning to the tag. If it's an On tag, start with the formatter disabled and only enable it after the On tag.
(In reply to comment #33) > Or maybe the formatter could change its behavior based on the first tag it > sees. If it's an Off tag, format everything from the beginning to the tag. If > it's an On tag, start with the formatter disabled and only enable it after the > On tag. Is that really possible to you ? going back in the source file ? In case no off or on tag is in the file, wouldn't it mean a two-pass formatting ? Anyway, I think the multiple tags is a better option, all the more since it was already in the air.
(In reply to comment #33) > > I think I can workaround my problem by modifying our templates > > and generating an additional END at the beginning of each file. > > Would it also be enough if we just added the possibility to define multiple On > and Off tags? Then you could add a word from the header comment (e.g. > 'Copyright') as Off tag, and we could avoid yet another preference. > That was my first proposal for this API, but it was rejected by Dani as he would not have enough time to implement the corresponding UI... > Or maybe the formatter could change its behavior based on the first tag it > sees. If it's an Off tag, format everything from the beginning to the tag. If > it's an On tag, start with the formatter disabled and only enable it after the > On tag. hmmm interesting... would you intend to implement this behavior in the formatter, Markus? <g> (In reply to comment #34) > Is that really possible to you ? going back in the source file ? In case no > off or on tag is in the file, wouldn't it mean a two-pass formatting ? > Everything is possible, the single question is: what would be the cost of it (time to develop and performance impact)? Quickly thinking about it, I think there could be an "elegant" solution to do so, but I would definitely need more time to make this idea more precise and validate it... > Anyway, I think the multiple tags is a better option, all the more since it > was already in the air. > I agree... As I said above, this limitation comes from the UI side (sorry Markus), as I already have a patch containing the implementation for multiple tags. However, this would need to add another preferences and, as I also already said, this is definitely too late to do that (except if there would be a justified strong need for it of course...)
Verified.
*** Bug 128630 has been marked as a duplicate of this bug. ***
*** Bug 195894 has been marked as a duplicate of this bug. ***
Glad to discover that this is finally fixed. But I have a small question: why there are no *default value* for these two flags? I'm downloading 3.6 M7 today, and are expecting that there are default values for these two flags (actually I always do), but it's not there. I understand that if these two default values are set by default will break backward-compatibility, but can we add a button next to the preference page say: Default or Suggest for me, or put a line of text (label) to show the suggested tags? Here is why I believe the default value is important: it can be a kind of standard, which can be easily shared between developers and community, esp. for strategy applications which last several years and people goes and comes from different teams, companies etc. It saved a lot of efforts to argue which word is better than others. I can understand that there are lot of projects have defined their own tags (like what have been suggested in the context of this issue). And providing the flexibility to make their tags defined in preferences will reduce the efforts involved. But for the new projects (and lot of existing projects which has not defined their tags), a default value will make the life much easier. I can see that if default value provided, these projects will start using it without changing. If default value is required, <format: on> and <format: off> (found in the context of this issue) looks good to me. And if these two can be added to the context assistant, that's even better!
(In reply to comment #39) I've filed 311582 for a master switch for the 2 new options. That's a prerequisite for setting defaults. Please continue discussion about concrete defaults in that bug. See also bug 311578 for a problem with tags "//J-" and "//J+" for e.g. Jalopy.
Please use bug 311617 to discuss/propose default tags.
*** Bug 323620 has been marked as a duplicate of this bug. ***
