fix(config): fetch configs if user has configured (#66)

[kevinhwang91]

No description provided.

[danymat]

What is the purpose of the meta table then ?

[kevinhwang91]

Defer load. If I only use Lua filetype, I don't want to load all of the filetype configurations.

[danymat]

I tried to print inside it, but it seems that it is never called

[kevinhwang91]

Remove your filetype configuration and print again.

[danymat]

It seems to work, however, the get_template() still not work because conf.languages is only holding added languages information.

To test: print(vim.inspect(require('neogen').get_template("lua')))"

[kevinhwang91]

No, it will work, check out your config.

[danymat]

Hmm, i don't get it then. conf.languages is not resulting to anything, for example ruby is broken because in config.setup, we only loop over custom setup

[danymat]

Okay after digging a little bit, I found out that modifying the template with the template API, for example:

require("neogen").get_template("python"):config({ annotation_convention = "numpydoc" })
Is not going to work, I guess because the table is generated from the __call, and the reference is not kept with _data

[kevinhwang91]

It's not related to this issue. template.config just extends the table and doesn't assign the value back to conf.languages[ft].template is holding.

[danymat]

I'm kinda scratching my head right now, because of new behavior. Let me explain:

• Before merging refactoring, the neogen template api (:h neogen-template-api) did succeed in updating a configuration even if there was no merging table back to config (as you mentioned here: fix(config): fetch configs if user has configured (#66) #67 (comment)), because the reference to the table was somehow the same.
• Now that the refactor gets the configuration for a language with an other way, the template api is not working anymore if we want to modify the template

That means we have to decide:

• keep the api and try to fix this, by somehow "saving" the new content back to the configuration table
• Delete the API (or keep it private only for setting up the languages). I don't really like this way, but it's a way of doing things.

Any thoughts @kevinhwang91 ?

[kevinhwang91]

That means we have to decide:

1. keep the api and try to fix this, by somehow "saving" the new content back to the configuration table
2. Delete the API (or keep it private only for setting up the languages). I don't really like this way, but it's a way of doing things.

I suggest you delete the API. Users already have setup function to change the config to do what they want.
Assume one day, a user posts an issue and you found s/he changed neogen's configuration inside multiple files or functions (via API and setup function), how could s/he easy to reproduce the issue?
More API more scratching, you can't easy refactor the code base and the code will be rot in the future. TBH, neogen is not a lib and If you want to maintain this plugin easy and happy, you should close the redundant API and keep the plugin stable and simple. For me setup function is enough to customize neogen.

FYI, I have two Lua plugins in maintenance, they are easy to maintain because of less APIs or options.

[danymat]

Thanks for the feedback, I pushed a new version to make this API private