`lush.parse` error when basing from another specs

[Michael Chris Lopez]

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 }

Related: zenbones-theme/zenbones.nvim#14

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

[Oliver Marriott]

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.

[Oliver Marriott]

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"

lush.nvim/lua/lush/compiler.lua

Lines 6 to 10 in 63e11d9

 -- sanitise value if empty or blank 
 local function value_or_NONE(value) 
   if value == nil or value == '' then 
     return 'NONE' 
   end 

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.

[Michael Chris Lopez]

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 zenbones-theme/zenbones.nvim#14 (comment) 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.