Closed rumpelsepp closed 7 years ago
Hi @rumpelsepp, please invoke EditorConfig: Show State
to determine if editorconfig mangling your tab-type because of an editorconfig-setting (that's the case if f.e. the indent_style
is different to auto
).
Editorconfig should only touch the tab type, if indent_style
is configured. If it is configured it always overrides the Atom-settings. This is expected behavior.
Since I have no editorconfig files in that project, EditorConfig: Show State
always shows auto
.
🤔 If it shows auto, editorconfig shouldn't change anything..
Well, i am wrong (the responsible line is https://github.com/sindresorhus/atom-editorconfig/blob/master/index.js#L136). To revert changes possibly made by editorconfig we currently explicit apply the atom-config setting for that scope.
I assume this is why your setting gets reset to something different than expected. I have to think about how this case must be treated correctly.
🗒 Reference changed to https://github.com/sindresorhus/atom-editorconfig/blob/master/index.js#L57
@florianb when viewing a GitHub source file, press the y
key to get a permalink including the commit hash you were looking at; then code references in issues always point to the same place you originally mentioned, even if the source file is updated in future commits (and even when the source file is removed or renamed!)
The permalink to that source line of code is https://github.com/sindresorhus/atom-editorconfig/blob/773d07bd230e2e91d441e3ac4cadce9025562185/index.js#L57
The tab type is actually stored under editor.tabType
key in config. editor.softTabs
is only used when editor.tabType
is set to auto
and Atom fails to determine the tab type of a buffer (which happens when a buffer does not contain any leading whitespace). It is not correct to set the tab type based on editor.softTabs
value only.
See how Atom v1.14.3 determines the tab type for an editor: the function and its usage.
Thanks for your comment @orgkhnargh, even though i don't know what it should tell me - or was it addressing kirsle?
Atom-Editorconfig requires the editor.tabType
being set to auto
anyways.
@florianb I'm sorry if my comment was not clear. It was addressed to you, @florianb.
I'll try to explain. When editor.tabType
is set to auto
, it's necessary to examine the buffer content in order to determine whether spaces or tabs are being used (atom editors have usesSoftTabs
method that does just that). Atom-Editorconfig does not examine the buffer content, it just sets the default value (editor.softTabs
).
Here is a list of steps to reproduce the issue shown on @rumpelsepp's gif.
editor.tabType
is set to auto
and editor.softTabs
is set to true
.line with tab indent
another line with tab indent
.editorconfig
file with the following content. This will prevent editorconfig from using any global configuration files, and all the settings will be implicitly set to auto
.
root = true
editor.softTabs
).Thanks @orgkhnargh - i guess i got it now. I drafted a fix, i'd appreciate if you could take a look! However, i still have to write a test for it.
@florianb looks fine to me!
The only thing I am concerned about is that it still ignores the editor.tabType
value, which is not consistent with the behavior of Atom without atom-editorconfig. IMO, when a user does not specify indent_style
for a file in .editorconfig
, the logic of determining the indent style should fall back to what Atom uses. Currently atom-editorconfig implicitly decides that editor.tabType
is set to auto
, but people could have set editor.tabType
to either hard
or soft
too. I'm not sure why would anyone do that instead of specifying indent_style
in the [*]
section of .editorconfig
, but it is a possibility that might be reasonable to consider.
Thanks @orgkhnargh.
I in fact decided to not support Atom's tabType being set to anything else than auto
because Atom seems to internally invoke updates of the editor's configuration which results in a override of the tabType settings done by this package.
So when a tabType different to auto
is detected the user is warned that indent_styles may not be applied correctly. To limit the experience of unexpected behavior we could disable the treatment of indent_styles entirely as long as the tabType isn't set to auto
.
@florianb I understand your point, but I don't think it makes sense. The only time when the settings of an editor may be different from the ones listed in .editorconfig
is after user closes (or switches off from) the settings tab and before user activates an editor (atom-editorconfig reapplies the settings on top of what Atom applied when an editor is activated).
The only way to break this I could think of is when the user changes editor.tabType
somehow without switching from the active editor (e.g., they could make a tollbar button that switches tab type in the settings). In that case the tab type of the active editor will be changed by Atom. Only the active editor will be affected, because as soon as the user switches to another editor, tab type there will be reapplied by atom-editorconfig, as well as the tab type of the editor that was active during the change as soon as the user switches back to it. Even this could hopefully be fixed by reapplying the editorconfig settings on editor.tabType
and editor.softTabs
.
I don't really see how not setting editor.tabType
to auto
could interfere with atom-editorconfig. I can see that changing editor.tabType
while atom-editorconfig is active may lead to issues with one (currently open) editor when user does not use settings-view for configuration. But this only means that you should warn users not to change tab type, as the process of changing is the cause of issues, not the values they change tabType to. Having tabType set to other values cannot be harmful as long as atom-editorconfig handles them correctly.
The above is the conclusion I made after I read both atom and atom-editorconfig source code. Please let me know if I am wrong.
@orgkhnargh the decision to stick with tabType being auto
was made in April 2016. And one reason is that the tabType is also being applied on tokenization. The tokenization API of the text-buffer is considered as private. So i treat that part as black box which i can't affect.
So i would like to ask what this discussion is about and what you are aiming for?
Applying the editorconfig's standard to Atom has a lot caveats and some parts still rely on moving parts of the Atom environment. So if you would like to enhance the (pretty stable) tabType-functionality - feel free to play around with a fork. I would really appreciate to have more practical contributions.
@florianb I am just trying to bring to attention the moving parts of the Atom environment that aren't that moving and could be handled correctly.
Please excuse me if I was too annoying :white_flag:
@orgkhnargh i guess i don't get it again. The editor.tabType is everytime applied a tokenize-event get's fired, unless it is set to auto
. I don't see any way to intercept that, or to get notified of that in a way which guarantees that this package is being the last one in the event-chain which is called. Until this is solved, we can't set the softTabs without being overridden, unless the tabType is set to auto
.
You brought attention to a bug in the implementation which is going to be fixed. And i am thankful for that.
But i can't see that the further discussion about the requirement of tabType being set to auto
fixes anything. Because in my understanding there is nothing more to fix. But i am only a human, so if i just don't see the case of a incorrect implementation besides of this issue, please open a new issue and file a spec which points out where the current implementation fails. That way i guess the chance lowers i am able to misunderstand what you're aiming for.
@brumm i rolled the patch out for this issue. I'd appreciate if you could confirm that this issue is fixed.
Atom forgets the tab type configuration when this plugin is enabled. I use the autodetect feature of atom, to detect if a buffer uses tabs or spaces for the intendation. When I change tabs, atom forgets that setting. Disabling this plugin fixes this issue, so it might be caused by
atom-editorconfig
.In the attached gif I create a new line, switch tabs and then create a new line again. You see that after switching tabs spaces are used.
Involved .editorconfig-files
None; just the plugin is enabled
Directory structure
Not relevavant I guess.
Installed packages