search

OdatNurd / OverrideAudit

Easily Manage Your Sublime Text Package Overrides
https://odatnurd.net/overrideaudit/
MIT License
39 stars 7 forks source link

[RFC] Support for Complete Overrides? #23

Open OdatNurd opened 7 years ago

OdatNurd commented 7 years ago

Summary

Currently the only thing done with complete overrides is to tell you when they exist, check them to see if they're expired or not and to ensure that their source package is used as the base when diffing and determining overrides. #15 would add the ability to accept them as still valid if desired.

There could be something similar to the existing reports and diffs that would let you work just between the two packed versions of the file and ignoring the unpacked file, if any. Doing so would allow you to see things like how your complete override differs and if the composition of the package has changed.

I'm not sure exactly how useful that would be because I'm not entirely sure how popular such a complete override is. The initial version of OA has the required code to collect that information but it's not realized in any commands.

If it's not a particularly common practice then in all likelyhood just having an indication that there is a complete override and it may need to be reconsidered could be enough in the short term.

keith-hall commented 7 years ago

I think this would be really useful, even if it is not currently common practice - I'm thinking of working on a plugin that will periodically check the Default Packages repo, and create/update an Installed Package per folder in that repo when something changes on the master branch, so one can have the latest changes in a package without them being unpacked overrides - i.e. to allow one to have overrides of those and see what the changes are compared to what's on the master branch. This will also work around the auto-reload not working with symlinks problem (https://github.com/SublimeTextIssues/Core/issues/187) that otherwise plagues us syntax definition devs :)

OdatNurd commented 7 years ago

That is a very interesting use case, I must say. :)

In that case it could logically be expected that the override sublime-package has the same list of files, possibly just with the occasional addition or removal, which makes the existing functionality work well in that case.

I tried to take pains to make all of the API calls that do things like collect overrides and detect them take a parameter that indicates which kind you meant, so implementing something like this could be as "easy" as adding an extra parameter to the existing commands that specifies which set of overrides to use.

Actually having a good use case for this is a good argument for shifting it upwards in the priority list.