If the measure of a good day’s work is the sheer number of lines of change that git reports when you pull in the latest group of changes, then I really put in a hell of a lot of work today. On the other hand, if you measure it by the amount of effort that was put in, then that’s too bad because I want to feel better about everything that was done today.
Honestly though, even though the amount of time spent performing the change wasn’t that big, deciding how to go about it certainly took a bit of time.
The minor change today is that the authoring tools now have their own stub of a help system, and that the command for reloading the current help file has been enhanced so that if you press the appropriate key while you’re editing the source of the current help file, it reloads the file as well. This makes for a nice speed boost while editing help files.
This will need to be revisited again somewhere down the line because as it currently stands the F5 key now always performs a reload while in a help file. That might get in the way of people that want to use the F5 key for something else while editing text. This should be easily solved with the introduction of a setting that would turn off the binding if the user doesn’t want to use it, so I’m not worrying about it right now.
The more major change is that the structure of the code has been altered to physically separate the core hyperhelp package from the HyperHelpAuthor package, which are now stored in two distinct folders from within the top level of the source tree. Now that things have reached a state where help is viewable and can be authored, it’s time to split things up a bit.
Fundamentally the only change to the code required to support this is that things in the authoring tools need to change where they’re importing from so that if they import from the hyperhelp core they qualify their imports. More realistically, working the package this way means that instead of having it in the Packages folder it needs to be elsewhere, so that the two packages can be separate.
To that end I’ve modified my local setup so that instead of having the repository directly checked out in Packages with a name of hyperhelp, it’s now checked out in an external location and each of the two packages is now symlinked by name in the Packages folder instead. As far as Sublime is concerned they’re two packages now.
In order to make development work easier, when you’re working with external code that’s been symlinked into the Packages folder, it’s best to open the file from within Packages itself instead of from it’s internal location. Various tools (including the HyperHelpAuthor and hyperhelp packages themselves) rely on checking the path of a file to see if it’s in an appropriate location.
In this case, doing that means adding the appropriate folders to the project from their Packages location and then telling the project to exclude them from the top level directory so they don’t show up twice and mess up indexing and reference lookups. The sublime-project file in the repository now contains references to that folder directly, so if you use the code you may need to swap that.
The last thing I did along these lines is make a modification to AutomaticPackageReloader to allow it to still work. As I mentioned above, various packages use the path of a file to verify that they’re in the Packagesfolder, and this is one of them. Since it only makes sense to try and reload python files that are plugins, and that’s where plugins live, it’s a great test.
Unfortunately an issue with it is that it calls os.path.realpath() on file names as it’s trying to process them. That makes all symlink references be replaced with where they point, which makes the paths no longer in the packages folder, which causes it to no longer reload them. To fix this I removed that call so that files are left alone.
After the fact I discovered that Sublimerge (a package I use to do diffing) can’t tell that files are in source control in this case (ironically, it should probably be calling os.path.realpath() on the files), which makes my usual work flow of using that package to vet changes before I commit more hairy.
I’ll have to think on that some more, but I think the only solution there would be to use hard links on all of the files instead of symlinks on the two package folders. That’s more of a pain in the butt to maintain in the long term, but since the layout only needs to work this way until the end of December (at which point the code will become two repositories), that may be worth doing in the interim.