Community
Participate
Working Groups
Build ID: 3.4 The Java environment allows to select a save action in the preferences: Java -> Editor -> Save Actions This would be very useful for CDT and probably all other editors too. So feel free to reassign it to Eclipse platform. PS: The internal code formatting is very useful, especially as there exist no good command line formatter for C++. Is there any way to call it from the command line or in a batch modus to reformat all (except a few special) files?
(In reply to comment #0) > Is there any way to call it from the command line or in a batch modus > to reformat all (except a few special) files? No, but it should be relatively easy to implement a headless application for that similar to what JDT provides.
*** Bug 300191 has been marked as a duplicate of this bug. ***
The bug was filed in 2008 and still not implemented. "Format on save" action would be very useful and convenient and should not be that hard to implement.
Created attachment 229401 [details] Screenshot of JIndent "Format on Open" Preference StackOverflow discusses the lack of this feature here: http://stackoverflow.com/questions/5378071/format-c-c-code-on-save/14489127 I've found that the commercial "JIndent" solution supports a "format-on-open" Preference, which formats the source code when a file is opened in the editor (see attached screenshot). This has some advantages like providing auto-formatted code for better readability, and giving me the option of reviewing the formatting before actually saving. If I don't like the auto-formatting for any reason, I simply choose "Undo" and the auto-formatting changes are all gone. I suppose it shouldn't be too hard to emulate a "Ctrl+Shift+F" keystroke on editor-open notification of selected file types (eg C/C++ files only)? At least it should be easier than format-on-save which always bears some risk of saving (and committing) formatting changes that have never been reviewed ?
*** Bug 426656 has been marked as a duplicate of this bug. ***
(In reply to Martin Oberhuber from comment #4) > I suppose it shouldn't be too hard to emulate a "Ctrl+Shift+F" keystroke on > editor-open notification of selected file types (eg C/C++ files only)? At > least it should be easier than format-on-save which always bears some risk > of saving (and committing) formatting changes that have never been reviewed ? I think format on open could be a separate feature / bug.
Proposed patch for save action from Oliver: https://git.eclipse.org/r/#/c/21420/
A bug opened in 2008 and still open? Wow. I didn't think it was too hard put a "format on save" option. Fix and close this bug report ASAP.
(In reply to Mark B from comment #8) > A bug opened in 2008 and still open? Wow. I didn't think it was too hard put > a "format on save" option. Fix and close this bug report ASAP. Eclipse is an open-source project; there is no commercial company behind it of which you can make demands as a customer. Most of the people contributing to Eclipse do so in their spare time on a volunteer basis. The handful of people who are paid to work on it are paid to work on specific features needed by their employer. The current status of this bug is that there is a patch posted for review in comment 7, it has been reviewed, it needs to be revised to address the review comments, but the original author of the patch doesn't have the time to do so. If it's important for you to have this fixed, you're welcome to pick up the work and make the revisions yourself. As you can see from the review, the project committers are fairly prompt in reviewing posted patches.
(In reply to Nathan Ridge from comment #9) > (In reply to Mark B from comment #8) > > A bug opened in 2008 and still open? Wow. I didn't think it was too hard put > > a "format on save" option. Fix and close this bug report ASAP. > > Eclipse is an open-source project; there is no commercial company behind it > of which you can make demands as a customer. > > Most of the people contributing to Eclipse do so in their spare time on a > volunteer basis. The handful of people who are paid to work on it are paid > to work on specific features needed by their employer. > > The current status of this bug is that there is a patch posted for review in > comment 7, it has been reviewed, it needs to be revised to address the > review comments, but the original author of the patch doesn't have the time > to do so. > > If it's important for you to have this fixed, you're welcome to pick up the > work and make the revisions yourself. As you can see from the review, the > project committers are fairly prompt in reviewing posted patches. It's not important only for me but there are a lot of people out there waiting for this feature and I think six years are enough. I know it's an open source project but if to close this report the project needs six or more years maybe there is really something wrong. However I'm a developer but I don't know the Eclipse code, if I can help I'll do.
(In reply to Mark B from comment #10) > It's not important only for me but there are a lot of people out there > waiting for this feature and I think six years are enough. I recognize that. I'm a volunteer, and I have been working my way through fixing open bugs, but there are thousands of them, and many of them are similarly popular to this one. > I know it's an > open source project but if to close this report the project needs six or > more years maybe there is really something wrong. I agree that there is some disparity between the rate at which users ask for new features and the rate at which contributors are able to provide them. Do you have any suggestions for how to address this disparity? I've argued above that there isn't anyone we can point to and say "hey you, you should be working on this feature!". > However I'm a developer > but I don't know the Eclipse code, if I can help I'll do. I pointed out how you can help: by revising the posted patch to address the latest review comments (specifically, Elena's comments dated Sep 4, 2014). If you're able to do that, great. If not, we'll have to wait until someone else does. That someone else may be me at some point, but I have a long backlog of bugs I plan to work on before this one, so you shouldn't wait up.
Created attachment 248522 [details] Proposed patch with fixed comments
Guys, I tried to fix the comments of last patch series. I didn't understood how gerrit works so I post here the update patches against the master branch. Actually in the last version there was a bug, because the code in performSaveAction was called only if shouldRemoveTrailingWhitespace() was true or shouldAddNewlineAtEof() but not for shouldStyleFormatCode(). If someone can help to submit the patch for review would be great. I tested the code and works great. I'm waiting for your comments.
See bug 426656 and related gerrit https://git.eclipse.org/r/#/c/21420/. I just can't commit further changes to address the comments as are outside of my change and understanding. This works but doesn't do the JDT 'magic undo' - on save, format; If user does CTRL+Z immediately afterwards undo format and re-save without formatting.
(In reply to Oliver Vinn from comment #14) > This works but doesn't do the JDT 'magic undo' - on save, format; If user > does CTRL+Z immediately afterwards undo format and re-save without > formatting. It's true but as said by Elena Laskavaia on 4 Sep we could be happy with this patch and add the undo later. At least after six years we can close this bug report and open a new one :)
(In reply to Marco Stornelli from comment #13) > Guys, I tried to fix the comments of last patch series. I didn't understood > how gerrit works so I post here the update patches against the master > branch. [...] If someone can help to submit the patch for review would be > great. I tried submitting the patch, but Gerrit doesn't allow me to submit a patch authored by someone else. Could you please try submitting it yourself via Gerrit, using the instructions at https://wiki.eclipse.org/CDT/git#Using_Gerrit_for_CDT ? If you run into any problem, let us know and we'll help you figure it out.
(In reply to Nathan Ridge from comment #16) > Could you please try submitting it yourself via Gerrit, using the > instructions at https://wiki.eclipse.org/CDT/git#Using_Gerrit_for_CDT ? If > you run into any problem, let us know and we'll help you figure it out. Thanks. I uploaded to https://git.eclipse.org/r/#/c/21420/ I fixed a bug in the sixth patch found by integration tool. There are a couple of trailing white spaces in the patch, after the comments I'm going to send a new patch to fix it, however it seems ok to me. Let me know if the patch can be ready for submission in mainline. PS: The Eclipse process and tools for review and integration are really cool :)
Looks like the patch was committed in http://git.eclipse.org/c/cdt/org.eclipse.cdt.git/commit/?id=54607bd07fa5f306a39ee19bd28966267151240a. Thanks Marco! Should we leave this bug open for the 'undo' part?
@Nathan Ridge: you're welcome. A big thanks even to Oliver for the intial patch. I really hope we can close this bug report and the others related to this one and open a new bug report with the "magic undo" :)
I created bug 455664 for the undo enhancement. Thank you Oliver and Marco!
