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.
Product Version = NetBeans IDE 7.2 RC1 (Build 201206272359) Operating System = Windows 7 version 6.1 running on amd64 Java; VM; Vendor = 1.7.0_05 Runtime = Java HotSpot(TM) 64-Bit Server VM 23.1-b03 I never, ever have tabs in my source code. I always have "Expand Tabs to Spaces" checked, both for all languages and for Java. After installing 7.2 rc1, the editor is placing tabs in every Java source file (I have not checked other file types yet) that I edit. It seems to place the tab only at the beginning of lines. This is a DISASTER for source code control. It makes it look like every line has been changed.
Created attachment 121670 [details] IDE log
I tried to reproduce, but unfortunately did not succeed. When the "Expand tabs to spaces" checkbox is checked, spaces are always generated to me. Is this with per-project formatting options or with global formatting options? If the latter, could you please double check the per-project options are not interfering (Project Properties dialog has a "Formatting" tab for most project types). Also, could you please pack the options and attach them here (${userdir}/config/Editor for global options)? Thanks.
I can't reproduce it now, either. Sorry. I had switched back to 7.1.2 to get some work done, and I just switched back to 7.2 and I can't see the problem any more. Strange thing is, I was seeing the problem AFTER I committed to CVS. I removed the tabs and committed again, but the diff for that commit doesn't show any tabs removed. I originally saw this problem when I was replacing the first two spaces in a line with "//" (to comment the line out) and noticed that the line shifted left. I guessed that the shift happened because those "two spaces" was actually a tab, so I searched for tabs in the file and found many of them, but only at the beginning of the line. Strange, no?
Really strange. Please reopen if you see that again, with steps to reproduce. Thanks.
For what it's worth, in the past I've observed weird misbehavings in this regard consistently after installing jvi, even if I subsequently uninstall it. I chased down the issue by diffing config files after a fresh install, then adding and removing jvi. I'm not sure if these errors correlate to this issue, but it sounds likely it's travelling the same code path in netbeans. I believe it to be linked to having "Number of spaces per Indent" and "Tab Size" different vs the same, when that checkbox is turned off Conditions [under Tools->Options->Editor->Formatting]: 1) Expand tabs to spaces = off Number of Spaces per Indent = 4 Tab Size = 8 Result: hitting tab causes four spaces to be inserted, violating the "Expand Tabs to spaces" checkbox expectation. 2) Expand tabs to spaces = off Number of Spaces per Indent = 4 Tab Size = 4 Result: Hitting tab causes a tab to be inserted, as expected Am reopening this bug. It may be a different bug [feel free to ask, and I can open a fresh one]
(In reply to comment #5) > Conditions [under Tools->Options->Editor->Formatting]: > 1) > Expand tabs to spaces = off > Number of Spaces per Indent = 4 > Tab Size = 8 > > Result: hitting tab causes four spaces to be inserted, violating the "Expand > Tabs to spaces" checkbox expectation. Sorry, but this is as expected. "Tab" key increases the indent by the "Number of Spaces per Indent". If the current indent is not a multiple of "Tab Size", the remainder is filled with spaces, as there is no other option to keep all the constraints true. If only tabs are desired, then "Number of Spaces per Indent" should be equal "Tab Size".
(In reply to comment #6) > (In reply to comment #5) > > Conditions [under Tools->Options->Editor->Formatting]: > > 1) > > Expand tabs to spaces = off > > Number of Spaces per Indent = 4 > > Tab Size = 8 > > > > Result: hitting tab causes four spaces to be inserted, violating the "Expand > > Tabs to spaces" checkbox expectation. > > Sorry, but this is as expected. "Tab" key increases the indent by the "Number > of Spaces per Indent". If the current indent is not a multiple of "Tab Size", > the remainder is filled with spaces, as there is no other option to keep all > the constraints true. If only tabs are desired, then "Number of Spaces per > Indent" should be equal "Tab Size". I don't agree. I think it depends on what order you expect the options there to be evaluated in. There's no obvious ordering [other than top-to-bottom, which is what I think my mental model assumes]. This is what the process should be, in my mind: 1) User hits tab 2) NB looks at checkbox. Expanding tabs to spaces is off, so it should insert a tab. 3) When it actually renders the code on-screen, NB sees a tab in the code, and looks at the "Tab Size" option to evaluate how far to shift the next character over. 4) In this model, the "spaces per indent" setting has no purpose, because when I hit the keyboard's indent button [tab], I don't want spaces, as I've indicated via the checkbox. Alternatively, this is the process you [and, evidently, NB] follow: 1) User hits tab 2) NB looks at the "Tab Size" option and sees this as "shift things eight to the right". 3) NB looks at checkbox. Expanding tabs to spaces is off, but NB has to figure out how to show eight spaces when tab is only four; it fills the deficit with spaces. In my mind, the checkbox is the key; if it's off, I expect hitting tab to not generate spaces. Either behaviour is fine, really. But the UI should make this clear; I spent a lot of time chasing this down.