Skip to content
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

window config override for harfbuzz_features doesn't work if font already specifies them #5420

Open
LunarLambda opened this issue May 14, 2024 · 0 comments
Labels
bug Something isn't working

Comments

@LunarLambda
Copy link

What Operating System(s) are you seeing this problem on?

Linux X11

Which Wayland compositor or X11 Window manager(s) are you using?

GNOME

WezTerm version

wezterm 20240513-184050-44b61d7e

Did you try the latest nightly build to see if the issue is better (or worse!) than your current version?

Yes, and I updated the version box above to show the version of the nightly that I tried

Describe the bug

Following the advice of #5403 (comment), I tried to set a window config override for harfbuzz_features, however it does not take precedence over the harfbuzz features described in my config's font setting.

Also, the toggle-ligature example here doesn't work if the font specifies harfbuzz_features already.

The issue is that I have multiple fonts with different harfbuzz_features set:

    -- These both had 'calt=0' previously
    font = w.font_with_fallback {
        {
            family = 'Berkeley Mono',
        },
        {
            family = 'FiraCode Retina',
            harfbuzz_features = { 'ss03', 'ss05' }
        },
    },

And I would simply like to add/remove calt=0 from the list for all of them, and keep the remaining features as specified.

To Reproduce

No response

Configuration

My config:

local w = require 'wezterm'

w.on('update-status', function(window, pane)
    local wo = window:get_config_overrides() or {}

    if pane:is_alt_screen_active() then
        wo.harfbuzz_features = { 'calt=1' }
    else
        wo.harfbuzz_features = { 'calt=0' }
    end

    window:set_config_overrides(wo)
end)

return {
    font = w.font_with_fallback {
        {
            family = 'Berkeley Mono',
        },
        {
            family = 'FiraCode Retina',
            harfbuzz_features = { 'ss03', 'ss05' }
        },
    },
    font_size = 15,
    freetype_load_target = 'Light',
    freetype_render_target = 'HorizontalLcd',
}

Repro using the example from documentation:

local wezterm = require 'wezterm'

wezterm.on('toggle-ligature', function(window, pane)
  local overrides = window:get_config_overrides() or {}
  if not overrides.harfbuzz_features then
    -- If we haven't overridden it yet, then override with ligatures disabled
    overrides.harfbuzz_features = { 'calt=0', 'clig=0', 'liga=0' }
  else
    -- else we did already, and we should disable out override now
    overrides.harfbuzz_features = nil
  end
  window:set_config_overrides(overrides)
end)

return {
  keys = {
    {
      key = 'E',
      mods = 'CTRL',
      action = wezterm.action.EmitEvent 'toggle-ligature',
    },
   font = w.font { family = 'FiraCode Retina', harfbuzz_features = { 'ss03', 'ss05' } },
  },
}

When removing harfbuzz_features from font, it works. Else it does not.

Expected Behavior

window config override harfbuzz_features should be appended/merged with harfbuzz_features set by the current font.

I want to avoid duplicating my font configuration in multiple places, and manually adding/removing elements from the harfbuzz_features table for each font or determining which font is currently being used seems difficult given the APIs provided by wezterm.

Logs

14:01:27.304 INFO wezterm_gui > Spawned your command via the existing GUI instance. Use wezterm start --always-new-process if you do not want this behavior. Result=SpawnResponse { tab_id: 2, pane_id: 2, window_id: 2, size: TerminalSize { rows: 24, cols: 80, pixel_width: 640, pixel_height: 384, dpi: 0 } }

Anything else?

No response

@LunarLambda LunarLambda added the bug Something isn't working label May 14, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

1 participant