I'm not at my mac at the moment, but if you look at wezterm show-keys --lua you'll probably see a couple of keys with curly braces; I see this on my linux box:

    { key = '{', mods = 'SUPER', action = act.ActivateTabRelative(-1) },
    { key = '{', mods = 'SHIFT|SUPER', action = act.ActivateTabRelative(-1) },
    { key = '}', mods = 'SUPER', action = act.ActivateTabRelative(1) },
    { key = '}', mods = 'SHIFT|SUPER', action = act.ActivateTabRelative(1) },

I think you should also replace all of those in your config and I think that will sort this out.

I edited the security settings to allow dtolnay/rust-toolchain to run; I think you'll need to update this PR for them to trigger again.

Thanks for this!

planning a follow up PR to run less CI workflows if one fails and I have some questions about it:

1. Is this of any interest to you? I don't want you to review something you are not interested in.

In general, I do prefer that all of the builds run, because the main value I derive from them is running on all the different platforms that I cannot test locally. If one fails I don't want it to stop the others from trying and failing; they may fail differently, or they may succeed. Either way: it is valuable signal for my next steps.

In particular: I strongly dislike the fail-fast strategy that is the default on GH actions. That makes sense when trying to minimize infrastructure cost, but my goal with the CI is to maximize the value of the time of the human that is making changes.

2. Is it okay not to run _continous workflows if the non continous one fails?

The continuous builds in this repo are triggered on push or by schedule. The push builds should always run, as that is the main way that I catch things I may have overlooked before I push.

The scheduled builds are a bit redundant these days: they were from a time where the nightly builds used to only run on schedule and not on push.

The scheduled builds do occasionally surface problems with issues that may arise from a new rust compiler release, for example.

3. Is it okay to run one Linux workflow first (I am thinking Ubuntu22.04), and skip all other Linux workflows if it fails? It would still run the MacOS/Windows workflows.

No (because of the reasons above) but one thing I have been considering recently, because GH actions queues have been really clogged, is that I'd like the pages, a linux build + mac + windows to get priority over the rest of the linux distros.

I think that would mean changing the workflows for the other linux builds to use workflow_dispatch and then adding a "deferred linux dispatcher" workflow that essentially did something like:

• sleep 10 minutes
• dispatch the other linux workflows

I don't know if that will work very well, and it could end up being more frustrating always waiting an extra 10 minutes for them in cases where the queues work well.

Another alternative option is to mark a number of the linux platforms as "tier 2" and switch them from building on push, and instead have them run on a schedule, but again: that would just make the latency for getting a build worse in most cases.

I've yet to be convinced that this sort of optimization would actually be better either for me personally, or for users that may be waiting on a fix in the nightly.

4. Is it okay to run cargo check instead of cargo build in the non _tag/_continous workflows? Should be much faster than a full compile/optimize run.

The build does need to run. From experience, I've seen check succeed when build fails.

allow json encoding wezterm.GLOBAL entries

Neither kitty nor wezterm use gui frameworks like GTK or KDE

This should be resolved now in main.

It typically takes about an hour before commits are available as nightly builds for all platforms. Linux builds are the fastest to build and are often available within about 20 minutes. Windows and macOS builds take a bit longer.

Please take a few moments to try out the fix and let me know how that works out. You can find the nightly downloads for your system in the wezterm installation docs.

If you prefer to use packages provided by your distribution or package manager of choice and don't want to replace that with a nightly download, keep in mind that you can download portable packages (eg: a .dmg file on macOS, a .zip file on Windows and an .AppImage file on Linux) that can be run without permanently installing or replacing an existing package, and can then simply be deleted once you no longer need them.

If you are eager and can build from source then you may be able to try this out more quickly.

fix delegation of --skip-config to wezterm-gui

refs: #3325

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

Linux X11

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

I'm using KDE plasma so it should be kwin.

WezTerm version

wezterm 20230322-063603-f37c3ae5

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

zathura is a GTK pdf viewer app (I guess so), and when I execute zathura some.pdf in wezterm in my shell, the window opens normally but it appears under the wezterm window and didn't focus on it. It is raised (like xdotool windowraise) but not focused (like xdotool windowactive). When using konsole, alacritty, it focuses on the pdf viewer normally.

To Reproduce

Install zathura, and open any pdfs. For example on Arch,

sudo pacman -S zathura zathura-pdf-mupdf
zathura some.pdf

Configuration

With wezterm -n, the problem can still happens.

Expected Behavior

Should focus on the pdf viewer.

Logs

No error message there

Debug Overlay
wezterm version: 20230322-063603-f37c3ae5 x86_64-unknown-linux-gnu
Window Environment: X11 KWin
OpenGL version: Mesa Intel(R) Graphics (ADL GT2) 4.6 (Compatibility Profile) Mesa 23.0.0
Enter lua statements or expressions and hit Enter.
Press ESC or CTRL-D to exit

Anything else?

No response

