Cannot use fonts installed with home-manager #18982
Comments
JosephTLyons
added
setting
|
Did a little investigating:
Now, if However, in my Nix install: $ ls .config/fontconfig
conf.d
$ ls .config/fontconfig/conf.d
10-hm-fonts.conf 52-hm-default-fonts.confSo, Alternatively,,maybe instructions could be given on how to make a regular Not sure how related to #17203 this is, I'm not familiar with Guix. (why aren't the code snippets aren't rendering sigh...) |
|
Everything works fine for me. Nix-installed fonts are available in Zed. { config, pkgs, ... }:
{
home.packages = with pkgs; [
nerd-fonts.jetbrains-mono
]
fonts.fontconfig = {
enable = true;
};
} |
|
Is there a workaround for this? @maciej-lech from your snippet i'm guessing you're running unstable? Doesn't work for me on stable and stable home manager. I tried using the nerd-fonts package from unstable but it didn't fix it. |
|
@maciej-lech sigh welp, i cant figure it out...because now it works? even with @repomaa what's your environment? if possible, could you make a rust project with the following snippet and see if adding/removing fonts with HM changes what shows? use fontdb::Database;
fn main() {
let mut db = Database::new();
db.load_system_fonts();
println!("{} font faces", db.len());
for f in db.faces() {
println!("{}", f.post_script_name);
}
} |
|
@repomaa yes, unstable. |
A `for..in` loop on a `BinaryHeap` is not sorted, see https://doc.rust-lang.org/std/collections/struct.BinaryHeap.html#method.iter so the old code, whilst presumably _intended_ to be sorted, was actually iterating with a random order. Collecting as a `Vec` then sorting is simpler and more efficient since `read_dir` depends on FS and can be in ascending order which degrades each insertion from `O(1)` to `O(log(n))`, amortised for `BinaryHeap`, see https://doc.rust-lang.org/alloc/collections/binary_heap/struct.BinaryHeap.html#time-complexity-3 That random order was causing downstream bugs: - zed-industries/zed#18982 - zed-industries/zed#22676 - flathub/dev.lapce.lapce#50 - RazrFalcon/fontdb#78 as, e.g. inside a flatpak, `/etc/fonts/conf.d/05-flatpak-fontpath.conf` features a `<remove-dirs />` that would then hide the flatpak-specific `<dir>`s like `/run/host/fonts` in `/etc/fonts/conf.d/50-flatppk.conf` if the `05-` file gets merged after the `50-` file.
A `for..in` loop on a `BinaryHeap` is not sorted, see https://doc.rust-lang.org/std/collections/struct.BinaryHeap.html#method.iter so the old code, whilst presumably _intended_ to be sorted, was actually iterating with a random order. Collecting as a `Vec` then sorting is simpler and more efficient since `read_dir` depends on FS and can be in ascending order which degrades each insertion from `O(1)` to `O(log(n))`, amortised, for `BinaryHeap`, see https://doc.rust-lang.org/alloc/collections/binary_heap/struct.BinaryHeap.html#time-complexity-3 That random order was causing downstream bugs: - zed-industries/zed#18982 - zed-industries/zed#22676 - flathub/dev.lapce.lapce#50 - RazrFalcon/fontdb#78 as, e.g. inside a flatpak, `/etc/fonts/conf.d/05-flatpak-fontpath.conf` features a `<remove-dirs />` that would then hide the flatpak-specific `<dir>`s like `/run/host/fonts` in `/etc/fonts/conf.d/50-flatppk.conf` if the `05-` file gets merged after the `50-` file.
A `for..in` loop on a `BinaryHeap` is not sorted, see https://doc.rust-lang.org/std/collections/struct.BinaryHeap.html#method.iter so the old code, whilst presumably _intended_ to be sorted, was actually iterating with a random order. Collecting as a `Vec` then sorting is simpler and more efficient since `read_dir` depends on FS and can be in ascending order which degrades each insertion from `O(1)` to `O(log(n))`, amortised, for `BinaryHeap`, see https://doc.rust-lang.org/alloc/collections/binary_heap/struct.BinaryHeap.html#time-complexity-3 That random order was causing downstream bugs: - zed-industries/zed#18982 - zed-industries/zed#22676 - flathub/dev.lapce.lapce#50 - RazrFalcon/fontdb#78 as, e.g. inside a flatpak, `/etc/fonts/conf.d/05-flatpak-fontpath.conf` features a `<reset-dirs />` that would then hide the flatpak-specific `<dir>`s like `/run/host/fonts` in `/etc/fonts/conf.d/50-flatppk.conf` if the `05-` file gets merged after the `50-` file.
|
Background: I fixed this problem in fontdb 0.19.0+ (I think, it might have been 0.18.0+). I attempted to propagate the fix to all dependent crates (and ultimately here), either with issues or PRs. The problem is that the author of the crate doesn't use Cargo versioning correctly - meaning that Cargo considers 0.17.0 and 0.18.0 etc. incompatible (they are, in fact, compatible). Furthermore, the same author is responsible for a widely used SVG crate that uses fontdb, and it seems that they are/were experiencing massive burnout (which is completely understandable, especially given their location) - so it took a significant amount of time for them to get round to updating the fontdb dep in usvg. During that time, upgrading fontdb was attempted but had to be rolled back: pop-os/cosmic-text#295 - the reason is that cosmic-ui used usvg, so cosmic-ui wound up with different versions of fontdb (one via cosmic-text, the other via resvg/usvg). Ultimately it looks like the System76 developers are going to have to coordinate a crate update for cosmic-text and cosmic-ui (resvg+usvg seems to have been updated since I last looked at this, but not cosmic-text). This is why my flake+fork (which danielgafni has since forked and begun to maintain) uses a fontdb override, to a fontdb fork of mine that falsely declares it's the older version: https://github.com/jcdickinson/fontdb/tree/0-18-backport . zed-industries could do likewise, fontdb is a relatively slow moving crate - so it shouldn't take much effort. @P1n3appl3 just a lay of the land/minefield so that you can avoid the failures that I made. I haven't kept track of this since the cosmic-text rollback, so maybe something has changed. Edit: the underlying bug is that symlinks aren't followed at all, and given how everything Nix works... |
|
Just an extra note to add if petitioning for a coordinated crate update train starts soon: Another bug certain setups might encounter (the big one being (almost) all flatpak installs, but I'm sure certain Nix setups too hence the relevancy here) is actually one further level upstream than That's fixed in this PR: Riey/fontconfig-parser#11 pending review & merge. This is, arguably, quite a big bug, so ideally the update train will include it - especially since it sounds like updating Ideally, system font discovery should really be its own package that uses the OS' database, with |
Check for existing issues
Describe the bug / provide steps to reproduce it
Fonts installed with home-manager aren't valid options in the
buffer_font_familyandui_font_familyoptions.Putting fonts installed using home-manager (for me I have
InterandCodeNewRoman Nerd Font) as values for those options doesn't work, with a "Value is not accepted" warning popping up.Curiously:
.SystemUIFontset as the value forbuffer_font_familysets Inter as the font (butInterdoesn't).monospaceand.monospacedon't work either.The relevant sections of my
home.nix(the full thing is here) are:Environment
Zed: v0.155.2 (Zed)
OS: Linux Wayland fedora 40
Memory: 15.4 GiB
Architecture: x86_64
GPU: Intel(R) UHD Graphics 620 (KBL GT2) || Intel open-source Mesa driver || Mesa 24.1.7
If applicable, add mockups / screenshots to help explain present your vision of the feature
transcription
a picture of two panes in Zed,
the left pane has settings.json open with the following content:
the last line has a warning attached, with the message "Value is not accepted."
the right pane has a terminal open, with the following content:
If applicable, attach your Zed.log file to this issue.
Zed.log
The text was updated successfully, but these errors were encountered: