Any plan for adding search capabilities?

[franzinc]

markserv is a really nice project. Users of my internal documentation are complaining about no search, though. Are there plans to add it? Are there easy ways to use an internal tool to add it? Thanks for creating cool software that is useful and easy to config.

[F1LT3R]

Work in progress:
https://github.com/F1LT3R/markserv/tree/lunr-search

[e40]

Is there any update on this, aside from the "work in progress" above?

[F1LT3R]

@e40 - no updates at the moment.

It's quite a large body of work to implement this, so I'm not sure when I will be able to take it on.

I'm more than happy to accept PRs for search capabilities. On that branch, or with a completely fresh take.

There are open design questions around search that should be addressed:

1. Should search be available on every page, or just the table of contents?
2. Should search be showing results of the files as they are on disk, or the rendered output of files? Or both?
3. Should search results include files that have been included/implanted/nested, or show the nesting tags? Or some combination, with options?
4. Should search results be cached to disk for a project? If so, what should that cache look like?
5. Should the search results be a new screen, or some form of modal?

Do you have ideas for this @e40 ?

[zuedev]

@F1LT3R If I may, I'd like to offer my two cents into this discussion.

1. Should search be available on every page, or just the table of contents?

I think that a search input should be available on every page that has the rest of the theme present, such as any non-raw file, as it would allow for the greatest mobility and ease of use for the user. Also, a hotkey to focus the search input would be nice! Ala, Google, YouTube, etc.

2. Should search be showing results of the files as they are on disk, or the rendered output of files? Or both?

I would personally like to see a snippet of the relevant result entry, just like how GitHub does it with their search. You get the convenience of previewing the matched content and the functionality of increased entries on the page. Best of both worlds!

3. Should search results include files that have been included/implanted/nested, or show the nesting tags? Or some combination, with options?

The search input should not include included files by default, but maybe a dedicated search page (or the results page) should allow the user to enable flags for a more comprehensive search?

4. Should search results be cached to disk for a project? If so, what should that cache look like?

Yes, in fact, we could explore some prebuilt or warmed-up cache options. Maybe allow the user to enable a flag on the cli that takes a moment at runtime to precache all markdown files in an easier to search format? If not, we could just cache as it's searched.

As for how it should look, I favour simple filesystem caching, such as a .cache folder in the root or something like that. Organised in some sort of key->property relationship where the key is the filename/location and the property is the indexed search/contents. Open to other options though!

5. Should the search results be a new screen, or some form of modal?

All on the page, and once it searches it should take you to a search/result page, just like the GitHub search flow.