Better default titles in search: Remove file format ending

[kaixin-hc]

What is the purpose of this pull request?
Fixes #1803 .

• Documentation update
• Bug fix
• Feature addition or enhancement
• Code maintenance
• Others, please explain:

Overview of changes:
When searching for a file that doesn't have a specified title, return an autogenerated title which is the file path minus the file format ending. For example, if the filepath is userGuide/index.md, it returns userGuide/index.

Anything you'd like to highlight / discuss:

Testing instructions:
One way to test this is to remove userGuide/index.md from the unsearchable files in site.json on the markbind documentation site.

Proposed commit message: (wrap lines at 72 characters)
Improve default title for search by removing file format ending

---

Checklist: ☑️

• Updated the documentation for feature additions and enhancements
• Added tests for bug fixes or features
• Linked all related issues
• No unrelated changes

[ryoarmanda]

A little nit below:

[ryoarmanda]

Although not a major issue considering how the normal situation would be like, this would give unexpected results when the file has no extensions (index would be presented as an empty string) or "double" extensions (index.tar.gz would be presented as index.tar)

The latter case seems a bit unlikely to be passed on in normal development situation so I guess it's okay to not cover that (let me know if you feel otherwise though!), but it's good fault-tolerance if we can handle the former case, so it still returns the file name.

[tlylt]

For the latter case, If there is a file of type .tar.gz, will the search check the content of such files, or, will it be useful for the search to check the content of such files? I am guessing not really, so I think it is fine since typical files that we are getting the content from are .md or .html.

Not too sure about the search implementation and hence cant comment on the formal case/other possible cases.

[ryoarmanda]

Okay, I have delved in a little bit on how we include pages and the search, and looks like the latter case (and probably the former too) can be reasonably ignored 😅

Search data comes from siteData.json, which is written by Site, that includes data from Site.pages, which in turn is collected from site.json properties (pages, globs, and the likes). I guess we can reasonably believe that search results come from page files and not any arbitrary file. As our page files are of the normal extension form (.md and .html), then we can assume that the latter case would not happen.

By extension (heh), the former case shouldn't really happen as well. But I still think it's good to be safe rather than encountering a case where the result are empty strings one day. 😄

[kaixin-hc]

I investigated this suggestion more as well, and found the following code in NodeProcessor.

      const fileExt = path.extname(file);
      if (fsUtil.isMarkdownFileExt(fileExt)) {
        const renderedContent = this.markdownProcessor.renderMd(content);
        // Wrap with <root> as $.remove() does not work on top level nodes
        parser.parseComplete(`<root>${renderedContent}</root>`);
      } else if (fileExt === '.html') {
        parser.parseComplete(`<root>${content}</root>`);
      } else {
        const error = new Error(`Unsupported File Extension: '${fileExt}'`);
        reject(error);
      }

In other words, MarkBind only supports .html or .md. If you deliberately include a 'page' which doesn't have a supported file format ending, the Unsupported File Extension: error is thrown and the website cannot build at all.

So I think both the former and the latter case are invalid inputs that will safely never happen under the current implementation 😅

[ryoarmanda]

Thanks for the deeper investigation @kaixin-hc, we can safely use this implementation then 😄

[ryoarmanda]

LGTM 🎉