`lush.parse` error when basing from another specs

mcchrish commented 2 years ago

local lush = require "lush"
local base = require "zenflesh" -- some spec

local specs = lush.parse(function()
    return {
        TabLine { base.TabLine, gui = nil }, -- setting gui to nil, not "italic"
    }
end)

lush.apply(lush.compile(specs))

But it works with extend or merge.

Work around is to do something like:

TabLine { bg = base.TabLine.bg, fg = base.TabLine.fg, gui = nil }

Error detected while processing /root/.config/nvim/init.lua:
E5113: Error while calling lua chunk: [NULL]

rktjmp commented 2 years ago

I'll be honest, it's been a while since I've worked on the code and don't have the time to check properly right now (half of this post is really notes to future me), but my test:

  describe "#69", ->
    it "errors", ->
      base = parse -> {
        A { fg: "#00FF00", gui: "italic" }
      }
      spec = parse -> {
        A { base.A, gui: nil }
      }

Gives the error:

user bugs #69 errors
./lua/lush/parser.lua:1: {
  code = "circular_self_link",
  msg = "Attempt to link self",
  on = "A"
}

Off the top of my head,

gui = nil is probably ending up as a no-op/getting stripped.
- (perhaps this is an oversight or perhaps the preferred way is actually redefining the rule with all keys, will have to think about that.)
so A { base.A, gui = nil } == A { base.A } which is illegal (circular self link).

So the parser can't rectify the spec and somewhere it's failing to check for errors or perhaps just cant surface the error context properly.

Anyway, if you gui = "NONE", you force the key to be set to a value and the error doesn't happen.

For your user, you might have to wrap the mini-spec in a Colorscheme autocommand (check exact name) so the mini-spec is applied after the normal colorscheme since it's not executed in an obvious order. That's a neat trick I hadn't thought of doing, just passing a small patch of highlights to apply, good use of the internal tool chain!

extends/merge is the prescribed way to do it for bigger changesets but the small patch is a nice way too. Extends/merge sets up a proper parent scope, which is probably why the error doesn't show up in that case, but I would have to look into it.

That should keep you moving, but it is a bug, at least in not showing a useful error if nothing else.

rktjmp commented 2 years ago

Getting my brain back in Lua mode, I am thinking:

key = nil is the same as not having the key in a lua table (IIRC)
so when I request/pairs() the keys given for a highlight group, lua doesn't return gui because it's nil, as good as not being in the table
so the highlight only has a group name and changes from an inherit rule into a link rule.

I bet if you set gui = nil, fg = "#11111" it probably works fine because a key exists and it stays as an inherit rule instead of becoming a link.

Nils are ok to reach the compiler, they get coerced into "NONE"

https://github.com/rktjmp/lush.nvim/blob/63e11d96191b66a5d7c288bad08187aebbfca97b/lua/lush/compiler.lua#L6-L10

Not 100% if I can actually check for this, since checking if a key is nil would probably break the whole link idea cause everything would look like an inherit without checking all the way up chains for differences.

Probably the fix will just be surfacing the error and documenting that key = "NONE" is the correct way to unset a value.

mcchrish commented 2 years ago

Anyway, if you gui = "NONE", you force the key to be set to a value and the error doesn't happen.

This works! I should have thought of this in the first place. Not sure why I went with nil.

I'll probably make this https://github.com/mcchrish/zenbones.nvim/issues/14#issuecomment-935704875 the recommended way for simple overrides. It's much more flexible but still simple to write. I first considered showing the extend/merge way but that seems to large of an apply/compile for one override.

rktjmp / lush.nvim

`lush.parse` error when basing from another specs #69