This removes around 900 unnecessary clones, ranging from cloning a few
ints all the way to large data structures and images.
A lot of these were fixed using `cargo clippy --fix --workspace
--all-targets`, however it often breaks other lints and needs to be run
again. This was then followed up with some manual fixing.
I understand this is a large diff, but all the changes are pretty
trivial. Rust is doing some heavy lifting here for us. Once I get it up
to speed with main, I'd appreciate this getting merged rather sooner
than later.
Release Notes:
- N/A
Ensures issues like #36242 and #36295 do not arise where users are
confused that the agent panel does not follow the default UI font size
whilst also keeping the possibility of customization. The agent font
size was matching the UI font size previously alredy, which makes it
easier to change it for most scenarios.
Also cleans up some related logic around modifying the font sizes.
Release Notes:
- The agent panel font size will now inherit the UI font size by default
if not set in your settings.
Closes#18565
I could use some advice on the color palette / theming. A couple
options:
1. The `drop_target_background` color could be used for the border if we
didn't use it for the background of the tab. In VSCode, the background
color of tabs doesn't change as you're dragging, there's just a border
between tabs. My only concern with this option is that the current
`drop_target_background` color is a bit subtle when used for a small
area like a border.
2. Another option could be to add a `drop_target_border` theme color,
but I don't know how much complexity this adds to implementation
(presumably all existing themes would need to be updated?).
Demo:
https://github.com/user-attachments/assets/0b7c04ea-5ec5-4b45-adad-156dfbf552db
Release Notes:
- Highlight where a dragged tab will be dropped between two other tabs
---------
Co-authored-by: Smit Barmase <heysmitbarmase@gmail.com>
Closes#14050
Release Notes:
- Added the ability to set theme-specific overrides via the
`theme_overrides` setting.
---------
Co-authored-by: Peter Tripp <peter@zed.dev>
Co-authored-by: Marshall Bowers <git@maxdeviant.com>
Release Notes:
- Settings can now be configured per operating system with the new
top-level fields: `"macos"`/`"windows"`/`"linux"`. These will override
user level settings, but are lower precedence than _release channel_
settings.
Closes #ISSUE
The behavior of the theme selector is documented above the function,
copied here for reference:
```rust
/// separates theme "mode" ("dark" | "light" | "system") into two separate states
/// - appearance = "dark" | "light"
/// - "system" true/false
/// when system selected:
/// - toggling between light and dark does not change theme.mode, just which variant will be changed
/// when system not selected:
/// - toggling between light and dark does change theme.mode
/// selecting a theme preview will always change theme.["light" | "dark"] to the selected theme,
///
/// this allows for selecting a dark and light theme option regardless of whether the mode is set to system or not
/// it does not support setting theme to a static value
```
Release Notes:
- N/A *or* Added/Fixed/Improved ...
Settings Profiles
- [X] Allow profiles to be defined, where each profile can be any of
Zed's settings
- [X] Autocompletion of all settings
- [X] Errors on invalid keys
- [X] Action brings up modal that shows user-defined profiles
- [X] Alphabetize profiles
- [X] Ability to filter down via keyboard, and navigate via arrow up and
down
- [X] Auto select Disabled option by default (first in list, after
alphabetizing user-defined profiles)
- [X] Automatically select active profile on next picker summoning
- [X] Persist settings until toggled off
- [X] Show live preview as you select from the profile picker
- [X] Tweaking a setting, while in a profile, updates the profile live
- [X] Make sure actions that live update Zed, such as `cmd-0`, `cmd-+`,
and `cmd--`, work while in a profile
- [X] Add a test to track state
Release Notes:
- Added the ability to configure settings profiles, via the "profiles"
key. Example:
```json
{
"profiles": {
"Streaming": {
"agent_font_size": 20,
"buffer_font_size": 20,
"theme": "One Light",
"ui_font_size": 20
}
}
}
```
To set a profile, use `settings profile selector: toggle`
Followup to #33678, doing the same thing for all JSON Schema files
provided to json-language-server
Release Notes:
* Added warnings for unknown fields when editing `tasks.json` /
`snippets.json`.
This PR revives zed-industries/zed#27818 and aims to complete the
partially implemented overloaded signature help feature.
The first commit is a rebase of zed-industries/zed#27818, and the
subsequent commit addresses all review feedback from the original PR.
Now the overloaded signature help works like
https://github.com/user-attachments/assets/e253c9a0-e3a5-4bfe-8003-eb75de41f672Closes#21493
Release Notes:
- Implemented signature help for overloaded items. Additionally, added a
support for rendering signature help documentation.
---------
Co-authored-by: Fernando Tagawa <tagawafernando@gmail.com>
Co-authored-by: Claude <noreply@anthropic.com>
Co-authored-by: Kirill Bulatov <mail4score@gmail.com>
Co-authored-by: Kirill Bulatov <kirill@zed.dev>
The major change in schemars 1.0 is that now schemas are represented as
plain json values instead of specialized datatypes. This allows for more
concise construction and manipulation.
This change also improves how settings schemas are generated. Each top
level settings type was being generated as a full root schema including
the definitions it references, and then these were merged. This meant
generating all shared definitions multiple times, and might have bugs in
cases where there are two types with the same names.
Now instead the schemar generator's `definitions` are built up as they
normally are and the `Settings` trait no longer has a special
`json_schema` method. To handle types that have schema that vary at
runtime (`FontFamilyName`, `ThemeName`, etc), values of
`ParameterizedJsonSchema` are collected by `inventory`, and the schema
definitions for these types are replaced.
To help check that this doesn't break anything, I tried to minimize the
overall [schema
diff](https://gist.github.com/mgsloan/1de549def20399d6f37943a3c1583ee7)
with some patches to make the order more consistent + schemas also
sorted with `jq -S .`. A skim of the diff shows that the diffs come
from:
* `enum: ["value"]` turning into `const: "value"`
* Differences in handling of newlines for "description"
* Schemas for generic types no longer including the parameter name, now
all disambiguation is with numeric suffixes
* Enums now using `oneOf` instead of `anyOf`.
Release Notes:
- N/A
Closes#32354
The issue is that we render selections over the text in the agent panel,
but under the text in editor, so themes that have no alpha for the
selection background color (defaults to 0xff) will just occlude the
selected region. Making the selection render under the text in markdown
would be a significant (and complicated) refactor, as selections can
cross element boundaries (i.e. spanning code block and a header after
the code block).
The solution is to add a new highlight to themes
`element_selection_background` that defaults to the local players
selection background with an alpha of 0.25 (roughly equal to 0x3D which
is the alpha we use for selection backgrounds in default themes) if the
alpha of the local players selection is 1.0. The idea here is to give
theme authors more control over how the selections look outside of
editor, as in the agent panel specifically, the background color is
different, so while an alpha of 0.25 looks acceptable, a different color
would likely be better.
CC: @iamnbutler. Would appreciate your thoughts on this.
> Note: Before and after using Everforest theme
| Before | After |
|-------| -----|
| <img width="618" alt="Screenshot 2025-06-09 at 5 23 10 PM"
src="https://github.com/user-attachments/assets/41c7aa02-5b3f-45c6-981c-646ab9e2a1f3"
/> | <img width="618" alt="Screenshot 2025-06-09 at 5 25 03 PM"
src="https://github.com/user-attachments/assets/dfb13ffc-1559-4f01-98f1-a7aea68079b7"
/> |
Clearly, the selection in the after doesn't look _that_ great, but it is
better than the before, and this PR makes the color of the selection
configurable by the theme so that this theme author could make it a
lighter color for better contrast.
Release Notes:
- agent panel: Fixed an issue with some themes where selections inside
the agent panel would occlude the selected text completely
Co-authored-by: Antonio <me@as-cii.com>
- Improved colors
- Blank out diff hunk gutter highlights in conflict regions
- Paint conflict marker highlights all the way to the gutter
Release Notes:
- Improved the highlighting of merge conflict markers in editors.
---------
Co-authored-by: Marshall Bowers <git@maxdeviant.com>
Co-authored-by: Cole Miller <cole@zed.dev>
A user on Discord reported an issue where the minimap thumb was fully
opaque:
<img
src="https://github.com/user-attachments/assets/5049c6a3-f89a-4ceb-9d1b-ec06e7fe9151"
height="300">
This can happen because the scrollbar and its thumb might not
neccessarily be transparent at all.
Thus, this PR adds the`minimap.thumb.background` and
`minimap.thumb.border` colors to themes so theme authors can specify
custom colors for both here.
Furthermore, I ensured that the minimap thumb background fallback value
can never be entirely opaque. The values were arbitrarily chosen to
avoid the issue from occuring whilst keeping currently working setups
working. With the new properties added, authors (and users) should be
able to avoid running into this issue altogether so I would argue for
this special casing to be fine. However, open to change it should a
different approach be preferrred.
Release Notes:
- Added `minimap.thumb.background` and `minimap.thumb.border` to themes
to customize the thumb color and background of the minimap.
- Fixed an issue where the minimap thumb could be opaque if the theme
did not specify a color for the thumb.
This PR updates terminal file icon associations in icon_theme.rs
I've added a `bash_login` file as mentioned in the gnu docs for bash
startup files. For zsh I updated the startup files to more accurately
reflect the zsh startup file documentation such as adding `zlogin` and
removing `zsh_profile` in favor of `zprofile`. I also added the default
`zsh_history` file that is set on MacOS.
Sources:
- [bash docs - Bash Startup
Files](https://www.gnu.org/software/bash/manual/html_node/Bash-Startup-Files.html)
- [zsh docs - Startup
Files](https://zsh.sourceforge.io/Intro/intro_3.html)
Release Notes:
- Improved file icon associations in icon_theme.rs to support more shell
configuration files
https://github.com/zed-industries/zed/issues/30972 brought up another
case where our context is not enough to track the actual source of the
issue: we get a general top-level error without inner error.
The reason for this was `.ok_or_else(|| anyhow!("failed to read HEAD
SHA"))?; ` on the top level.
The PR finally reworks the way we use anyhow to reduce such issues (or
at least make it simpler to bubble them up later in a fix).
On top of that, uses a few more anyhow methods for better readability.
* `.ok_or_else(|| anyhow!("..."))`, `map_err` and other similar error
conversion/option reporting cases are replaced with `context` and
`with_context` calls
* in addition to that, various `anyhow!("failed to do ...")` are
stripped with `.context("Doing ...")` messages instead to remove the
parasitic `failed to` text
* `anyhow::ensure!` is used instead of `if ... { return Err(...); }`
calls
* `anyhow::bail!` is used instead of `return Err(anyhow!(...));`
Release Notes:
- N/A
Closes#30802
Release Notes:
- Fixed issue where setting `buffer_line_height.custom` to 0 would cause
text to disappear
---------
Co-authored-by: Michael Sloan <michael@zed.dev>
Follow-up to #28064
This PR adds the `scrollbar_thumb_active_background` to themes and uses
it for the editor scrollbars to color these whilst they are being
dragged. This way, we provide the best customizabiliy for the scrollbars
and enable theme authors to add good contrasts between all the three
states `ScrollbarThumbState::Idle`, `ScrollbarThumbState::Hovered` and
ScrollbarThumbState::Dragging`.
It also adds this to the VsCode theme importer so any future imported
themes will have this set as well.
Whenever the property is not set, I decided it is best to fall back to
the normal `thumb_background` for the time being, as this way the
distinction and contrast between hovered and active state is better than
having the same color for hovering and dragging the scrollbar.
Example with active color set via `experimental.theme_overrides` in the
settings:
https://github.com/user-attachments/assets/9934e75b-6e0a-4a41-90ba-bfffb89865e7
Release Notes:
- Added the `scrollbar.thumb.active_background` color to themes. Theme
authors can use this property in combination with
`scrollbar.thumb.hover_background` to customize the color of the editor
scrollbar thumbs while these are hovered or being dragged.
You can set `agent_font_size` as a top-level settings key. You can also
use `zed::IncreaseBufferFontSize` and `zed::DecreaseBufferFontSize` and
`zed::ResetBufferFontSize` the agent panel is focused via the standard
bindings to adjust the agent font size. In the future, it might make
sense to rename these actions to be more general since "buffer" is now a
bit of a misnomer. 🍐'd with @mikayla-maki
Release Notes:
- N/A
---------
Co-authored-by: Mikayla Maki <mikayla.c.maki@gmail.com>
Nathan here: I also tacked on a bunch of UI refinement.
Release Notes:
- Introduced the ability to follow the agent around as it reads and
edits files.
---------
Co-authored-by: Nathan Sobo <nathan@zed.dev>
Co-authored-by: Max Brunsfeld <maxbrunsfeld@gmail.com>
Things this doesn't currently handle:
- [x] ~testing~
- ~we really need an snapshot test that takes a vscode settings file
with all options that we support, and verifies the zed settings file you
get from importing it, both from an empty starting file or one with lots
of conflicts. that way we can open said vscode settings file in vscode
to ensure that those options all still exist in the future.~
- Discussed this, we don't think this will meaningfully protect us from
future failures, and we will just do this as a manual validation step
before merging this PR. Any imports that have meaningfully complex
translation steps should still be tested.
- [x] confirmation (right now it just clobbers your settings file
silently)
- it'd be really cool if we could show a diff multibuffer of your
current settings with the result of the vscode import and let you pick
"hunks" to keep, but that's probably too much effort for this feature,
especially given that we expect most of the people using it to have an
empty/barebones zed config when they run the import.
- [x] ~UI in the "welcome" page~
- we're planning on redoing our welcome/walkthrough experience anyways,
but in the meantime it'd be nice to conditionally show a button there if
we see a user level vscode config
- we'll add it to the UI when we land the new walkthrough experience,
for now it'll be accessible through the action
- [ ] project-specific settings
- handling translation of `.vscode/settings.json` or `.code-workspace`
settings to `.zed/settings.json` will come in a future PR, along with UI
to prompt the user for those actions when opening a project with local
vscode settings for the first time
- [ ] extension settings
- we probably want to do a best-effort pass of popular extensions like
vim and git lens
- it's also possible to look for installed/enabled extensions with `code
--list-extensions`, but we'd have to maintain some sort of mapping of
those to our settings and/or extensions
- [ ] LSP settings
- these are tricky without access to the json schemas for various
language server extensions. we could probably manage to do translations
for a couple popular languages and avoid solving it in the general case.
- [ ] platform specific settings (`[macos].blah`)
- this is blocked on #16392 which I'm hoping to address soon
- [ ] language specific settings (`[rust].foo`)
- totally doable, just haven't gotten to it yet
~We may want to put this behind some kind of flag and/or not land it
until some of the above issues are addressed, given that we expect
people to only run this importer once there's an incentive to get it
right the first time. Maybe we land it alongside a keymap importer so
you don't have to go through separate imports for those?~
We are gonna land this as-is, all these unchecked items at the bottom
will be addressed in followup PRs, so maybe don't run the importer for
now if you have a large and complex VsCode settings file you'd like to
import.
Release Notes:
- Added a VSCode settings importer, available via a
`zed::ImportVsCodeSettings` action
---------
Co-authored-by: Mikayla Maki <mikayla@zed.dev>
Co-authored-by: Kirill Bulatov <kirill@zed.dev>
Co-authored-by: Mikayla Maki <mikayla.c.maki@gmail.com>
Co-authored-by: Marshall Bowers <git@maxdeviant.com>
TODO:
- [x] Make it work in the project diff:
- [x] Support non-singleton buffers
- [x] Adjust excerpt boundaries to show full conflicts
- [x] Write tests for conflict-related events and state management
- [x] Prevent hunk buttons from appearing inside conflicts
- [x] Make sure it works over SSH, collab
- [x] Allow separate theming of markers
Bonus:
- [ ] Count of conflicts in toolbar
- [ ] Keyboard-driven navigation and resolution
- [ ] ~~Inlay hints to contextualize "ours"/"theirs"~~
Release Notes:
- Implemented initial support for resolving merge conflicts.
---------
Co-authored-by: Max Brunsfeld <maxbrunsfeld@gmail.com>
This adds a "workspace-hack" crate, see
[mozilla's](https://hg.mozilla.org/mozilla-central/file/3a265fdc9f33e5946f0ca0a04af73acd7e6d1a39/build/workspace-hack/Cargo.toml#l7)
for a concise explanation of why this is useful. For us in practice this
means that if I were to run all the tests (`cargo nextest r
--workspace`) and then `cargo r`, all the deps from the previous cargo
command will be reused. Before this PR it would rebuild many deps due to
resolving different sets of features for them. For me this frequently
caused long rebuilds when things "should" already be cached.
To avoid manually maintaining our workspace-hack crate, we will use
[cargo hakari](https://docs.rs/cargo-hakari) to update the build files
when there's a necessary change. I've added a step to CI that checks
whether the workspace-hack crate is up to date, and instructs you to
re-run `script/update-workspace-hack` when it fails.
Finally, to make sure that people can still depend on crates in our
workspace without pulling in all the workspace deps, we use a `[patch]`
section following [hakari's
instructions](https://docs.rs/cargo-hakari/0.9.36/cargo_hakari/patch_directive/index.html)
One possible followup task would be making guppy use our
`rust-toolchain.toml` instead of having to duplicate that list in its
config, I opened an issue for that upstream: guppy-rs/guppy#481.
TODO:
- [x] Fix the extension test failure
- [x] Ensure the dev dependencies aren't being unified by Hakari into
the main dependencies
- [x] Ensure that the remote-server binary continues to not depend on
LibSSL
Release Notes:
- N/A
---------
Co-authored-by: Mikayla <mikayla@zed.dev>
Co-authored-by: Mikayla Maki <mikayla.c.maki@gmail.com>
This PR adds fallback colors for the `version_control.<variant>` theme
properties.
This fixes the colors when themes do not provide the properties.
Related to https://github.com/zed-industries/zed/pull/26951.
Release Notes:
- Added fallback colors for the `version_control.<variant>` theme
properties.
Closes#26847
Release Notes:
- Updated Git panel background to use panel_background instead of
ElevationIndex::Surface.bg(cx) for consistency with other panels.
- Removed redundant GitStatusColors struct from status.rs and refactored
to use existing theme colors.
- Adjusted Color enum mappings in color.rs to reference
version_control_* colors instead of status() for better alignment with
the theme system.
- Cleaned up unused or redundant code.
### DISCLAIMER
> As of 6th March 2025, debugger is still in development. We plan to
merge it behind a staff-only feature flag for staff use only, followed
by non-public release and then finally a public one (akin to how Git
panel release was handled). This is done to ensure the best experience
when it gets released.
### END OF DISCLAIMER
**The current state of the debugger implementation:**
https://github.com/user-attachments/assets/c4deff07-80dd-4dc6-ad2e-0c252a478fe9https://github.com/user-attachments/assets/e1ed2345-b750-4bb6-9c97-50961b76904f
----
All the todo's are in the following channel, so it's easier to work on
this together:
https://zed.dev/channel/zed-debugger-11370
If you are on Linux, you can use the following command to join the
channel:
```cli
zed https://zed.dev/channel/zed-debugger-11370
```
## Current Features
- Collab
- Breakpoints
- Sync when you (re)join a project
- Sync when you add/remove a breakpoint
- Sync active debug line
- Stack frames
- Click on stack frame
- View variables that belong to the stack frame
- Visit the source file
- Restart stack frame (if adapter supports this)
- Variables
- Loaded sources
- Modules
- Controls
- Continue
- Step back
- Stepping granularity (configurable)
- Step into
- Stepping granularity (configurable)
- Step over
- Stepping granularity (configurable)
- Step out
- Stepping granularity (configurable)
- Debug console
- Breakpoints
- Log breakpoints
- line breakpoints
- Persistent between zed sessions (configurable)
- Multi buffer support
- Toggle disable/enable all breakpoints
- Stack frames
- Click on stack frame
- View variables that belong to the stack frame
- Visit the source file
- Show collapsed stack frames
- Restart stack frame (if adapter supports this)
- Loaded sources
- View all used loaded sources if supported by adapter.
- Modules
- View all used modules (if adapter supports this)
- Variables
- Copy value
- Copy name
- Copy memory reference
- Set value (if adapter supports this)
- keyboard navigation
- Debug Console
- See logs
- View output that was sent from debug adapter
- Output grouping
- Evaluate code
- Updates the variable list
- Auto completion
- If not supported by adapter, we will show auto-completion for existing
variables
- Debug Terminal
- Run custom commands and change env values right inside your Zed
terminal
- Attach to process (if adapter supports this)
- Process picker
- Controls
- Continue
- Step back
- Stepping granularity (configurable)
- Step into
- Stepping granularity (configurable)
- Step over
- Stepping granularity (configurable)
- Step out
- Stepping granularity (configurable)
- Disconnect
- Restart
- Stop
- Warning when a debug session exited without hitting any breakpoint
- Debug view to see Adapter/RPC log messages
- Testing
- Fake debug adapter
- Fake requests & events
---
Release Notes:
- N/A
---------
Co-authored-by: Piotr Osiewicz <24362066+osiewicz@users.noreply.github.com>
Co-authored-by: Anthony Eid <hello@anthonyeid.me>
Co-authored-by: Anthony <anthony@zed.dev>
Co-authored-by: Piotr Osiewicz <peterosiewicz@gmail.com>
Co-authored-by: Piotr <piotr@zed.dev>
Polish PR
- [ ] Horizontal scrollbar for git panel
- [ ] Allow shift clicking a checkbox in any section to stage the whole
section
- [ ] Clean up design of no changes/pending push state in panel
- [x] Ensure checkbox placeholder dot is centered in the checkbox
- [x] Improve spacing between elements in git panel entries
- [x] Update git branch icon to match branch selector text when disabled
- [x] Truncate last commit message less aggressively in panel
- [x] Clean up new panel header design
- [x] Remove `_background` version control keys (backgrounds are derived
from the foreground colors)
### Previous message truncation:
Before:
After:
### Make branch icon match when menu is disabled
Before:
After:
Release Notes:
- N/A *or* Added/Fixed/Improved ...
---------
Co-authored-by: Cole Miller <cole@zed.dev>
Co-authored-by: Cole Miller <m@cole-miller.net>
Co-authored-by: Max Brunsfeld <maxbrunsfeld@gmail.com>
Was dabbling on the shaders these past few days and felt like we could
have the WGSL logo. This is based on the logo found on the GPU Web
repository: https://github.com/gpuweb/gpuweb/tree/main/logo
Release Notes:
- N/A
Proper version of https://github.com/zed-industries/zed/pull/25425
When https://github.com/zed-industries/zed/pull/24857 returned font
updates on settings changes, settings values, not in-memory ones should
be compared.
This PR returns back the logic finally, and changes it to explicitly
track the settings values, not the in-memory ones.
Also adds the same tracking for UI font changes, which had never been
tracked before.
Release Notes:
- Fixed font sizes not reacting on settings change
Closes https://github.com/zed-industries/zed/issues/25413
As the issue points out well, themes do not need to alter any in-memory
state on load: that is done via settings file load.
Originally, it was introduced in
https://github.com/zed-industries/zed/pull/4064 and
https://github.com/zed-industries/zed/pull/24857 had restored that
behavior, which seems wrong to do.
Apart from removing that part, removes unnecessary methods and
emphasizes that in-memory state is the Buffer/UI size — no need to add
`Adjusted` there as the settings file presence is already enough.
Release Notes:
- Fixed theme selector resetting the buffer size
We've decided to go in a different direction on indicating the staged
status of hunks, so go back for now to a world where we don't display
staged and unstaged hunks differently outside the (still gated) project
diff editor.
cc @iamnbutler
This reverts commit 8c202b3b09.
Release Notes:
- N/A
This PR makes it so we don't log errors for missing themes or icon
themes until after the extensions have been loaded.
Currently, if you are using a theme that is defined in an extension it
is common to see one or more "theme not found" errors in the logs. This
is the result of us having to initialize the theme before the extensions
have actually finished loading.
This means that a theme that _may_ exist once extensions load is
considered non-existent before they have loaded.
To that end, we now wait until the extensions have loaded before we
start logging errors if we can't find the theme or icon theme.
Closes https://github.com/zed-industries/zed/issues/24539.
Release Notes:
- Reduced the number of "theme not found" and "icon theme not found"
errors in the logs for themes provided by extensions.
This PR updates the `ThemeRegistry` to return structured errors from the
`get` and `get_icon_theme` methods (which are used to retrieve themes
and icon themes, respectively).
We want to be able to carry the name of the theme that was not found as
state on the error, which is why we use a `Result` and not an `Option`.
However, we also want to be able to accurately identify when the error
case is "not found" so we can take appropriate action, based on the
circumstances.
By using a custom error type instead of an `anyhow::Error`, we get both.
There isn't any functional change in this PR. This just sets us up for
future improvements in this error.
Release Notes:
- N/A
.RData is a file that stores R objects.
Release Notes:
- Added file icon associations for `.rdata` and `.RData` files.
---------
Co-authored-by: Marshall Bowers <git@maxdeviant.com>
This PR adds the ability for icon themes to provide their own file
associations.
The old `file_types.json` that was previously used to make these
associations has been removed in favor of storing them on the default
theme.
Icon themes have two new fields on them:
- `file_stems`: A mapping of file stems to icon keys.
- `file_suffixes`: A mapping of file suffixes to icon keys.
These mappings produce icon keys which can then be used in `file_icons`
to associate them to a particular icon:
```json
{
"file_stems": {
"Makefile": "make"
},
"file_suffixes": {
"idr": "idris"
},
"file_icons": {
"idris": { "path": "./icons/idris.svg" },
"make": { "path": "./icons/make.svg" }
}
}
```
When loading an icon theme, the `file_stems` and `file_icons` fields
will be merged with the ones from the base icon theme, with the values
from the icon theme being loaded overriding ones in the base theme.
Release Notes:
- Added the ability for icon themes to provide their own file
associations.
