[Edge case] Implicit or relative target folder in `sorting-spec` -> folder rename requires manual re-application of custom sort, otherwise the order is not applied

[SebastianMC]

Affected scenarios:

• sorting specification is placed in a folder (e.g. in sortspec file in a folder), AND
  • the target-folder: is specified as ., which means 'containing folder', OR
  • the target-folder: part is omitted, which implicitly means 'containing folder'

When the container folder is renamed, the specific custom sorting specification is no longer applied to it, until the sorting is explicitly or implicitly refreshed.

Technical underlying reason

When the sorting specification is compiled by the plugin, the relative or implicit target folder path is translated to full absolute path of the target folder. Then, when the folder is renamed and Obsidian - implicitly - refreshes the sorting, the target folder path stored in compiled sorting specification no longer matches and is ignored.

Solution

An edge case, the fix boils down to monitoring folder rename events and reacting if the renamed folder was covered by custom sorting order based on relative or implicit target-folder: specification. Could be tricky, need to evaluate the approach - either force sorting spec recompilation or finetune the existing compiled specs. Or maybe it is not worth it at all because of potential complexity. To be decided.

The scenarios out of scope:

• when target folder is specified using any form of wildcard matching - the custom sorting will still be applied automatically after rename
• when target folder is specified explicitly by name - by definition folder rename will make the relevant sorting rule(s) no longer applicable