search

Olical / aniseed

Neovim configuration and plugins in Fennel (Lisp compiled to Lua)
https://discord.gg/wXAMr8F
The Unlicense
606 stars 28 forks source link

Requiring a module that cannot be found results in opaque error on windows #65

Closed Kethku closed 2 years ago

Kethku commented 3 years ago

I have an aniseed config which works on windows. However when I tried to move to packer.nvim (by reading and emulating the magic-kit system) I started getting opaque errors like this: image

I came to realize that the errors are due to not a module (in this case foobar). But I was really struggling to understand what was going on because of the Undefined Variable C

I think that this has something to do with windows, but I'm not sure. C seems suspiciously like c:/ drive name. But that really is just a hunch.

bangedorrunt commented 3 years ago

@Kethku it's better if you could provide your config, or I could highly recommend you take reference from https://github.com/datwaft/nvim, he's using windows like you.

Kethku commented 3 years ago

https://github.com/Kethku/vim-config heres my config. Note: its currently working as I fixed the issues caused by using packer.nvim by switching to paq. Its easy to repro the problem though by adding something like {require {foobar foobar}} to one of the module definitions

bangedorrunt commented 3 years ago

Since you use paq, I have no idea what went wrong with packer. I'm using packer without any prob.

It is recommended by the creator to use autoload such as

(module foo
  {autoload {foobar foobar}})

;; Or short hand

(module foo
  {autoload {: foobar}})
Olical commented 3 years ago

You don't need to use autoload but it's a helpful tool for delaying some larger modules until they're used by a key mapping etc 😄

I think that this has something to do with windows, but I'm not sure. C seems suspiciously like c:/ drive name. But that really is just a hunch.

This is definitely a possibility... I actually did a bunch of work to support Windows paths a little while ago and had some happy (I think?) Windows users after that, so it could be the C:\ prefix but I have my doubts since every windows user would face that issue.

This may come down to needing some better error catching and logging although it's hard since Aniseed deliberately steps out the way for performance after it's compiled everything. The whole design is based around letting your code get required as Lua so you lose the original Fennel (which is why Fennel traceback support makes little sense for the aniseed.env stuff).

Your config is only Fennel while you work on it and before you restart Neovim, then it's just plain old Lua that has no link to Fennel without sourcemaps... something that Fennel doesn't support as far as I know. Just a little bit of context on why showing nice errors is hard 😓

That being said, I should see if I can get it to print the full stack trace somewhere, that should be a bare minimum. And with the new Aniseed module system in the next version you'll get MUCH more minimal and human readable Lua so it should be easier to debug, yay!

Olical commented 3 years ago

Interesting that it's only when you moved to packer though... odd! I'll have a deeper dig into this in some free time, work now, just wanted to acknowledge and drop some more context from my end.

Kethku commented 3 years ago

Just to be clear, I don't think packer has anything to do with it. My issues showed up because of a confusion I had with the order in which packer loads things. I couldn't figure out how to force packer to load from the compiled config so that I could then configure my syntax highlighting. So when I tried to set my color scheme in an aniseed module, the system would fail printing the above message.

So as an example, (module foo {require {foobar foobar}}) fails when foobar does not exist resulting in the opaque error message.

Sorry for the confusion