-
Notifications
You must be signed in to change notification settings - Fork 47
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
[feature] Add language specific definitions extensibility example #13
Comments
Also it would make additional configuration easier. For example see gruvbox. If it were possible to have a separate lush function for a configurable feature and join them in the end, the definitions in the beginning would not be necessary. |
How do you imagine using those files you linked? To be explicit in discussion, as they are, they define no rules for the groups, so inheriting from them would not be useful, beyond automatically clearing any hl-linking that their associated plugin does. As I understand it, they exist as "language templates", where if you want to style haskell, you have the option of copying the haskell file to So your main spec might be
You would likely have to have a
Right now, you can already to something like this, which is probably close to what you want:
(#9) The sticky part is bringing it all into an actual usable theme, since you have to redefine all the groups:
But at this point, I think you are talking about spec inheritance #10.
Sorry this comments all over the place, it's sort of a dense topic. Do you think the first part, requiring base and setting groups off it, covers what you are talking about or not? |
The first listing is most similar to the idea I had in mind. The main spec file, would include some conditions for the definition of these modules. Something like this: local config = { -- user-defined in the `vimrc`
rust = vim.g.amazing_theme_load_rust or 0,
...
}
local modules = {}
-- for all the plugins and languages specified in the `vimrc`
if config.rust == 1 then
local rust = require "lush-theme.languages.rust"
vim.tbl_extend(modules, rust)
end
-- then the modules would be loaded in the main spec
local theme = lush(function()
base = {
...
}
vim.g.tbl_extend(base,modules)
return base
end)
return theme This would allow to make some interesting things possible... For example, when I only use plugins vim.g.amazing_theme_plugins = {
vim_startify = true,
undotree = true
} And the advantage is, that I do not pay any loading time for plugins I do not use at all. This could extend to languages and conditionally loading languages, only if they are being used... As for the Another advantage of this would be, that you could have something like this in a module ( vim.g.plugin_color_variable = tostring(hsl(90,30,50))
...
local theme = lush(function()
...
end)
return theme This would enable having settings for plugins that are made by variables to be in the same file and only defined after loading. Thank you very much for your reply and this project. It has an amazing potential. (should I comment the groups in the templates?) |
Yes, this could also be used for better modulation of the scheme. Now, colour schemes, that have many definitions of groups take very long to load, therefore increasing the startuptime. Would it be possible to make syntax to provide conditions similarly to something like the packer.nvim definition of packages? This could maybe compile into augroup rust
autocmd FileType rust hi RustComment gui=italic, guibg=red ...
...
augroup END This could make the colourscheme much smaller and faster to load with the same amount of definitions... right? |
Sorry for being a little bit spamy, but I thought of a better way... |
See post on #8, I think the extends system will do most of what you want right? Though this issue feels like it's maybe being pulled in a few directions (conditional extends, syntax template files and performance of large themes). |
Yeah. I think that it helps a lot! Maybe we could split this into different issues?
The last two would help with the performance IMO. Also we might have an issue about the templates (language and plugin)... I have some kind of templates as I shared through the gist for languages and have some for plugins locally. We only need to agree on the implementation. |
Problem
Every example uses eventually uses only one lush function to define the colours.
Proposition
I think that it would be more powerful to define specific features in multiple files and require them only if necessary.
Possible solution
If I understand it correctly, what is being defined by the
lush
function is a table. Therefore a way to get about it would be to usevim.tbl_extend
or something similar to define the colours in mutliplelush
functions. If there is no reason not to do it this way, than there should be an example for this functionality, because it is very powerful and could be extensively used for more modularity and code clarity.Example of use
I created these files for language colour definitions and would like to store them in these separate files and add them to a global colour table definition. Also the files should be added to the template folder I think for better incentive for colourscheme creation to have a greater coverage. (I have something similar for plugins...)
The text was updated successfully, but these errors were encountered: