Should editor settings (tabLength/softTabs/preferredLineLength) be set?

[zargony]

Currently, this package sets the tabLength/softTabs/preferredLineLength editor settings (in settings/rust.cson) of Rust files to values recommended by the Rust style guide. This means that Atom automatically uses 4 spaces for indentation and a line length of 99 when editing .rs files, even if the user has different (global) settings. This was meant to encourage people to use these settings accordingly to the style guide (which is used by almost every public Rust code). There's still the possibility to override these settings in the package settings. However, this seems to confuse people and more and more issues and pull requests pop up that try to remove these recommended defaults.

I personally think it's a good idea to provide these editor settings to encourage the public Rust style. However, if people are confused about this, it might be better to remove them? I don't think I should decide this on my own. What do you think about it?

Keep recommended editor settings (👍)

• encourages people to write "proper formatted" code
• this seems the way how Atom designed it (these package settings do appear automatically)

Don't keep recommended editor settings (👎)

• people are confused if their personal editor settings are overridden (and usually don't know about the package settings)

[cnd]

I don't like recommended editor settings, I prefer 2, 4 is a lot...

[Alhadis]

I use 4-column wide hard tabs and hate it when grammars change that. If it isn't a syntactic requirement that a tab or a space be used to indent, it shouldn't be shoved onto the end user.

(To be bluntly honest, I don't give a crap about "Rust standard style", and I doubt I'm alone either.)

[josh-berry]

I'm mostly on the fence about this, but tilting slightly in favor of removing the custom line length, since:

• language-rust is the only language package I've used that does this,
• people probably already have other window/tab sizes, settings, etc. set up to expect whatever their "standard" width is (e.g. 80 columns), and
• it's actually impossible, AFAICT, to get language-rust to follow the default settings as outlined in Preferred wrap length settings is automatically set back to 100 when both wrap-guide and Rust wrap are set to 72. #89. (For example, if I try to explicitly set language-rust to use 80-column lines, it reverts to the built-in default of 100! I have to set it to use 79-column lines instead...)

I don't really think "standard style" is good enough reason to give language-rust different/surprising behavior compared to Atom's other language packages. It's a shame that Rust decided to deviate from the 80-column convention, which has been in wide use for a long time in a number of different contexts.

That said, I'm more of a casual user of Rust -- it's not my primary language (or a language I use professionally), and people who use it on a regular basis may have a different opinion.

[rjbailey]

If there was a way to set a default for this package while still allowing configuration, then I'd be all for it, but as it stands now, it isn't possible for me to customize the package to match my global settings (and frustratingly, it LOOKS possible--my changes just seem to be ignored).

Until Atom provides a way to set per-package defaults that doesn't have this problem, I'd really appreciate it if language-rust would stop overriding these settings.

[Alhadis]

@rjbailey Do as I did and add this (or whatever you want to change) to your config.cson:

".rust.source":
  editor:
    softTabs: false

Problem solved!

[rjbailey]

Thanks for the workaround!

[zargony]

Atom also does have a settings page for it. It's just a bit hard to find. Go to Settings -> Packages -> language-rust -> Settings (gear icon next to the uninstall button). There are the Rust-specific editor defaults. Works for other language packages too.

[jordiorlando]

@zargony Unfortunately this actually does not work. The defaults that show up for line length and tab length are Unscoped value: 80 and Unscoped value: 2, respectively, even though they are in reality set to 99 and 4. The result of this is that changing them manually to the global editor settings (e.g. 80 and 2) results in the settings being almost immediately overwritten, while changing them to any other value works. So with language-rust installed it is impossible for me to use my global settings for rust code.

[rjbailey]

Right, I experienced the same thing. That's why I said it looks possible, but actually isn't--I found the settings page, but couldn't use it to configure the package to use my global defaults. It's not a very good experience.

[zargony]

You're right and I've come across this as well some time ago. Atom's settings page seems to ignore package-based defaults and always look at global defaults. This sounds like an Atom bug to me.

[hbobenicio]

Forcing a code style, even if it is kind of a language standard. is annoying and limited. No problem it defaults to the style guide, but having no configuration option that allows the user to explicitly tell his identation styles is frustrating. It would be better, IMHO, to default to the style guide and to have an option for the user to be free and choose whatever style he wants to.

[zargony]

I agree that forced coding style is annoying. The intended behavior is to provide defaults accordingly to the style guide, but (of course) allow anyone to override these defaults. It's because of Atom bug #939 that you currently can't override them back to the global defaults.

[SnirkImmington]

The intended behavior is to provide defaults accordingly to the style guide, but (of course) allow anyone to override these defaults. It's because of Atom bug #939 that you currently can't override them back to the global defaults.

Coming from a fresh Atom install with every other file type formatted at an 80 character width, installing Rust lints package, and then having the width indicator 19 characters off from the default is very annoying. If I could go over to the settings window for this package I would, but as mentioned before this does not work.

I was only able to fix this because I'd fixed this in on another computer - by grepping for "width" and "9" in my .atom folder. I had no idea there'd be settings files besides config.cson - which other packages had already written their custom settings to, and they were adjustable in the settings window and not broken.

I get that this is an Atom bug. As an end user, though, it really pissed me off - I'm just trying to show how frustrating it is. Imagine being new to Atom and seeing that a setting is off but all the settings menu and config.cson editing cannot help. Please don't include any broken configuration changes until Atom makes sure that they can be fixed in the settings menu.

[zargony]

Looks like it got fixed in Atom (atom/settings-view#967) and with next Atom Release we shouldn't have this issue anymore.

[focusaurus]

Just an anecdote that I just wasted 30 minutes troubleshooting why my wrap guide was at 100 even though the core package wrap-guide's setting was 80. Changed to other values, no luck. I think the wrap guide should be handled entirely by the wrap-guide package and atom-language-rust should absolutely have nothing to do with that. If you want to prompt the user to set a rust-specific length of 100, which wrap-guide already supports, just suggest that or offer to add it to config.cson and let wrap-guide handle it, but don't just magically override it. I asked for wrap-guide support and almost filed a bug, but luckily I tried to reproduce in safe mode and realized some of my packages must be doing something way out of their expected scope.

I'll also note that wrapping at 100 causes stackoverflow code snippets to scroll horizontally, which makes it harder to get help with a rust issue.

[Aerijo]

I think the wrap guide should be handled entirely by the wrap-guide package and atom-language-rust should absolutely have nothing to do with that

don't just magically override it

realized some of my packages must be doing something way out of their expected scope

I think it makes complete sense that the wrap guide package respects language settings; in fact, I would consider it a bug if it didn't. It would be weird for the soft wrap length to be different to the visual indicator of the wrap-guide. It's not a "magic override", it's just doing it's job.

And this sort of setting is well within the expected scope of this package; each programming language comes with it's own "expected style". It's not enforceable, but package defaults should align with these values (because, presumably, these expectations were set for a reason). If a user makes a (one time) conscious decision to change it, power to them.

Note I haven't actually tested what happens when you change the defaults set by this package. I know Atom can behave strangely when default settings are involved. However, at a conceptual level, this is the right behaviour (for the wrap guide, and for providing default settings).