Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Interacts poorly with per-type indentation settings #23

Open
danfuzz opened this issue Oct 18, 2016 · 4 comments
Open

Interacts poorly with per-type indentation settings #23

danfuzz opened this issue Oct 18, 2016 · 4 comments

Comments

@danfuzz
Copy link

danfuzz commented Oct 18, 2016

When one has a config.cson that specifies per-type indentation, my expectation would be that the config settings are the default for new files and are responsible for the tab width on tabbed files, but that this package overrides these settings based on what is detected. That doesn't appear to be what happens. Instead, it looks like this package gets overridden by the per-type setting.

Steps To Reproduce

  1. Put the following in your config.cson:

    ".js.source":
     editor:
       tabLength: 8
       tabType: "hard"
    
  2. Open up a .js file with blatant two-space indentation.

Expected Results

The editor is set to two-space indentation.

Actual Results

The editor is set to eight-space hard tab indentation. If you watch carefully, you can sometimes see the indentation status briefly flash "2 Spaces" before getting thwacked to "Tabs (8 wide)".

@danfuzz
Copy link
Author

danfuzz commented Nov 3, 2016

(I've been doing some investigation.) I know this isn't a complete solution, but it looks to me like part of the problem is that there is a way for the spacing settings to get updated other than the two methods that this package overrides. Specifically, TextEditor.update is the underlying method, and it is indeed sometimes called directly. As such, it might make sense to override it instead of the other methods, e.g. something like this in auto-detect-indentation.coffee:

    originalUpdate = editor.update
    ...

    # Trigger "did-change-indentation" event when indentation is changed.
    editor.update = (params) ->
      value = originalUpdate.call(editor, params)
      if (params.softTabs isnt undefined) or params.tabLength
        @emitter.emit 'did-change-indentation'
      value

@danfuzz
Copy link
Author

danfuzz commented Nov 3, 2016

A little more info: Near as I can tell, the actual settings race is between this package and this bit from text-editor-registry.js in Atom core (around line 333), https://github.com/atom/atom/blob/master/src/text-editor-registry.js#L333-L343:

      for (const [settingKey, paramName] of EDITOR_PARAMS_BY_SETTING_KEY) {
        this.subscriptions.add(
          this.config.onDidChange(settingKey, configOptions, ({newValue}) => {
            this.editorsWithMaintainedConfig.forEach((editor) => {
              if (editor.getRootScopeDescriptor().isEqual(scopeDescriptor)) {
                editor.update({[paramName]: newValue})
              }
            })
          })
        )
      }

One of the so-named EDITOR_PARAMS_BY_SETTING_KEY is in fact:

  ['editor.tabLength', 'tabLength'],

@danfuzz
Copy link
Author

danfuzz commented Nov 3, 2016

Just one more note before I give up on this for the day. I have a really janky workaround, which mostly works. In auto-detect-indentation.coffee, if you delay the indentation setup by a moment, then it will typically end up running after the per-type setup. That is, change this:

    indentation = IndentationManager.autoDetectIndentation editor
    IndentationManager.setIndentation editor, indentation, true

to this:

    # Wait just a moment to allow for the default value to get set up by the
    # per-type configuration code. Then run the detector.
    soon = ->
      indentation = IndentationManager.autoDetectIndentation editor
      IndentationManager.setIndentation editor, indentation, true
    setTimeout soon, 250

The problem I've noticed is that this doesn't work when restarting Atom, when saved window state gets restored. I haven't figured out why that is.

In any case, I hope all this commentary is useful to you.

@danfuzz
Copy link
Author

danfuzz commented Nov 10, 2016

BTW, the referenced bug was closed as "fixed in 1.12," but it looks to me like the problem still exists in that version.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant