[Idea] Server mode

[iazel]

I keep thinking on how awesome would be to have a server mode to give a much better IPC so that it's easier to build plugins with this kind of functionality, eg: a nvim plugin.

My current plan is to use Unix Domain sockets and to provide 4 operations:

• Initialize Bucket: Will create and initialize a new bucket, which is basically a container for the provided inputs and can be searched multiple time.
• Search: the actual fuzzy finder, which will return a list of matching for the given input in the given bucket. This should have some way to highlight characters in the same fashion as it already does. Would be nice to provide also the score and each pos to highlight, but this could come in a second iteration.
• Insert: will insert values in a bucket. Basically an incremental insert
• Remove: will remove the given values from the bucket. Same behavior as Insert

The buckets will be stored in memory for now, but next iterations could introduce a persisting operation.

Right now I think it would be easy to provide some custom protocol to build it on, like:

Search protocol:
1 Byte for OP
1 Byte for Bucket ID
N Byte for search term (up to 1024)
1 Null byte to signal termination

If succeeds, will respond with:
1 Null Byte for signaling Success
4 Byte Nr. of results
8 Byte Total nr. of searched strings
N Byte null byte separated results

If fails:
1 Non-Null Byte Error code

However I'm also considering to use msgpack for easier extensibility; the problem is that I've never used it and could take some time to start with xD

What do you think? Any suggestion? :)

[KoFish]

Implementing a easily parsable output-input schema would probably be a good thing. But I can't see any ups with IPC. The only thing I could see is that it would make it a lot easier to accidentally introduce memory leaks.

[iazel]

I think instead that IPC is pretty cool because you don't need to pass the input every time, saving quite some time for big and frequently used inputs (eg: all files in a big project repo) and open up to a possible pre-processing step that will make the algorithm computation even faster!

It's true it can introduce memory leaks, but I'm sure we can also fix them! ^^

[jhawthorn]

Hi @Iazel, thanks for the issue but I will not be implementing this. I intend to keep fzy minimal and unix-y.

You're also welcome to fork fzy and implement this yourself. choices.c and match.c should fix this usecase well and need minimal (if any) changes.