Community
Participate
Working Groups
Dear Team, Removing trailing spaces while saving file could be an option. Of course, this option would be disabled by default to avoid damaging on CVS/SVN. Thank you all for your so incredible work, Christophe Bismuth
This is possible for Java files in the Java editor.
*** Bug 311173 has been marked as a duplicate of this bug. ***
What is the status of this bug after 3 years?
(In reply to comment #5) > What is the status of this bug after 3 years? No time to work on this but would accept a high quality patch.
(In reply to comment #6) > No time to work on this but would accept a high quality patch. What do I need to start?
(In reply to comment #7) > (In reply to comment #6) > > No time to work on this but would accept a high quality patch. > > What do I need to start? Bug 195063 needs to be addressed. For a summary of the problems/questions to solve see bug 195063 comment 6.
*** Bug 341407 has been marked as a duplicate of this bug. ***
(In reply to comment #8) > (In reply to comment #7) > > (In reply to comment #6) > > > No time to work on this but would accept a high quality patch. > > > > What do I need to start? > Bug 195063 needs to be addressed. For a summary of the problems/questions to > solve see bug 195063 comment 6. I don't think there is a need to be as fancy as described in bug 195063 comment 6. CDT currently supports removing trailing whitespace in edited lines only, which exactly what most users are looking for. See createSaveActionEdit method in /org.eclipse.cdt.ui/src/org/eclipse/cdt/internal/ui/editor/CDocumentProvider.java
Any progress on that after yet another year? Removing trailing whitespace from edited lines is definitely that I want. However, bug #311173 was marked as a duplicate of this bug, and chances to fix it were drastically reduced by this action.
(In reply to comment #11) > Any progress on that after yet another year? Sorry, no resources to work on this.
(In reply to comment #12) > (In reply to comment #11) > > Any progress on that after yet another year? > Sorry, no resources to work on this. Having said that, if someone is interested in this and wants to provide a high quality patch it would be welcome.
Agile says that if task is too complicated, it should be split. I've heard that bug #311173 is covered in CDT and JDT as well. How about start with that? It will be real at least.
(In reply to comment #14) > I've heard that > bug #311173 is covered in CDT and JDT as well. How about start with that? It > will be real at least. I don't get your point.
(In reply to comment #15) > (In reply to comment #14) > > I've heard that > > bug #311173 is covered in CDT and JDT as well. How about start with that? It > > will be real at least. > I don't get your point. All right. Let's explain from the start. (In reply to comment #12) > (In reply to comment #11) > > Any progress on that after yet another year? > Sorry, no resources to work on this. No resources means that there are nobody to work on this, probably because the task is huge. There is a set of methodologies available that help in these cases. They are often referenced to as "agile" - you may have heard about agile manifesto. This task is gathered from several _close, but different_ user stories, which were closed as duplicates. These stories are often easier to implement than master bug, sometimes they are contradicting, sometimes they can take a completely different approach than master ticket. For example, bug #311173 can be fixed on formatter level instead of on file save. The approach you choose to quickly mark bugs as duplicates (instead of dependencies) makes the master issue overcomplicated. The issue becomes "epic" - another term from agile. Task is considered "epic" when nobody is able to tackle it due to time or other constrains - i.e. you don't have resource. The common methodology to approach these things is to split epic task into several user stories and if stories still take more than one day to handle - split them in tasks. I propose to start with bug #311173 and split it into tasks. There might be ready to use pieces of code in CDT and JDT projects that solve exactly this user story, but not the story in this master report.
My question was not about "agile" - I know what this is ;-), but rather for "I've heard that bug #311173 is covered in CDT and JDT as well. How about start with that?". Anyway, the first task to solve is bug 195063 which is about pushing down (i.e. reuse) the code in JDT to allow doing things on save.
(In reply to comment #17) > My question was not about "agile" - I know what this is ;-), but rather for > "I've heard that > bug #311173 is covered in CDT and JDT as well. How about start with that?". > > Anyway, the first task to solve is bug 195063 which is about pushing down (i.e. > reuse) the code in JDT to allow doing things on save. Why is it so strictly necessary to remove whitespaces on save? ISTM that detecting touched lines on save (for removing trailing spaces) is more complicated than doing it while formatting entered text.
> Why is it so strictly necessary to remove whitespaces on save? ISTM that > detecting touched lines on save (for removing trailing spaces) is more > complicated than doing it while formatting entered text. 'Save' explicitly terminates the editing. If you want to implement this while typing you can end up in strange user interactions and you also need to make sure it gets removed on save (e.g. type 'Tab' + save) because otherwise you end up with trailing whitespace again.
*** Bug 359214 has been marked as a duplicate of this bug. ***
(In reply to comment #20) > *** Bug 359214 has been marked as a duplicate of this bug. *** Actually my report goes slightly further than this bug. Hence it is not a real duplicate of this, but a relative. In addition to this bug, my suggestion adds this: Yes, remove trailing whitespaces on option, but leave those meant for indentation in empty lines (compare to previous non-empty line).
Created attachment 240193 [details] remove space remove trailing space
