Replies: 9 comments 18 replies
-
|
Another tidbit of information: The Nightfox colorscheme has a compiler feature. If this could lay to rest any need for tradeoffs between an easy to maintain (modular) design and colorscheme performance, it might be worth looking into. Maybe nvim 0.9 will already do other caching optimizations in this regard, I don't know. |
Beta Was this translation helpful? Give feedback.
-
|
This is exactly what I was hoping for. I have been pondering on the startup time of the colorscheme and the possibility of toggling highlighting for individual plugins that aren't installed on the system. I believe compiling the colorscheme would be a suitable solution. I would like to incorporate this feature into a refactor. Thank you for the suggestion. |
Beta Was this translation helpful? Give feedback.
-
Beta Was this translation helpful? Give feedback.
-
|
Update 1 I apologize for the delay in starting the refactoring project as I have been preoccupied with other tasks. However, I plan to begin the project soon and will be streaming the process on twitch.tv/ful1e5. Additionally, I would like to mention that neovim has recently introduced a breaking change with semantic highlight groups. As a result, I will be incorporating this into the project's restoration. The new highlight group names will be under |
Beta Was this translation helpful? Give feedback.
-
|
Parens and square brackets are still the wrong color. They should be the default foreground color.
I'm using github dark dimmed and am on the latest commit as of this post. Also, I believe table properties are supposed to be fg color too (e.g. Here is how it is supposed to look:
And I could be wrong, but I think diffAdded and diffRemoved etc. should have the default foreground color as their foreground setting as well. This is what gitsigns uses by default to hl line numbers and the numbers are ending up green (their foreground setting should be the same color as the default/global foreground color)...but their bg setting seems to be correct at least (i.e. green and red respectively). |
Beta Was this translation helpful? Give feedback.
-
How it is supposed to beIn some langs (like js) method and regular fn calls are indeed pink (relative to the GitHub dark dimmed theme), in lua they are blue as shown in the screenshot. For Lua, function names in function definitions/declarations are pink. Regardless of lang, parens and braces should always be the default fg color (or simply unhighlighted) from what I've seen. The only exception to this in Lua are the square brackets used to delimit multiline comments (in which case they should be highlighted the same as comment text), or those used to delimit strings (in which case they should be light blue like the string content). --[[
lua
--]]
-- builtin fn
print()
table.insert()
builtin = table.insert
concat = "" .. "" .. ""
local CAPITALIZED = 2 + 2 / 2 and true
-- ... is default fg color here and so are ( and ) and params
function pink(a, b, ...)
end
local function pink()
end
-- . is pink here
function pink.pink()
end
function a.b.c()
end
-- : is pink here
function pink:pink()
self:blue() -- self is blue too
self.blue()
self.x = y
y = self.x
y = self
self.x = debug
self.x = debug.debug
self.x = table
end
function a.b:c()
end
local default_fg = 9999.99
local d, d2 = debug, debug.setmetatable
-- All string delimiters including their content are light blue
local default_fg = [[light blue]], 'light blue', "light blue"
Blue { default_fg = nil }
Blue()
default_fg.AlsoBlue {}
default_fg:AlsoBlue {}
default_fg.AlsoBlue()
default_fg:AlsoBlue()
local default_fg
default_fg
default_fg = default_fg.default_fg
local default_fg = { default_fg = true }
-- etc.
-- unless otherwise noted , and . and : and [ and ] etc. are default fg color...basically all punct chars it seemsJSON{ "key": "val\nue", "arr": [1, 2, 3, true, null] }JSclass MyType {
constructor(param) {
super()
this.abc = this
super.method(undefined, null)
}
method(param, ...k) {}
}
// builtin
setTimeout(() => {})
console.log()
const b = MyType();
const b = new MyType();
let regex = /^123([abc])+\1\2(?:jddu)$/g;
var str = `${exp + 2}`
const x = y ? true : false;
function func(a, b, ...c) {
}
func(1, a, { x: y }, 2 + 2)
const obj = { method(a, b, ...c) {}, prop: true }
const x = obj.prop.prop
const x = obj.prop.prop()
const x = obj.prop()
debuggerTStype SomeType = "" | number
class MyType {
constructor(param: string) {
super()
this.abc = this
super.method(undefined, null)
}
method(p: MyType) {}
}
// builtin
setTimeout(() => {})
console.log()
const b = MyType();
const b = new MyType();
let regex = /^123([abc])+\1\2(?:jddu)$/g;
var str = `${exp + 2}`
const x = y ? true : false;
function func(a, b, ...c) {
}
func(1, a, { x: y }, 2 + 2)
const obj = { method(a, b, ...c) {}, prop: true }
const x = obj.prop.prop
const x = obj.prop.prop()
const x = obj.prop()
debuggerRubyhash = { "Jane Doe" => 10, "Jim Doe" => 6 }
hash = { aa: 10, bb: 6 }
class Cls < Sub
attr_accessor :abc
@one = "abc"
@@two = "def"
end
def some_method(value='default', arr=[])
puts value
puts arr.length
end
results = method_name parameter1, parameter2
results = method_name(parameter1, parameter2).reverseMakeSHELL = bash
.PHONY: target target2
v = $(call myfn,arg)
override somevar = hello
xxx := hello
yyy ::= hello
override define multi
@goodbye $$world "$$(echo world)"
endef
target2: ;
target: preq
Rust#![crate_type = "lib"]
use allmine::stillmine::Func;
use std::Vec;
pub MyStruct {
pub id: Option<usize>,
hello: MyStruct,
}
// This is a simple macro named `say_hello`.
macro_rules! say_hello {
// `()` indicates that the macro takes no argument.
() => {
// The macro will expand into the contents of this block.
println!("Hello!");
};
}
#[allow(non_camel_case_types)]
#[test]
#[derive(Clone, Debug)]
fn somefunc<'a>(param: Option<bool>, p2: SomeType<'a>, p3: Self, p4: Self::SomeType) -> int32 {
let user1 = User {
hello: mod::ns::ok,
active: true,
username: String::from("someusername123"),
email: String::from("someone@example.com"),
sign_in_count: 1,
};
println!("Hello!");
let abc = 100 + 100u8;
let abc = user1.active;
let xyz = Some(User2 { active: [ 1, 2, 3 ] });
let f = NotSome(None);
Abc::new();
self.meth()
}HTML<html>
<div class="someclass">
Hello World!
</div>
<html>CSSdiv.div#foo {
color: rgba(100, 200, 0, 0.5) !important;
}C#include <stdio.h>
#include <string.h>
struct Books {
char title[50];
char author[50];
char subject[100];
int book_id;
};
main() {
unsigned int myint = 42;
struct Books Book1;
struct Books Book2;
strcpy( Book1.title, "C Programming");
somefunc();
Book1.book_id = &book;
Book1.book_id = *book;
Book1->book_id = 'c';
return 0;
}command mycmd ${var} ${#var} "$var" "${var}" | cat
true || false
somecmd ${var} ${#var} "$var" "${var}" $var
IFS=$IFS
ifs=$ifs
var=$(command somecmd "$(echo hello)" $(mycmd "hello" hello) "$(mycmd "hello" hello)")
func() {
:
return 0
}
func 11 ${arr[@]} ${arr[*]} "${arr[@]}" "${arr[*]}" $IFS $var $(<file.lua) < somefile.lua
cmd \
-p1 \
--p2 \
p3
cmd1 p1; cmd2;
exit |
Beta Was this translation helpful? Give feedback.
-
|
Can we change this? |
Beta Was this translation helpful? Give feedback.
-
|
@tmillr You can override local colo = 'github_dark'
local spec = require('github-theme.spec').load(colo)
local palette = spec.palette -- To access palette values
require('github-theme').setup({
specs = {
all = {
syntax = {
bracket = spec.fg1,
},
},
},
})
vim.cmd.colorscheme(colo) |
Beta Was this translation helpful? Give feedback.
-
|
@ful1e5 Alright I'll check that out. Thank you |
Beta Was this translation helpful? Give feedback.
-
|
@tmillr If you are trying to solve the issue of highlight mismatch and would like me to review your pull request based on the description above, I would be happy to do so. In the meantime, I will be working on other features. |
Beta Was this translation helpful? Give feedback.
-
|
there are 2 |
Beta Was this translation helpful? Give feedback.
-
Beta Was this translation helpful? Give feedback.
-
|
Fixed in 9ddfac1 |
Beta Was this translation helpful? Give feedback.
-
|
Also, this isn't working for me. Am I doing something wrong? groups = {
all = {
-- this will remove the highlight groups
["@punctuation.bracket"] = {},
}, |
Beta Was this translation helpful? Give feedback.
-
|
Fixed in 861245e |
Beta Was this translation helpful? Give feedback.
-
|
White theme (GitHub_light) colours seem really different from the actual GitHub theme (on the right). Contrast, highlight groups, and colour assignments are way better on GitHub currently. |
Beta Was this translation helpful? Give feedback.
-
I think it's ruby. |
Beta Was this translation helpful? Give feedback.
-
|
yep it’s ruby |
Beta Was this translation helpful? Give feedback.
-
|
The colors are wrong, but the washed-out appearance could just be your font settings (or the way your terminal is rendering text). What terminal or gui are you using? Maybe try messing with anti-aliasing settings or increasing the font weight of your regular/default font within the settings of the terminal you're using. |
Beta Was this translation helpful? Give feedback.
-
|
I’m using Iterm (though the iterm colour scheme is broken and cannot be imported so im using a default light theme) with Fira code nerd font. I just saw there was a retina weight and that does improve the washed out effect (thanks for the tip). About the colours, is this something on your list already? |
Beta Was this translation helpful? Give feedback.
-
Yeah. I have some ideas and changes that I'd like to contribute and run past the owner/maintainer concerning the incorrect highlights, and It sounds like this will become a priority soon. I believe that it all starts with #253. You can also check out #252 and #237. |
Beta Was this translation helpful? Give feedback.
-
|
Just a suggestion, but it might be a good idea to note in the documentation and/or README (if not done already) that this plugin breaks the links from Edit: some of the links back to vim's standard/default hl groups are broken too, for example the link from Just my 2 cents |
Beta Was this translation helpful? Give feedback.
-
|
I submitted a pr #250 to fix lua function declarations (the highlighting of the function's/method's name). |
Beta Was this translation helpful? Give feedback.
-
|
A major version, v1.0.0, has been released. I would like to express my gratitude to everyone who contributed to and sponsored this project. A special thank you goes to @tmillr for enhancing the highlights and providing additional support for missing Treesitter's highlights. I'm concluding the discussion now. If anyone needs assistance, please start a new conversation. If you encounter any issues, feel free to create an issue. Finally, I kindly request you to consider sponsoring my work to support its continuous development. Your sponsorship would be greatly appreciated. |
Beta Was this translation helpful? Give feedback.
-
Beta Was this translation helpful? Give feedback.
-
Update 1
TLDR; I'm planning to refactor the codebase for compatibility with Neovim 0.9 and is seeking feedback on requested features and improvements.
I have been unable to push new features for the past few months due to bugs and limitations with the codebase for this color scheme. The codebase was heavily inspired by tokyonight.nvim, which was the first color scheme written in pure Lua and had many features for Neovim 0.5, including support for tree-sitter highlights. However, Neovim has exposed more of vim's native commands through
vim.*, which has made many of the utility functions we wrote no longer useful.Additionally, Treesitter recently removed the
TS*highlight group, which we patched in our codebase (PR #222). However, we can do a better job by reducing common highlights according to the new variant of the GitHub color scheme that we plan to implement. That is why I am planning to reorganize the code to use Neovim 0.9's features and native commands in a major refactor.In order to minimize the impact on people's Neovim configurations, I would like to issue a warning before the refactor begins. If any major changes are pushed upstream, I will provide migration documentation for those following the main branch. By starting this discussion beforehand and sharing the changes and problems I have identified, we can address the most requested features, make the code extensible for future requests, and determine the best way to make these improvements.
By making these changes, we can not only make it easier for new people to join this community and contribute to the project, but we can also enable others to use this color scheme as a template for creating their own. By sharing the changes and problems I have found in detail, we can discuss them and determine the best way to make these improvements.
Addressing Key Limitations
Here are the improvements we are making to this colorscheme:
Restructuring Modules
The current structure of the project's modules presents challenges that can make it difficult for new contributors to understand and contribute to the project, as well as for existing contributors to read and refactor the tightly-coupled functions and modules.
One significant issue is the use of inconsistent naming conventions and arbitrary divisions of functions, which can make it difficult to understand the project's structure. Another problem is the lack of clear comments or documentation, which could greatly assist someone in working on the project.
These issues were exacerbated when additional modules were added to support native autocmd and support for old vim syntaxes, as well as lua type support and new feature configuration options. Given these challenges, it would be beneficial to reorganize and clarify the project's structure.
The current module structure is as follows:
I am describing the structure because it was requested in #193, and I believe it may be helpful for people to have a better understanding of the changes being made.
As we continue to work on optimizing the project, it is important to me that we maintain the current features provided by the colorscheme. To ensure a smooth refactoring process, I am proposing the use of built-in commands and the revision of certain functions. If you have any thoughts on the project's overall structure, I would be grateful for your input.
For ideas on function naming and module organization, I want to refer to the ellisonleao/gruvbox.nvim colorscheme. If you are a plugin or colorscheme author, please feel free to share your ideas on structure as well.
In terms of specific areas of focus, I plan to reorganize the
util.luamodule into a utility module. For thetheme.luamodule, I am considering grouping plugin highlights in the form of a Lua table, although I am not yet certain what direction to take with this module. Finally, I also plan to perform a refactor on theconfig.luamodule to make it more adaptable to future feature implementations, which we can discuss further below. Suggestions for renaming these module names to improve project readability are also welcome.Ensuring Future Proof Configuration
We have been gradually adding new configurations to our project. Currently, when a new feature or option is introduced, we add it to the Lua config table and name it appropriately. However, I think it would be more effective to have a more organized and consistent config structure. By using Lua tables to group and understand the configurations, we can make the configuration easier to understand and navigate without needing to refer to documentation.
I would like to create an extendable config module that will make it easier to add new features in the future. To do this, I plan to carefully review the config structures of other colorschemes and group similar configs together in Lua tables. I am also planning to provide clear typing and detailed documentation for each option. One project that I find particularly interesting in this regard is navarasu/onedark.nvim. I welcome any suggestions or ideas you may have on this topic.
Adhering to primer for Color Guide
I am also considering renaming the colorscheme variant to align with the guidelines provided by primer.style and the colorblind variant must be renamed because it was removed from the beta version on primer website. It is uncertain if the variant of the VSCode theme is currently following these guidelines, but I believe it is being developed in accordance with them. To ensure consistency with other GitHub products and prevent potential issues, it is important to follow the guidelines provided by primer.
The current color palette used in this colorscheme was selected manually using a color picker, which may cause some differences in value of the colors compared to the palette used by VSCode themes and primer.
I also found that VSCode themes do not use a universal highlighter for code highlighting, but rather rely on community-created plugins using their preferred highlighter, which may involve some stupid regex stuff. This can cause certain types of code to be unparsed and result as default foreground color. This issue was not previously recognized when defining highlights in the colorscheme. Therefore, it is being considered to fix this issue in this refactor without significantly changing the VSCode and Neovim themes.
In the event that VSCode implements treesitter as a highlighter in the future, the highlights will be revisited and potentially modified through discussion.
Removing Aesthetic Elements Inspired by VSCode Themes
It is not necessary to completely remove highlights inspired by VSCode themes, but if a particular highlight (such as
@string.special) is connected to a core highlight and is part of a chain (for example,Special->@string.special->@lua.string.special), replacing it will cause all child highlights to become disconnected, and you will have to manually define all highlights linked to it (such as@string.special). This can be inconvenient and time-consuming.Additionally, highlights for Treesitter and Treesitter-based plugins often change, so you may need to constantly update these highlights as well. However, we can potentially save time by only overriding core Treesitter highlights and highlights related to supported programming languages.
Implementing Requested Features
I would like to implement feature request #176 as part of this refactor. Additionally, I would like to add documentation about the ability to override highlighting for specific file types, as discussed in #213. While requests for plugin support will not be addressed during the refactor, we should plan to address them after the refactor is complete.
I am grateful for everyone's efforts in reading my lengthy list of refactor suggestions and participating in the discussion. Your support and sponsorship have not gone unnoticed and I would like to especially thank @github for being my first one-time sponsor. Thank you all for your invaluable contributions and support.
Beta Was this translation helpful? Give feedback.
All reactions