In
7a5d727e22
the 'set-user-settings' callback was changed so that it nolonger
returned the promise created by `ConfigFile.update()`. This meant that
the logic in
[`ApplicateDelegate.onDidChangeUserSetting()`](https://github.com/atom/atom/blob/5f0231b/src/application-delegate.js#L193-L206) which uses
`.pendingSettingUpdateCount` to avoid triggering in response to calls to
ApplicationDelegate.setUserSettings` was no longer effective.
I noticed this when updating settings via the setting view. If you type
at just the right (wrong?) cadence, you'll notice that your input can
get updated with stale values.
Something like this:
```
You type "a" "b" "c"
config.set "a" "ab" "ac"
config.observe "a" "ab" "ac"
Input value "a" "ab" "a" "ac" "ab" "ac"
```
It's possible that is the same as https://github.com/atom/settings-view/issues/1062
After this change typing in settings input seems to behave as expected.
From what I can tell, this flag never worked correctly. Instead of
opening the paths specified in the project file, the directory
containing the project file itself would always be opened.
If Atom is launched in a shell that is missing the `USER`/`USERNAME`
environment variable it locks up due to an unhandled error from
`crypto.update`. This switches to using Node.js's built in
`os.userInfo()` method to retrieve the current user name,
allowing Atom to complete initialization in this scenario.
Fixes#16821.
This prevents the change handler for `core.titleBar` from being
triggered every time a new instance of the main process is created. This
fixes a regression that was causing users to be prompted for a restart
every time they opened Atom.
Co-authored-by: Max Brunsfeld <maxbrunsfeld@github.com>
Co-authored-by: Nathan Sobo <nathan@github.com>
