Hello, Thank you for your replies and your time.
So, I go with solution number 1:
* A HTML search engine is defined with a function, in a similar way to
what we have with export backend definition.
* To enable the search engine in an Org publication to HTML pages, a user
only have to set the corresponding option in its org-publish project:
:html-search-engine
By default, `:html-search-engine` is set no nil. And that mean no search
engine. To use PageFind, the user need to set the option like this in
its org-publish project:
:html-search-engine pagefind
A search engine is defined with:
* A symbol name
* An HTML template for the search field
* An HTML template for the header
* A function to do the indexation
* A function to install the dependencies on the generated website (ex:
CSS and JS file)
Of course, any of these option could be set to `nil` if not necessary to
a search engine. And the functions, when executed, will receive the
org-publish project options.
For the first search engine, I will use of using PageFind. And it would
require that the user have `pagefind` in its PATH. And I could define an
org-publish project option specific to this search engine like
`:pagefind-path` to let user define a custom path to the `pagefind`
executable.
I will start to work on it when I can.
Ihor Radchenko <yanta...@posteo.net> writes:
> Sébastien Gendre <s...@k-7.ch> writes:
>
>> # Solution 1
>>
>> After looking at Pagefind, I was thinking of taking inspiration from
>> "org-export-define-backend".
>>
>> Creating a function named like "org-html-define-search-engine" and that
>> will have as parameters:
>> ...
>
> This looks reasonable and flexible. +1
>
>> # Solution 2
>>
>> I was looking into tools suggested for the Hugo static site
>> generator:
>> https://gohugo.io/tools/search/
>>
>> And this was interesting:
>> https://gist.github.com/eddiewebb/735feb48f50f0ddd65ae5606a1cb41ae
>>
>> It use Hugo to directly generate an Index: It is configured to export
>> the home page into JSON in addition to HTML. Then, it use Fuse.js to add
>> a search field in the generated HTML.
>> ...
>
> This sounds too specific.
> Also, I think that implementing #1 does not prevent us from #2 if we
> choose to.
>
>> But: A JSON org-export could be useful for other case. After all, an
>> org-mode file containing headings with properties is a form of database.
>> Other persons could find an utility to have a JSON exporter.
>> ...
>
> Maybe, but that's a completely separate topic.
>
> In the context of search engine support, tying things to hugo is
> probably too limiting, unless you think that it is better than pagefind
> (it seems not as implementing it would be more complex).
>
>> And we maybe do an hybrid solution between solution 1 and 2:
>>
>> - We can have a function to define new search engines plus a simple
>> option in org-publish project to choose the used search engine
>>
>> - And having an official JSON org exporter can be used for some search
>> engines when we prefer to do the index with Org-mode/Emacs
>>
>> - And the official JSON exporter can also be used manually for people
>> who want or need it
>
> For JSON exporter in general, it might be useful, but I doubt that we
> need such exporter in the core. Unless we can actually use it somewhere
> in the core.
>
> I generally oppose adding things to the core left and right, simply
> because it will be me who will need to maintain yet another extra
> library. And that should either be justified by large benefits to users
> or by necessity to implement some other important feature.
signature.asc
Description: PGP signature
