<p dir="auto">Right now the base style sheet (everything in /static) is loaded before everything else (<a href="https://github.com/atom/atom/blob/master/src/window.coffee#L38">https://github.com/atom/atom/blob/master/src/window.coffee#L38</a>). It is done before the config is loaded and before the theme directories are added to the LESS import path.</p>
<p dir="auto">Loading like this keeps the base css separated from the themes, but it doesn't allow for usage of  variables from <code class="notranslate">ui-variables</code> in the base css. If variables were used, they would come from <code class="notranslate">/static/ui-variables.less</code> rather than the theme. So if the base <code class="notranslate">ui-variables</code> specified a <code class="notranslate">@component-padding</code> to be 10px, and my theme wants it to be 20px, I would need to override everywhere the padding is used in my theme with css rules. If the base css could import from the theme dir, my theme could just set the <code class="notranslate">@component-padding</code> variable to 20px.</p>
<p dir="auto">I propose we place the theme directories on the LESS import path when the base css is loaded. Here are the 2 secnarios</p>
<h3 dir="auto">Loading base css with access to themes</h3>
<p dir="auto">Here’s what would need to happen</p>
<ul dir="auto">
<li><code class="notranslate">config.load()</code> needs to happen in <code class="notranslate">window.setUpEnvironment</code> (Will this slow things down?)</li>
<li><code class="notranslate">ThemeManager</code> needs to get the generate the theme directories based on the <code class="notranslate">core.themes</code> config option, rather than the loaded themes.</li>
<li>Need to rebuild all the css when themes are changed</li>
</ul>
<p dir="auto"><strong>Pros</strong></p>
<ul dir="auto">
<li>Many things can be pulled into the base css. Most of the button styles, list styles (tree views, etc), text styles, some mixins. The themes do a lot less. There will be less repetition between themes.</li>
<li>We can override bootstrap variables in the themes, requiring less css overall.</li>
</ul>
<p dir="auto"><strong>Cons</strong></p>
<ul dir="auto">
<li>When a theme is changed, we would need to recompile <em>all</em> the css, not just the theme and package css. The bootstrap and the base css as well. Probably not fast.</li>
<li>Others I’m missing?</li>
</ul>
<h3 dir="auto">Leaving it the way it is</h3>
<p dir="auto"><strong>Pros</strong></p>
<ul dir="auto">
<li>Changing themes is only medium slow.</li>
</ul>
<p dir="auto"><strong>Cons</strong></p>
<ul dir="auto">
<li>Much more repetition between the themes. The new light and dark themes will have a lot of code duplicated between the two.</li>
<li>A little awkward because there is this <code class="notranslate">/static/ui-variables</code> file and nothing in <code class="notranslate">static</code> uses any of the variables from it.</li>
</ul>
<p dir="auto">How do you guys feel about this?</p>
<p dir="auto">If this is a duplicate please disregard:</p>
<p dir="auto">If I open several large files atom becomes unresponsive.<br>
After i am prompted with the force close dialog then i can close it.<br>
When i open it again in the same path the previously open files are opened again, which causes atom to become unresponsive again.</p>
<p dir="auto">The files are some browserified js bundles.<br>
I think they are prerendered even if the tab does not have focus which makes the editor freeze - that would be my best guess.</p>
<p dir="auto">The workaround i found is to delete the files from disk and opening the files again(atom .) .<br>
I mainly use atom from the command line call using atom . to open the current folder and the files in it.</p>