Make .status-modified more specific in list-tree?


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.

For instance:
Here’s our tree:
-app --folder1 --folder2 --folder3 ----modifiedfile.something

modifiedfile.something will get the color of git-modified, as it’s parent li contains 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 status-modified coloring.


The default themes don’t have the issue you’re talking about, if I’m understanding you correctly. For example:


Interesting! I’ll do some deconstruction of how they implemented that!