This has nothing to do with wezterm. Your shell is launching that program and the terminal has no idea, control or influence over things, especially gui programs, spawned by your shell.

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

macOS

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

No response

WezTerm version

20230320-124340-559cb7b0

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

• When navigating splits via a keybind tied to ActivatePaneDirection, there is no visual indication that that new pane has been activated.
• Cursor does not change, inactive_pane_hsb is not applied, etc.
• Upon pressing any additional key, the issue immediately resolves. Any text is inserted in the expected pane.

To Reproduce

1. Split panes via SplitHorizontal or SplitVertical.
2. Attempt to navigate panes via ActivatePaneDirection.

Configuration

Keybinds:

    {
        key = '\\',
        mods = 'LEADER',
        action = action.SplitHorizontal({ domain = 'CurrentPaneDomain' }),
    },
    {
        key = '-',
        mods = 'LEADER',
        action = action.SplitVertical({ domain = 'CurrentPaneDomain' }),
    },

    -- Navigate panes.
    {
        key = 'h',
        mods = 'CTRL|SUPER',
        action = action.ActivatePaneDirection('Left'),
    },
    {
        key = 'l',
        mods = 'CTRL|SUPER',
        action = action.ActivatePaneDirection('Right'),
    },
    {
        key = 'k',
        mods = 'CTRL|SUPER',
        action = action.ActivatePaneDirection('Up'),
    },
    {
        key = 'j',
        mods = 'CTRL|SUPER',
        action = action.ActivatePaneDirection('Down'),
    },

Expected Behavior

When invoking ActivatePaneDirection, the newly activated pane should immediately indicate that it has been selected.

Logs

No response

Anything else?

No response

Duplicate of https://github.com/wez/wezterm/issues/2879

I'm open to this, however, I've looked into the sysinfo crate a couple of times and the way it works is to eagerly collect a great deal of information from the system when it is told to update its copy. That can take (relatively speaking!) a long time and I'm concerned about that being triggered in situations where we don't want to block the GUI. We already have some similar issues with the wezterm.procinfo family of functions.

I think it would be wise to cherry-pick from the sysinfo crate (with appropriate attribution to the author) just the relevant system information functions that we need so that can use them independently and so that users only pay for the cost of that they need.

Thank you!

I'm basically adding ` around page titles when relevant.

Also changing many pages to have an h1 header, otherwise mkdocs generates a h1 header from the file name which is usually not what you want I think

If you have other ideas of large small changes to do, I can easily do them #vim-all-the-things :smiley:

Fix some documentation pages (#3321)

• Update ssh_backend.md

• Update normalize_output_to_unicode_nfc.md

• Update strikethrough_position.md

• Update underline_position.md

• Update underline_thickness.md

• Fix lua config docs titles to be formatted as inline code

• Mention how suggested alphabet for quick select is choosen

• Mention update-status and update-right-status for status_update_interval

• Fix docs for all keyassignments to be formatted as inline code

• Fix Lua object index titles

• Fix titles of wezterm.* module index pages

• Fix title of Color object & wezterm.color functions

We reduce titles from h2 to h1 because mkdocs defaults the page title to the page file name if no h1 header is found.

• Unify title of all object methods

• Add index page for Gui events

Ah, possibly: seems like the top of that function should remove those new bits so that the rest of the function works as originally intended, something like this:

fn decoration_to_mask(decorations: WindowDecorations) -> NSWindowStyleMask {
   let decorations = decorations.difference(WindowDecorations::MACOS_FORCE_DISABLE_SHADOW | WindowDecorations::MACOS_FORCE_ENABLE_SHADOW);

I'm not going to be near my mac for for most of the day, so if you have time to try that out and want to send a PR, that would be great!

docs: changelog for #3227

Is your feature request related to a problem? Please describe. When the scroll wheel is scrolled while the mouse is on the tab bar, Wezterm switches the tab. Scrolling to be able to switch tabs is desirable to some people, but for others, such as me, it isn't. Personally, I find it somewhat annoying that when I scroll while my mouse happens to be above the tab bar, the tabs switch rapidly, potentially causing the whole terminal window to flicker.

Describe the solution you'd like A configuration option to disable switching tabs on scrolling the tab bar.

Describe alternatives you've considered I guess there's always the option of using a Wezterm build from before tab scrolling was added, or configuring my system somehow to not send mouse scroll events to Wezterm, but realistically, these would be drastic measures for what I personally find to be a mild annoyance.

Add config option for scrolling the tab bar

Add docs for new scroll_tabs config option

Cargo formatted

Changed config option name to mouse_wheel_scrolls_tabs, made it default to true (matching current behavior)

Apply suggestions from code review

Adds a boolean config option ~~scroll_tabs~~ mouse_wheel_scrolls_tabs, defaulting to true, controlling whether using the mouse wheel on the tab bar will switch between tabs.

Closes https://github.com/wez/wezterm/issues/2938

Apply suggestions from code review