Refactor unlinked references section code for more customizability

[okomestudio]

Brief Abstract

I propose refactoring the org-roam-unlinked-references-section function to give users more options to customize the section behavior through custom variables and advising functions used in key steps within the function without replacing it in its entirety.

Long Description

The unlinked references section of org-roam buffer is constructed through a basic algorithm using ripgrep and filtering, much of it hard-coded which prevents users to tune any part of the behavior. I am fond of unlinked references for serendipitous discovery, but the current implementation limits the use cases to the simplest word matching with word-level tokenization.

For example, I have the following issues with the current implementation.

• The hard-coded word boundary regex in org-roam currently doesn’t accommodate regex parsing documents written in one of the CJK languages, which needs more than \b for identifying word tokens

• The regex matching isn’t flexible enough to handle variant characters, e.g., “Denny's” and “Denny’s” are considered different, when a regex pattern matching them is straightforward to write

Currently, implementing these would require replacing the
org-roam-unlinked-references-section function in its entirety. After the proposed refactoring, these can be solved though customizing variables and advising functions without intrusive code change to the source code.

The org-roam philosophy when it comes to customization seems to be to let users replace the whole function(s) after feature loading (see, e.g., this discussion. While this might be sufficient and incurs lower maintenance cost, by refactoring relevant code judiciously, users can tailor the code behavior more to their needs through custom variables and function advising while still benefiting from the overall logic, which is be mostly sound. Pure refactoring maintains the current logic, leaving the existing users unaffected by it.

Proposed Implementation (if any)

A proposed implementation is given in #2417.

Please check the following:

• No similar feature requests