I'm afraid this affects all GSF based languages. At least it does not seem to work in PHP as well (see issue #122282).
Tor, would you please have any input (observations, ideas) on that? Thanks

This was recently fixed - both in the trunk and in the high resistance 6.1 branch.


*** This issue has been marked as a duplicate of 132363 ***

I take it back. What was fixed was the indentation level used for formatting. I couldn't find a way to fix the tab
indentation level.  In issue 132363 I specifically list the tab-key-insert case as one that is still not fixed.

Vita, any ideas on how I can fix it? The problem is that the actual number of spaces inserted when you press tab comes
from an editor action, which is hardcoded to call Formatter.getSpacesForTab() instead of document.getShiftWidth.  And
the formatter spaces per tab seems to be initialized from the editor settings.

And there is obviously only ONE editor settings object for the GsfEditorKit - even though it serves multiple editor mime
types. 2 is there for Ruby. But it should be 4 for JavaScript and PHP.  Any ideas how I can solve it?

Tor, I looked through your patches in #132363 and our code and I don't understand why you changed this:

diff -r d7c458cefd44 javascript.editing/src/org/netbeans/modules/javascript/editing/JsFormatter.java
--- a/javascript.editing/src/org/netbeans/modules/javascript/editing/JsFormatter.java	Tue Apr 08 17:16:25 2008 +0400
+++ b/javascript.editing/src/org/netbeans/modules/javascript/editing/JsFormatter.java	Tue Apr 08 11:44:38 2008 -0700
     public int indentSize() {
-        return codeStyle.getIndentSize();
+        return -1; // Use IDE defaults
     }
     
     public int hangingIndentSize() {
-        return codeStyle.getContinuationIndentSize();
+        return -1; // Use IDE defaults
     }


The JsFormatter is now reading settings assigned to XML kit, which is a really nasty hack, but I doubt we can do
anything else for release61. This hack IMO was what fixed indentation/formatting for javascript files. The insert-tab,
remove-tab actions end up calling GsfDocument.getShiftWidth() and if this method returns JsFormatter.indentSize() the
actions seem to work fine. I hope I am not missing something essential here, but when I tried to revert this particular
change in release61 repo the actions seem to work fine without having to go to Tools-Options and change anything.

Could you please try it in your build and let me know if it works (and nothing else gets broken :-). Thanks

Hi Vita,
I'll play with this and test what happens without it.  My recollection is that without this fix, the indentation values
will be -hardcoded- to the default (4) and no longer be customizable by the user. For the JavaScript files I want it to
just pick up the IDE defaults instead.  The problem I was observing was that insert-tab did -not- call document
shiftwidth, it called the formatter.getSpacesPerTab setting directly.

The reason I'm using the xml.editor "hack" is that this is precisely what the editor options code does. There is a
global indentation width setting exposed by the editor options dialog - and it will use the xml.editor value as the
default. I presume this is done because the xml editor is present in all configurations of the IDE?

As I mentioned in issue 132695 there is also some special logic for Java and JSP files in the IndentationModel code; is
that code really necessary? If not, it should be removed - and if so, what can other language types do to get the same
effect?

Hi Vita,
I tried your patch but it doesn't work for me.

I changed the two methods in Formatter back, wiped my userdir, started the IDE and opened a JavaScript file. I press tab
-- and it indents 2 spaces instead of 4.

By the way, here's the Tab action - it calls Utilities.getNextTabColumn which doesn't call document shiftwidth, it calls
the formatter directly:

    public static int getNextTabColumn(BaseDocument doc, int offset)
    throws BadLocationException {
        int col = getVisualColumn(doc, offset);
        int tabSize = doc.getFormatter().getSpacesPerTab();
        return (col + tabSize) / tabSize * tabSize;
    }

The tab-action issue is tracked in issue 132641.

Hi Tor, I'm sorry for the delayed response, but I was temporarily assigned to another project. Anyway, you are right
that the tab-action is not working correctly. I don't have any suggestion at the moment, but I'm back at where I left
the settings rewrite before code freeze in 6.1 and this is my first thing to do for this release. My first priority is
to kill BaseOptions and make settings fully mime-type aware. As part of this I'd like to remove GSF's dependency on
o.n.e.Settings and BaseOptions (with your permission of course).

After that I want to cleanup things (workarounds, hacks) around indentation settings. We already have IndentUtils class
that returns basic indentation settings for a document. We should change these methods to accept mime type rather that
document and bind it to the new mime-type aware settings infrastructure.

Please feel free to add vstejskal to any settings related issues in GSF. Thanks

This is finally completely fixed, mostly due to all the work Vita has done in 6.5 to rewrite the settings
infrastructure. There were also some problems in GSF itself where it was hardcoded to use spaces instead of tabs; all
that code should now be using the proper utilities. I've just verified that several language types (JavaScript, Ruby and
ERB) all use the correct indentation settings, and that they persist across IDE sessions.

'ruby/gsf -> editor/csl' mass-move to be able to deleted gsf/ruby. Having to
change the version and platform of all closed moved issues to the same due to
Issuezilla deficiencies - choosing version == 6.5 and TM = 7.0.