Fixes#13729
Previously, when adding a window, we were unable to read its current
project paths out of the hash of the URL during window initialization
because the window still considered itself to be loading. Rather than
fixing this issue, we decided to completely eliminate the sharing of
state between processes in the window.location and instead switch to
cached synchronous RPC for the loadSettings and a dedicated RPC-based
mechanism for the project paths.
Fixes#13647.
This restores the behavior we had prior to #13475 when there are no pane
items while preserving its improved behavior for paths outside of the
current project.
I updated the list of text encodings that appear in the Settings configuration menu to properly reflect the code pages supported by [encoding-selector](https://github.com/atom/encoding-selector), as well as present descriptive text in the selection menu.
In the process, I removed what appeared to be a duplicate entry ('iso88597').
Note: I don't know if this change will affect the functionality of the menu, but I presume a more experience coder can figure this out.
This regression was introduced with the removal of the shadow DOM from
`<atom-text-editor>` elements. Previously we were relying on Chrome
always reporting `<atom-text-editor>` as the mousewheel `event.target`.
As a result, removing the shadow boundary caused the mousewheel event to
be potentially dispatched from anywhere inside the editor element,
making our previous logic for handling ctrl-mousewheel invalid. This
commit fixes it by recognizing mousewheel events that are dispatched
from within an editor.
We are working on a feature that changes the content of the editor when you mouse over some things and it makes the UI jump when going from 1 line to > 10. This makes the UI feel really bad.
I've looked at Sublime and the 1-9 state is the same as 1-99, only when you reach 100 lines then it jumps. I think that it is a better behavior as you want to minimize jumps as much as possible and it is extremely likely that you are going to hit the 9-10 lines threshold.
While this is being reviewed and until the new version shipped, we are going to monkeypatch Atom in order to get this feature.
```js
var presenter = atom.textEditors.editors.entries().next().value[0].presenter.__proto__;
var old_updateLineNumberGutterState = presenter.updateLineNumberGutterState;
presenter.updateLineNumberGutterState = function() {
var res = old_updateLineNumberGutterState.apply(this, arguments);
this.lineNumberGutter.maxLineNumberDigits = Math.max(2, this.lineNumberGutter.maxLineNumberDigits);
return res;
};
```
Released under CC0
Writing so much data to IndexedDB is blocking the main thread for
perceptible amounts of time. A patch-based representation of the
modified state could allows us to pay only for what has changed, but is
too complex to justify implementing right now to support full crash
recovery for large files.
Signed-off-by: Max Brunsfeld <maxbrunsfeld@github.com>
Calling `workspace.open` in an opener doesn't work properly with options
like `split: left` because it causes the opened item to be added to the
workspace as a side-effect. Since workspace openers are intended to be
used during the process of calling `workspace.open`, we need to use
`openTextFile`, which just creates an editor but does not attach it to
the workspace.
