Skip to content

Whole spec inheritance #10

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
3 of 4 tasks
rktjmp opened this issue Feb 18, 2021 · 7 comments
Closed
3 of 4 tasks

Whole spec inheritance #10

rktjmp opened this issue Feb 18, 2021 · 7 comments
Assignees

Comments

@rktjmp
Copy link
Owner

rktjmp commented Feb 18, 2021

#8 #23

  • Tests & Implementation
  • Docs
  • Readme
  • Example?

Elected for no hard example in examples/ but see :h lush-extending-specs and

-- undo_tree.lua
local base = require 'lush_theme.gruv_base' 

return lush(function()
  return {
   UndoTreeHeading { fg = base.Normal.fg, bg = base.Normal.bg },
   -- note: it *should* be ok to write links here, but whether they work is 
   --       dependent on you actually including the base group in the
   --       final spec, else it ends up linking to nothing.
   UndoTreeTime { base.Comment }
  }
end)
-- gruvbox.lua
local base = require 'lush_theme.gruv_base'

specs = {base}
for _, plugin in ipairs(config.plugins) do
  -- where plugins is something like {"undo_tree", "elixir", "fzf"}
  table.insert(specs, require('lush_theme.plugins.'..plugin))
end

return lush.extends(specs).with((function() return {} end)
-- or return lush.merge(specs)
@rktjmp
Copy link
Owner Author

rktjmp commented Mar 7, 2021

Pretty major bug where

base = parse -> {
  A { bg: "a_bg" , fg: "a_fg" },
  Z { bg: "z_bg", fg: "z_fg" }
}

base_2 = parse((-> {
  A { fg: A.bg },
  B { bg: "arst", fg: "rsast" }
  X { Z, fg: "x_z_fg" }
}), {extends: {base}})

will collapse because we try to define an existing group. I think this use case is actually pretty natural to fall into.

Can get around with some code changes and

base = parse -> {
  A { bg: "a_bg" , fg: "a_fg" },
  Z { bg: "z_bg", fg: "z_fg" }
}

base_2 = parse((-> {
  A { fg: base.A.bg },
  B { bg: "arst", fg: "rsast" }
  X { Z, fg: "x_z_fg" }
}), {extends: {base}})

but it makes the API inconsistent. May disable automatic lookup in favour of always using base.Group which is less magical, for better or worse.

@rktjmp
Copy link
Owner Author

rktjmp commented Mar 7, 2021

Prefer base.Group syntax in 39ef2bf

@rktjmp
Copy link
Owner Author

rktjmp commented Mar 7, 2021

@rktjmp
Copy link
Owner Author

rktjmp commented Mar 7, 2021

Example for docs

nord = require('lush_theme.nord)

lush.extend(nord).with(function()
  return {
    -- i like nord but need brighter normal text
    Normal { fg = nord.Normal.fg.li(30) },
    Comment { fg = colorblind_safe_green } -- also I cant see normal color
    MyPlug { ... } -- and I want my custom local plugin to mirror some nord settings. 
  }
end)

@rktjmp
Copy link
Owner Author

rktjmp commented Mar 8, 2021

Generally needs a "bang" fn at the end to roll up all the specs.

extends(specs).with(spec), most semantic in my mind (but i wrote it so that seems obvious).

chain(specs).combine(spec), suggestion but I am not sold on it.

merge(specs).into(spec), relationship is a bit inverse "into"

lush(spec).merge_with/onto(specs) puts parents at the end which may be many loc down.

Possibly have two styles

extends(specs).with(spec) for alteration, merge(specs) auto bangs, merge to me reads as an verb not an... adverb?

Could also just allow extends(specs).with(nil) but I would almost expect that to return nothing.

@rktjmp
Copy link
Owner Author

rktjmp commented Mar 17, 2021

:shipit:

@rktjmp rktjmp closed this as completed Mar 17, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant