Issue with directory-wide nim config scripts

[Wazubaba]

Hi, I noticed that while a per-module config script is properly used (ex: myscript.nims works for myscript.nim), the dir-wide versions (config.nims or nim.config) are not processed. This causes incorrect error highlighting for a lot of things, including the unit-tests generated by nimble since this plugin is not passing the imports to nim-suggest as far as I can tell. It also results in broken imports not being highlighted as well.

[alaviss]

Can I have the directory structure of your project, as well as the output of :echo nim#suggest#FindInstance() once you opened a file in the project?

[Wazubaba]

The config.nims file contains switch("path", "..")

/README.md
/multilang.nim
/multilang.nimble
/tests/
      /config.nims
      /test.nim
      /tree1.ini
      /tree2.ini
      /tree3.ini

{'addCallback': function('<SNR>43_instance_addCallback'), 'job': 3, 'start': function('<SNR>43_instance_start'), 'file': '/home/wazubaba/dev/code/nim/lib/native/multilang/multil
ang.nim', 'stop': function('<SNR>43_instance_stop'), 'cmd': 'nimsuggest', 'oneshots': [], 'on_exit': function('<SNR>44_bufCb', [{'cb': function('<SNR>43_instanceHandler'), 'buff
er': {'buffer': '', 'process': function('<SNR>44_process')}}]), 'on_stdout': function('<SNR>44_bufCb', [{'cb': function('<SNR>43_instanceHandler'), 'buffer': {'buffer': '', 'pro
cess': function('<SNR>44_process')}}]), 'message': function('<SNR>43_instance_message'), 'project': function('<SNR>43_instance_project'), 'isRunning': function('<SNR>43_instance
_isRunning'), 'cb': function('<SNR>42_onEvent'), 'query': function('<SNR>43_instance_query'), 'port': 51455, 'isReady': function('<SNR>43_instance_isReady'), 'contains': functio
n('<SNR>43_instance_contains'), 'on_stderr': function('<SNR>44_bufCb', [{'cb': function('<SNR>43_instanceHandler'), 'buffer': {'buffer': '', 'process': function('<SNR>44_process
')}}]), 'args': ['--autobind', '--address:localhost']}

[alaviss]

I think I know why this doesn't work, though I must say this kind of folder structure is a bit unconventional...

Does everything work if you open a file in tests directly from a fresh neovim session? I think I got a fix if that case work.

EDIT: I know exactly why this doesn't work now, fix follow soon.

[alaviss]

With the commit I merged, directly opening tests/test.nim will work.

However if you're working on multilang.nim and you decided to switch to tests/test.nim within the same neovim session, this will not work out of the box. The reason is due to how project management is done:

If a nimsuggest session is activated for multilang.nim, then any file opened within the same folder will reuse that session. Ie.

/README.md
/multilang.nim <- opened, spawned a nimsuggest instance on /
/multilang.nimble
/tests/
      /config.nims
      /test.nim <- if gonna be opened, will reuse the nimsuggest instance
      /tree1.ini
      /tree2.ini
      /tree3.ini

This is based on the simple fact that multilang.nim can import any file in tests/ due to tests/ being a subfolder, thus we assume that anything in tests/ is a part of multilang project and we should reuse the spawned nimsuggest instance to avoid (potentially) recompiling everything.

Of course, this is false for your project in particular, as tests/ is actually a project on it's own (for example if you import a file in tests/ from / it will error out because the inner config.nims won't be used). Currently I can only offer these walkarounds:

• Don't use config.nims and use import ".." / multilang instead.
• Use the standard src/ subfolder scheme that's the default for new nimble projects.

I'm considering whether this sort of "subproject within project" should be supported by default, since it doesn't respect the hierarchy of a Nim project. Though I'll tell you now that there's a high chance of ootb support given my goal for this plugin is to be foolproof...