Summary
On systems with a file system that is not sensitive to case (e.g. Windows and MacOS), Sublime Text internally treats files as identical as long as the only difference is their case. Thus for example, DEFAULT/exec.py, Default/EXEC.PY and Default/exec.py are all treated as identical. This also follows for sublime-package file names, wherein you can create a complete override of Lua.sublime.package with a LUA.sublime-package.
OverrideAudit works with these files the same way that Sublime appears to in this situation, and uses the names and contents of the shipped and installed sublime-package files as "gospel" when determining what file names should be represented as.
It is conceivable that someone going from e.g. Windows to Linux and transferring their configuration over could find themselves having issues, where suddenly their overrides no longer function the same way as they used to.
This could manifest as whole new competing packages, duplicated extensions (e.g. menu item additions) or in the case of python plugin files and load order commands that don't operate as expected.
My initial thoughts for this would be to treat it similarly to #15 as a potential new report that shows you issues that may crop up, along with a confirmation to repair them, but there may be a better way.
Parts of this may be covered by #16 for overrides files that are in a correctly cased package directory but have the wrong case themselves. Additionally this may suffer from the same potential issue as #15 if implemented as a report and the contents change.
Summary
On systems with a file system that is not sensitive to case (e.g. Windows and MacOS), Sublime Text internally treats files as identical as long as the only difference is their case. Thus for example,
DEFAULT/exec.py,Default/EXEC.PYandDefault/exec.pyare all treated as identical. This also follows forsublime-packagefile names, wherein you can create a complete override ofLua.sublime.packagewith aLUA.sublime-package.OverrideAudit works with these files the same way that Sublime appears to in this situation, and uses the names and contents of the shipped and installed
sublime-packagefiles as "gospel" when determining what file names should be represented as.It is conceivable that someone going from e.g. Windows to Linux and transferring their configuration over could find themselves having issues, where suddenly their overrides no longer function the same way as they used to.
This could manifest as whole new competing packages, duplicated extensions (e.g. menu item additions) or in the case of python plugin files and load order commands that don't operate as expected.
My initial thoughts for this would be to treat it similarly to #15 as a potential new report that shows you issues that may crop up, along with a confirmation to repair them, but there may be a better way.
Parts of this may be covered by #16 for overrides files that are in a correctly cased package directory but have the wrong case themselves. Additionally this may suffer from the same potential issue as #15 if implemented as a report and the contents change.