Dendron: Group Notes into Hierarchy

[hikchoi]

Context

https://github.com/dendronhq/dendron/issues/657 describes a use case where notes are written at a hierarchy that is fairly close to the top, but later needs to be refactored into a deeper hierarchy.

This is possible with the existing Refactor Hierarchy command, but in limited situations where it is trivial to come up with the right regular expression to match all the notes you want.

This proposal generalizes this use case so that the user can look up and select multiple notes they want to group into a specific hierarchy.

Proposal

Add a new command Dendron: Group Notes into Hierarchy (name pending)

When triggered, prompt the user with a note lookup with multiSelect enabled. Here the user can choose which notes should be grouped.

on accept, prompt again with another note lookup with multiSelect disabled. Here the user can choose an existing note to be the parent of the previously selected notes, or create a new note to be the parent.

Lastly display a webview with what the changes are going to be, before proceeding with the grouping.

Rationale

This eliminates the need for the user to come up with the right regular expression, which in a lot of cases isn't a good user experience.

This separates the intent of the user from what the (refactor) command can do, and better aligns with the user's expectation.

It also significantly reduces the complexity of the implementation as well as possible future troubleshooting.

Limitations

Any number of notes over the pagination limit of lookup could not be grouped with a single trigger of this command.

manually clicking multiple notes could be annoying.

Possible enhancements (and any other related items not in scope of this work item)

• use active selection in editor as grouping parent note
• enhance Refactor Hierarchy so that it accepts the full range of regular expression beyond wildcards (e.g. lookaheads and lookbehinds)
  • this has a bit of overlap with advanced querying of notes, and is mostly intended for advanced usage / bulk operations, so it will need to be specced out a bit more beforehand.

[kevinslin]

I think this command makes sense but would add this to our backlog. Meanwhile, having a general refactor that has full regex support is desirable because it handles a fuller spectrum of cases

[hikchoi]

Sounds good. Was mainly concerned about addressing #657 in a simpler way with my proposal.

I think once refactor can support full regex, we should consider adding easier ways to manipulate the note hierarchy similar to how this proposal does (focusing on one specific intent, and making it user friendly). Being hierarchy-based is something that differentiates us from other tools so doing so will strengthen what we are trying to do.