Most of my experience with debugging this comes from the Seti UI theme, however I think the same thing happens in the default Atom theme as well, since there isn’t specific enough classes to target.
I’ve noticed in trying to tweak the Seti UI that there is a class appended to the top level parent of a modified document called
.status-modified. That’s great, and really cool, however it doesn’t look very specific, which for modified files is a no-go. And by nature of added files, the parent scope should be good enough for coloring.
Here’s our tree:
-app --folder1 --folder2 --folder3 ----modifiedfile.something
modifiedfile.something will get the color of git-modified, as it’s parent
file.entry.list-item.status-modified. But also,
folder1, folder2, folder3 and
app will have that color too, as there is no
directory.entry.list-item.status-modified low enough in the list-styling scope. That class set only exists at the very beginning of the parent containers.
I would expect that
app (the root-root of the modified file) and
folder3 be colored per git-modified color.
I think the fix involves copying
.status-modified down to the
<ol class"entries list-tree"><li class="directory...>. That way we can target .status-modifieds no matter how deep they go, without polluting the folders relative to that same scope (
./) that also unfortunately get the