This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.
Strip trailing spaces on file save. Currently I've got CTRL+SHIFT+T mapped to trim, but would really like a way to do this automatically.
This should be already implemented - the save action should remove trailing space from all lines is current file. Can you please verify it once more time if it doesn't work for you.
closing as resolved due to inactivity and no verifiaction from reporter. Thanks.
Sorry for the delay. The save action does NOT strip trailing spaces on save. I tested with spaces on new lines and existing lines, and nothing was stripped off the ends of the lines.
Can you provide the exact build number and sample file with marked position of cursor while saving? Thanks
Build: 200905282243 File: class This def this print "this" [cursor] end end (trailing spaces after every line) I save. No change. I close and reopen. No change. I have to run the strip command then save before it works.
Netbeans (6.8 M2) doesn't remove trailing spaces in the line of the cursor (only before the cursor). These whitespaces are also stored if i close and reopen the document, set the cursor into another line and save the document again.
This works fine in my dev build. Just to make sure that we all understand how this feature works. The trailing spaces are removed (1) only from lines that you modified before saving and (2) they are not removed on the line where the cursor is. #1 - needed for VCS controlled files #2 - the editor must not change the caret position when saving files We had bug reports requesting both #1 and #2 and so it is highly unlikely that the current behavior will be changed.
Eg. Eclipse, Zend Studio and Kate (KDE Advanced Editor) removes the trailing spaces on ALL lines (also in the current cursor line) when saving. It would be nice if NetBeans may have the same behavior than the other major IDEs.
Well, I'm sure there will be people objecting at least as loudly as you are supporting this cause. We could probably support both styles and add an options that would control, which one is used.
Isn't this duplicate of issue 157561?
I think so. *** This bug has been marked as a duplicate of bug 157561 ***