This is a totally subjective style change. I just prefer keeping code
that is rarely changed tight and dense. Another option would be to
move the menu templates into a separate file.
Ideally both window closing and reloading should use 'beforeunload' to
control whether the unloading should continue, however since the save as
dialog is asynchronous, we have to prevent unloading first and then
continue after user's confirmation. And since we can not distinguish
whether the window is reloading or closing in the 'beforeunload'
handler, we do not know what to continue after user's confirmation. So I
have to rely on BrowserWindow's 'close' event to let user decide whether
window should be closed.
When user wants to close the window, the 'beforeunload' event would be
called, then the closing would be cancelled and the 'window:close'
command would be triggered. In the 'window:close' handler, a confirm
dialog could be showed if there are unsaved contents, and if the window
is really meant to be closed, the window would be tried to be closed
again and this time 'beforeunload' handler wont't prevent it.
In Atom, the 'beforeunload' event never prevents window from closing so
it in fact has the same effect with 'unload' event, I guess using
'beforeunload' instead of 'unload' is because the 'beforeunload' is
guarrenteed to happen when window is closing or application is quiting.
However in Atom Shell the 'unload' event is guarrenteed to happen on
both conditions, just like the 'beforeunload' in Atom, so it's safe to
replace the 'beforeunload' with 'unload' here.
And in Atom Shell, the 'beforeunload' event is mainly used for
preventing window from closing, just like the 'window:close' command in
Atom.
Currently the toggleDevTools of atom-shell is simulated by keeping state
of devtools, because there is no way to know the state of devtools in
brightray, so it could not behave correctly sometimes.
This problem will be solved when brightray is patched and atom-shel gets
updated.
For some reason, having flex-flow column on the pane item views
container was forcing the entire view to be repainted on cursor
movement and line edits. Allowing the container to flow row-wise and
setting the min-height to 0 instead of min-content-height achieves
the same layout effect without the huge repaint cost. Flexbox is a
fragile bitch.
If we remove a large number of screen lines when we are scrolled down,
the current @firstRenderedScreenRow may end up being larger than the
number of screen rows we now have. Setting renderFrom to the
@firstRenderedScreenRow in this case was causing the renderFrom to be
larger than the renderTo, which was causing problems downstream with
the new mapping code.
Now that ScreenLines don't contain the bufferRows property, which was
essential to the functioning of the LineMap, they're just containers
for tokens. Since they're stored in the TokenizedBuffer in a form that
doesn't necessarily match what ends up on screen, it makes more sense
to call them tokenized lines. A tokenized line is a screen line if it's
in the `.screenLines` array of the DisplayBuffer, but "screenness" is
not an inherent property, so it shouldn't be in the name of the class.
Previously, we used bufferRows to determine how many buffer rows were
spanned by the screen line in the event it was folded. Now that we have
RowMap, screen lines don't need to serve this purpose. We still need
to know if a screen line is wrapped, which we solve via setting the
lineEnd property to null for a soft-wrapped screen line.
