As reported in #131 and later on in #135, the File Explorer recovery process from messed-up state could be confusing to the user. When Obsidian with breaking changes in File Explorer (1.5.4 or newer Obsidian release) meets the plugin in version earlier than 2.1.7, the File Explorer view stops showing correctly the deeper levels (2nd and deeper) of folders tree. The recovery process is multi-step and doesn't include only disabling/uninstalling the plugin, a restart of Obsidian is required.
Let me find out if a plugin (like custom-sort) is capable of graceful handling of the disable / uninstall scenario: detect the disabling / uninstalling action and, in the last second of its existence, impose the File Explorer view refresh with standard sorting. This would make the potential future scenarios of recovery from Obsidian breaking changes a little bit less confusing.
As reported in #131 and later on in #135, the File Explorer recovery process from messed-up state could be confusing to the user. When Obsidian with breaking changes in File Explorer (1.5.4 or newer Obsidian release) meets the plugin in version earlier than 2.1.7, the File Explorer view stops showing correctly the deeper levels (2nd and deeper) of folders tree. The recovery process is multi-step and doesn't include only disabling/uninstalling the plugin, a restart of Obsidian is required.
Let me find out if a plugin (like custom-sort) is capable of graceful handling of the disable / uninstall scenario: detect the disabling / uninstalling action and, in the last second of its existence, impose the File Explorer view refresh with standard sorting. This would make the potential future scenarios of recovery from Obsidian breaking changes a little bit less confusing.