Comments (3)
Somewhat theme related for highlight groups:
Many upstream Tree Sitter grammars include highlights intended to work directly with nvim (since it is probably the most used editor with tree-sitter support). Being able to keep the code edit captures in sync with nvim values could be helpful for adding languages more easily. They have a document on what they support and how they map it to their internal values:
https://neovim.io/doc/user/treesitter.html#treesitter-highlight-groups
In the The following captures are linked by default to standard group-names:
section.
In Nova, you almost can never use an upstream highlights.scm file because Nova uses different capture names that map directly to Nova theme selectors. You always have to adjust the upstream one. While not the biggest issue, it would be nice to not have to manually adjust every upstream highlight file.
from codeedit.
This is some really good insight @mrsdizzie. These are my current thoughts. It is overly difficult right now to create a theme in most editors today for many developers. What if we make it easier by allowing theme creators to focus on the color palette they want to use and leave how the colors are applied up to language support extensions? Themes could have a set of color slots. Language support extensions could say, color 1 should be applied to variables, color 2 should be applied to keywords, etc. We would of course fallback to something generic. I'd love you hear you're thoughts on this!
from codeedit.
That is an interesting idea, but I'm not sure if people would end up liking that. I think people would want the colors to be consistent across all file types, and wouldn't like it if variables were pink in PHP files and brown in Javascript files because the language authors picked different color1 / color 2.
I do think it is right to focus on color palettes though. I am admittedly unfamiliar with how textmate or vscode structure themes, but my experience is that good color palettes are what people care about. For example, it seems like every editor / terminal / etc... must offer various solarized themes because those are popular and well defined colors that people like and expect to use everywhere.
Looking at examples of these implementations, it seems like most editors make this harder by not making it easy to define a palette and reference it when building the theme. As an example, I like this variant of the "Tomorrow Night" color palette:
some very basic psuedo code for a theme would be:
/* define color palette */
$red: #f2777a;
$orange: #f99157;
$yellow: #ffcc66;
$green: #99cc9b;
$cyan: #66cccc;
$blue: #6699ce;
$aqua: #cc99cc;
$pink: #cc99ce;
$brown: #ed7554;
background = brown;
variable = red;
function = aqua;
string = green;
bool = orange;
So it is easy to find a palette, define my palette in the theme, then use it for theming in a very clear way that is immediately obvious to the reader of the theme file what is happening. So I think some type of theme system that allows for this would be great.
Sublime text has something like this, though the syntax has more advanced options:
https://www.sublimetext.com/docs/color_schemes.html
But it lets you define colors as variables and then reference them later in rules.
from codeedit.
Related Issues (20)
- 🐞 File Navigator sorting for numbered files
- 🐞 Source Control Commit History Data Error
- ✨ Support Bold and Italic Theme Tokens
- 🐞 Reveal in Project Navigator not working
- 🐞 Source editor disappears when deleting all text HOT 8
- ✨ XML Syntax highlighting
- 🐞 Cannot show the contents of text files that are not UTF-8 encoded
- 🐞 CodeFileView Reevaluated Every Keystroke
- 🐞 Status Bar does not update when workspace is first opened
- ✨ Create New Project button HOT 3
- ✨ Settings Developer Menu
- 🐞 Lag when selecting certain settings menus
- 🐞Memory Leaks in SearchKit Result Retrieval
- 🐞 GitLab SelfHosted: Can't add account HOT 1
- 🐞 Ghost entries in the History Inspector view
- 🐞 History Inspector is empty if the git repo doesn't have a remote defined HOT 1
- 🐞 Auto change theme is not working properly HOT 12
- 🐞 Replace deprecated modifier .cornerRadius()
- Ia
- // swift-tools-version:5.4
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from codeedit.