Telescope support

[stefanwatt]

fixes #1

• removed dependency to config from api
• refactored config to only handle config -> json stuff is done in json module
• adapted config class to allow user to specify adapter
• removed unneccessary call to config.setup in plugin/cd-project.lua

[LintaoAmons]

Hi stefanwatt,

Really thanks for your efforts and this PR!

I think split into those modules are nice and easier for later enhancements and maintainance.

I have some ideas wants to discuss:

How to use the config module.

I see you pass it as a variable into functions, which is good to make it explicit.
But I think I would like to simplify the args of functions and define this config as sort of a global stuff which can be used anywhere if the function need it.

So, like the Api functions. I want to make the functions easier for user to call anywhere else. They don't need to consider about what config args they need to prepare and pass it into the API.

[LintaoAmons]

If we remove this setup call in the plugin entrypoint, the user have to call the setup function when they add the plugin in their configuration.

[stefanwatt]

Isn't that desirable?
Currently it's running twice if you have a custom configuration.

[stefanwatt]

Yeah to be honest I also wasn't sure how to do it.
The approach from before was resulting in a cyclical dependency between api and config. This was what I came up with to break that cyclical dependency, but I also don't love that you have to pass config values as parameters everywhere.

Do you have a pattern in mind?

[LintaoAmons]

The approach from before was resulting in a cyclical dependency between api and config.

I don't realise that I was calling something from API in CONFIG?

So in my mind, the layer should be something like

   Adapter   
      │      
      │      
      ▼      
     API     
      │      
      │      
      ▼      
    Config   

So API can directly invoke anything exposed in config

[stefanwatt]

I'll check again when I get off work, but there definitely was a cyclical dependency. Maybe it wasn't there before the PR and was a result of the refactoring.

What do you think about using a global variable to make the config accessible?

I just think it's kinda weird for other modules to import config. Seems like that should be something that's only used to call the setup function.

[LintaoAmons]

Global variables are also a quite good option for configuration, but I think community is more in to the setup function.

I suppose that other modules require config is quite common? Since the behaviours are controlled by the configuration, it will always have this kind of dependency, no matters it is passed in by parameters or imported directly.

[stefanwatt]

I just pushed something.
The global variable for the config doesn't mean you can't/shouldn't still have a setup function.
I use it just for access from other modules.

I couldn't find another clean way to require config everywhere. At some point you still end up with a cyclical dependency. For example:
api -> config -> usercommands -> api
I'm pretty happy with the way it's done now tho.
Curious to hear what you think.
If you know a way to do it differently, then please tell me.

[LintaoAmons]

Sorry, just found that the merge is not based on your branch, my bad.
Can you add some commit like changes the files format, then format back. And then I will merge it