A GPU-accelerated cross-platform terminal emulator and multiplexer written by @wez and implemented in Rust

Overview

Wez's Terminal

WezTerm Icon A GPU-accelerated cross-platform terminal emulator and multiplexer written by @wez and implemented in Rust

User facing docs and guide at: https://wezfurlong.org/wezterm/

Screenshot

Screenshot of wezterm on macOS, running vim

Installation

https://wezfurlong.org/wezterm/installation.html

Getting help

This is a spare time project, so please bear with me. There are a couple of channels for support:

The GitHub Discussions and Element/Gitter rooms are better suited to questions than it is to bug reports, but don't be afraid to use whichever you are most comfortable using and we'll work it out.

Comments
  • Support input method editors for X11

    Support input method editors for X11

    Describe the bug

    Hello Wez,

    I use UIM for switching the input method to Korean. I have bound it to ctrl + alt + space. Works fine in my current terminal emulator (terminator), but not in wezterm. I only get a log message saying

    2020-08-03T10:19:42.583Z ERROR wezterm_term::terminalstate > Ding! (this is the bell)

    I have no idea whether this is an issue with UIM or wezterm, but I found this and thought it might be related:

    FIXME in shift-space now emits space maybe?

    My guess (without looking at any code and / understanding how wezterm or UIM work) would be that wezterm swallows the key presses.

    Environment (please complete the following information):

    • OS: Linux (Debian Sid)
    • Version: wezterm 20200718-095447-d2315640

    To Reproduce

    Steps to reproduce the behavior.

    Please include as much information as possible that can help to reproduce and understand the issue; some pointers and suggestions are included here in this template. You are empowered to include more or less information than is asked for here!

    Configuration

    Happens without a config file. Also happens with use_ime = true, but from the text that appears to only affect MacOS anywat.

    Expected behavior

    When I press ctrl + alt + space, UIM receives that key combination so it can switch my IM.

    Screenshots

    Session Recording

    Additional context

    Add any other context about the problem here.

    enhancement Linux X11 fixed-in-nightly 
    opened by promisedlandt 44
  • Wezterm does not always notice window resize

    Wezterm does not always notice window resize

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

    Linux X11

    WezTerm version

    20220514-175933-64b6e63f

    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

    Sometimes wezterm does not recognize its window resize. Especially toggling fullscreen mostly does not work while resizing horizontally or vertically in a incremental fashion works a bit better. Please watch my screen recording.

    It seems that continuously (frequently) changing window size makes wezterm notice resize events, e.g., by using mouse or by holding keys for shrinking/enlarging a window or toggling fullscreen.

    I tried both my window manager's key binding and wezterm's Alt+Enter to toggle fullscreen state.

    I'm using i3, specifically i3-gaps v4.20.1, as the window manager on Gentoo Linux.

    To Reproduce

    Launch a wezterm and resize its window.

    Configuration

    no config

    Expected Behavior

    Resizing a terminal window should affect the terminal's content area size.

    Logs

    wezterm-20220514-175933-64b6e63f.log

    https://user-images.githubusercontent.com/158553/168458998-ad2f24ae-ca59-4995-b07f-c5f5cd15abdf.mp4

    Anything else?

    I bisected at release level and found that WezTerm-20210502-154244-3f7122cb-Ubuntu16.04.AppImage worked much better than WezTerm-20210814-124438-54e29167-Ubuntu16.04.AppImage. Although the former do fail to response to fullscreen toggle but much less frequently.

    I've checked the release notes of the latter, it seems that the most relevant issue is only #695.

    bug nvidia 
    opened by yuttie 38
  • wezterm doesn't handle bitmap fonts with strikes spread across multiple files

    wezterm doesn't handle bitmap fonts with strikes spread across multiple files

    @wez the Terminus installation on Arch has a bunch of otb files for each strike size:

    ❯ fc-list | rg -i 'Terminus'
    /usr/share/fonts/misc/ter-u22n.otb: Terminus:style=Regular
    /usr/share/fonts/misc/ter-u20n.otb: Terminus:style=Regular
    /usr/share/fonts/misc/ter-u22b.otb: Terminus:style=Bold
    /usr/share/fonts/misc/ter-u20b.otb: Terminus:style=Bold
    /usr/share/fonts/misc/ter-u24n.otb: Terminus:style=Regular
    /usr/share/fonts/misc/ter-u32n.otb: Terminus:style=Regular
    /usr/share/fonts/misc/ter-u28n.otb: Terminus:style=Regular
    /usr/share/fonts/misc/ter-u24b.otb: Terminus:style=Bold
    /usr/share/fonts/misc/ter-u18n.otb: Terminus:style=Regular
    /usr/share/fonts/misc/ter-u12n.otb: Terminus:style=Regular
    /usr/share/fonts/misc/ter-u16n.otb: Terminus:style=Regular
    /usr/share/fonts/misc/ter-u14n.otb: Terminus:style=Regular
    /usr/share/fonts/misc/ter-x12b.pcf.gz: xos4 Terminus:style=Bold
    /usr/share/fonts/misc/ter-x22b.pcf.gz: xos4 Terminus:style=Bold
    /usr/share/fonts/misc/ter-x32b.pcf.gz: xos4 Terminus:style=Bold
    /usr/share/fonts/misc/ter-x18b.pcf.gz: xos4 Terminus:style=Bold
    /usr/share/fonts/misc/ter-x20b.pcf.gz: xos4 Terminus:style=Bold
    /usr/share/fonts/misc/ter-x28b.pcf.gz: xos4 Terminus:style=Bold
    /usr/share/fonts/misc/ter-x16b.pcf.gz: xos4 Terminus:style=Bold
    /usr/share/fonts/misc/ter-x14n.pcf.gz: xos4 Terminus:style=Regular
    /usr/share/fonts/misc/ter-x14b.pcf.gz: xos4 Terminus:style=Bold
    /usr/share/fonts/misc/ter-x24n.pcf.gz: xos4 Terminus:style=Regular
    /usr/share/fonts/misc/ter-x24b.pcf.gz: xos4 Terminus:style=Bold
    /usr/share/fonts/misc/ter-x16n.pcf.gz: xos4 Terminus:style=Regular
    /usr/share/fonts/misc/ter-x18n.pcf.gz: xos4 Terminus:style=Regular
    /usr/share/fonts/misc/ter-x20n.pcf.gz: xos4 Terminus:style=Regular
    /usr/share/fonts/misc/ter-x28n.pcf.gz: xos4 Terminus:style=Regular
    /usr/share/fonts/misc/ter-x12n.pcf.gz: xos4 Terminus:style=Regular
    /usr/share/fonts/misc/ter-x22n.pcf.gz: xos4 Terminus:style=Regular
    /usr/share/fonts/misc/ter-u12b.otb: Terminus:style=Bold
    /usr/share/fonts/misc/ter-x32n.pcf.gz: xos4 Terminus:style=Regular
    /usr/share/fonts/misc/ter-u16b.otb: Terminus:style=Bold
    /usr/share/fonts/misc/ter-u14b.otb: Terminus:style=Bold
    /usr/share/fonts/misc/ter-u18b.otb: Terminus:style=Bold
    /usr/share/fonts/misc/ter-u32b.otb: Terminus:style=Bold
    /usr/share/fonts/misc/ter-u28b.otb: Terminus:style=Bold
    

    Problem is that on wezterm, no matter what font_size I set for Terminus, I always get the smallest sized one. I don't have similar problem with Alacritty. I'm trying setting values after pt2px conversion to no avail as well (I have 96 dpi).

    FWIW, I'm trying to replicate this, not sure whether it's possible at all on wezterm.

    Originally posted by @oblitum in https://github.com/wez/wezterm/issues/1165#issuecomment-932732562

    opened by wez 34
  • Crash with wayland enabled on Gnome Wayland and display scaling enabled

    Crash with wayland enabled on Gnome Wayland and display scaling enabled

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

    Linux Wayland

    WezTerm version

    wezterm 20220317-165235-27088fab

    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

    Unsupported modifier, resource creation failed.
    XXX: resource creation failed
     2022-03-18T01:41:36.947Z INFO  wezterm_gui::termwindow        > OpenGL initialized! Mesa Intel(R) UHD Graphics (CML GT2) 4.6 (Compatibility Profile) Mesa 22.0.0 is_context_loss_possible=false wezterm version: 20220317-165235-27088fab
    Unsupported modifier, resource creation failed.
    XXX: resource creation failed
     2022-03-18T01:41:37.042Z ERROR wezterm_gui                    > Error while flushing display: Broken pipe (os error 32); terminating
    thread 'main' panicked at 'cannot access a Thread Local Storage value during or after destruction: AccessError', /rustc/9d1b2106e23b1abd32fce1f17267604a5102f57a/library/std/src/thread/local.rs:388:26
    note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
    fish: Job 1, 'cargo run --release --bin wezte…' terminated by signal SIGILL (Illegal instruction)```
    
    ### To Reproduce
    
    1. Enable wayland
    2. Attempt to launch the application
    
    ### Configuration
    
    local wezterm = require 'wezterm';
    
    return {
        enable_wayland = true,
    }
    
    
    ### Expected Behavior
    
    Application launches and displays a window
    
    ### Logs
    
    _No response_
    
    ### Anything else?
    
    _No response_
    bug Wayland fixed-in-nightly 
    opened by szbergeron 31
  • Maximizing leads to crash

    Maximizing leads to crash

    Describe the bug

    Maximize => crash, "X11 connection is broken: ClosedReqLenExceed"

    Environment (please complete the following information):

    • Ubuntu 20.04, GNOME

    To Reproduce

    Maximize.

    Configuration

    local wezterm = require 'wezterm';
    
    return {
      font = wezterm.font("Fira Code Nerd Font"),
    
      font_size = 14.0,
      font_antialias = "Subpixel",
      font_hinting = "Full",
    
      dpi = 96.0,
    
      color_scheme = "Afterglow",
    
      keys = {
         {key="1", mods="ALT", action=wezterm.action{ActivateTab=0}},
         {key="2", mods="ALT", action=wezterm.action{ActivateTab=1}},
         {key="3", mods="ALT", action=wezterm.action{ActivateTab=2}},
         {key="4", mods="ALT", action=wezterm.action{ActivateTab=3}},
         {key="5", mods="ALT", action=wezterm.action{ActivateTab=4}},
         {key="6", mods="ALT", action=wezterm.action{ActivateTab=5}},
         {key="7", mods="ALT", action=wezterm.action{ActivateTab=6}},
         {key="8", mods="ALT", action=wezterm.action{ActivateTab=7}},
         {key="9", mods="ALT", action=wezterm.action{ActivateTab=8}},
         {key="Tab", mods="CTRL", action=wezterm.action{ActivateTabRelative=1}},
         {key="Tab", mods="CTRL|SHIFT", action=wezterm.action{ActivateTabRelative=-1}},
         {key="0", mods="CTRL", action="ResetFontSize"},
         {key="+", mods="CTRL", action="IncreaseFontSize"},
         {key="-", mods="CTRL", action="DecreaseFontSize"},
      }
    }
    

    Expected behavior

    Window maximized

    Screenshots

    image

    Additional context

    Have a GNOME extension, Pixel Saver that puts window border icons (close/maximize/minimize) in the GNOME top bar, perhaps that causes X to return something unexpected to wezterm.

    bug X11 
    opened by dsvensson 31
  • Two Applications Opening on OpenSUSE Repo Varient

    Two Applications Opening on OpenSUSE Repo Varient

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

    Linux Wayland

    WezTerm version

    20220408.101518.b908e2dd~232-1.1

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

    No, and I'll explain why below

    Describe the bug

    I have installed the wezterm application from the opensuse repository. When I open the application, two applications appear on my task manager, WezTerm and wezterm-gui.

    Also, the opensuse repository is not up to date. Thank you!

    To Reproduce

    No response

    Configuration

    -- WezTerm -- https://wezfurlong.org/wezterm/

    local wezterm = require 'wezterm'

    return { default_prog = {"/usr/bin/zsh", "-l"},

    check_for_updates = false,

    color_scheme= "nord",

    window_background_opacity = 0.90, initial_rows = 30, initial_cols = 130,

    font = wezterm.font("MonoLisa Nerd Font"), font_size=12,

    -- Cursor style default_cursor_style = 'BlinkingBar',

    -- Enable CSI u mode -- https://wezfurlong.org/wezterm/config/lua/config/enable_csi_u_key_encoding.html enable_csi_u_key_encoding = true

    }

    Expected Behavior

    When I open my application it should say just WezTerm is running instead of opening a separate application called wezterm-gui

    Logs

    No response

    Anything else?

    https://i.imgur.com/f4mSmLc.pn f4mSmLc

    Thank you so much for the help! Love the terminal otherwise though :)

    bug 
    opened by epswims 27
  • vttest

    vttest

    Describe the bug

    Are you using vttest ? It is a great way to test your terminal features. Some of them fails now.

    Also maybe this comment might help.

    Environment (please complete the following information):

    • macOS 10.15.2 (19C57)
    • Frontend: not sure
    • 20200113-222147-724ad3a

    To Reproduce

    Download vttest from: https://invisible-island.net/vttest/

    run vttest from terminal

    press 1 to run the first test. press Enter several times to skip to next test and show errors.

    bug 
    opened by erf 27
  • Change color of tab depending on pane feature

    Change color of tab depending on pane feature

    Is your feature request related to a problem? Please describe.

    I use toolbox to run certain things at work and it looks more or less the same as my regular account. I do use starship to change the prompt, but it would be amazing if the tab could also indicate that this tab runs in toolbox.

    Describe the solution you'd like It would be amazing if wezterm could change to color/add a prefix of the tab based on the tab title or an env variable or a file or so (the actual flag is the existence of a file but I think I can set a env variable or use a title command to change the tab title).

    Describe alternatives you've considered As far as I understand the config (https://wezfurlong.org/wezterm/config/lua/config/tab_bar_style.html) does not allow for context based styling of specific panes.

    One alternative is using the right status, as pane:get_title() exists. But that doesn't show non-active tab(s) which run in that environment.

    enhancement fixed-in-nightly waiting-on-op 
    opened by jankatins 26
  • Add config option to always open window in full screen/maximized

    Add config option to always open window in full screen/maximized

    Is your feature request related to a problem? Please describe. When using wezterm on laptop, the window size is too small and I have to maximize the window everytime.

    Describe the solution you'd like It would be really nice, if it there is a configuration option to always open the window in full screen/maximized.

    Describe alternatives you've considered Similar behaviour can be obtained by setting initial_rows and initial_cols, but needs to be configured per machine/monitor.

    Additional context

    #256 #177

    enhancement fixed-in-nightly 
    opened by JoyceBabu 26
  • CPU usage rises until reload

    CPU usage rises until reload

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

    Windows, FreeBSD X11

    WezTerm version

    20220319-142410-0fcdea07

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

    No, and I'll explain why below

    Describe the bug

    First off, just want to say that I've used a bunch of terminals over the years and this is my favorite terminal by far. Keep up the good work and hopefully I'll be able to contribute in the future someday :) Now, onto the issue...

    I've noticed that wezterm-gui will start to eat up more and more CPU usage over time. It doesn't seem to happen all of a sudden, but the average utilization seems to climb higher and higher. I realize it after I've noticed that my CLI has become slower and slower. I'll switch to the htop tab and see wezterm-gui at the top. I'll hit Ctrl+Shift+R to reload the config and the CPU usage subsides quickly after that. It's strange.

    I have three workstations (freebsd/amd64, win10/amd64, & macOS/arm64). I haven't noticed it on macOS yet, but I rarely use wezterm directly on there (mainly just Windows + FreeBSD). I've only really noticed it on FreeBSD, but that happens to be my primary workstation.

    The fact that it builds up slowly and then subsides on config reload makes me wonder if it's accumulating file handles or whatnot. I haven't looked at the source for wezterm and don't know which crates it's using, but assuming that underneath it's using kqueue() to watch config files, FreeBSD has a known issue where it has to open a fd for each file being watched (whereas inotify just creates a watcher on the root directory).

    When I started writing this post I did a reload of the wezterm config and wezterm-gui CPU utilization was at 0.2%. Over the past few minutes it has risen to 10% with no interaction with wezterm. It's strange.

    To Reproduce

    Unsure, as I don't even know when or how it's triggered.

    Configuration

    animation_fps = 1 cursor_blink_ease_in = "Linear" cursor_blink_ease_out = "Linear"

    Expected Behavior

    CPU usage remains <1% at idle.

    Logs

    14:19:21.471 INFO wezterm_gui::termwindow > Ding! (this is the bell) in pane 1 14:19:37.095 INFO wezterm_gui::termwindow > Ding! (this is the bell) in pane 1 17:37:56.570 INFO wezterm_gui::termwindow > Ding! (this is the bell) in pane 4 17:37:58.824 INFO wezterm_gui::termwindow > Ding! (this is the bell) in pane 4 17:38:08.018 INFO wezterm_gui::termwindow > Ding! (this is the bell) in pane 4 18:27:53.003 WARNING wezterm_term::terminalstate > unhandled DecPrivateMode SetDecPrivateMode(Unspecified(1015)) 18:27:53.004 WARNING wezterm_term::terminalstate > unhandled DecPrivateMode ResetDecPrivateMode(Unspecified(1015)) 18:28:31.712 WARNING wezterm_term::terminalstate > unhandled DecPrivateMode SetDecPrivateMode(Unspecified(1015)) 18:28:31.713 WARNING wezterm_term::terminalstate > unhandled DecPrivateMode ResetDecPrivateMode(Unspecified(1015)) 18:28:43.346 WARNING wezterm_term::terminalstate > unhandled DecPrivateMode SetDecPrivateMode(Unspecified(1015)) 18:28:43.347 WARNING wezterm_term::terminalstate > unhandled DecPrivateMode ResetDecPrivateMode(Unspecified(1015)) 18:28:52.629 WARNING wezterm_term::terminalstate > unhandled DecPrivateMode SetDecPrivateMode(Unspecified(1015)) 18:28:52.629 WARNING wezterm_term::terminalstate > unhandled DecPrivateMode ResetDecPrivateMode(Unspecified(1015)) 18:44:25.816 INFO wezterm_gui::termwindow > Ding! (this is the bell) in pane 1

    Anything else?

    No response

    bug 
    opened by xorander00 25
  • Text is brighter than the previous release

    Text is brighter than the previous release

    Describe the bug

    After getting a "new release" notification today, I switched from a version from June (wezterm-git (wezterm.ssh.0.1.1.120.g20c4dcdc-1)) to a nightly build (wezterm-nightly-bin (20210815.182117.ab21910d-1)). I immediately noticed multiple changes to how the content is rendered, compared to instances of the previous version I still have running.

    • The cursor sometimes has "fuzzy" edges, compared to the previously sharp edges.
      • With my custom "Gruvbox Light Soft" colour scheme, this happens for active panels, while the inactive ones are fine
      • With the default colour scheme, it's the other way around
    • Text is now bold(er) and colours have changed slightly
    • Contrary to the text getting bolder, the character used to render the separator between panes is now thinner. It's also used in Kakoune, where the change is the same.
    • Dimming for inactive panes doesn't affect the background colour any more. Only the text colour changes.
      • It does work again when the inactive pane is running Kakoune.

    Environment:

    • OS: Linux X11
    • Version: wezterm 20210815-182117-ab21910d

    Configuration

    Font settings:

    font = wezterm.font("Hack Nerd Font"),
    font_size = 14,
    

    Colour Scheme:

    # Gruvbox Light Soft
    [colors]
    background = "#f2e5bc"
    foreground = "#3c3836"
    cursor_bg = "#3c3836"
    cursor_border = "#f2e5bc"
    cursor_fg = "#f2e5bc"
    
    # black, red, green, yellow, blue, purple, teal, white
    ansi = ["#282828","#cc241d","#98971a","#d79921","#458588","#b16286","#689d6a","#928374"]
    brights = ["#7c6f64","#9d0006","#79740a","#b57614","#076678","#8f3f71","#427b58","#7c6f64"]
    

    Screenshots

    Fuzzy cursor: image

    Bold text, different colours: Old version is top. image

    Active vs Dimmed: Active is top. image

    bug 
    opened by sclu1034 25
  • Mouse selection with Shift inconsistent

    Mouse selection with Shift inconsistent

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

    Windows, Linux X11, Linux Wayland

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

    Window 10, Fedora 37 with GNOME.

    WezTerm version

    20221231-234404-7c886744

    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 I select test with the mouse while holding Shift, I always expect that a new area would be selected. That's the behavior of most Linux terminals, such as xterm and gnome-terminal. That's also the Putty behavior on Windows, WezTerm is inconsistent in its behavior. If the application in the terminal is using the mouse (e.g. Midnight Commander), I get the expected behavior. Otherwise (e.g. bash), WezTerm is extending the existing selection if there is one. Worse yet, WezTerm would "extend" the selection if there is none; the other point is where I last clicked the mouse. Extending the selection is a behavior that I never expect. Over the years of using various Linux terminals, I got accustomed to the a simple, consistent behavior - when I'm holding Shift, the mouse copies whatever I select, whether I'm running a mouse aware application or not. I noticed that behavior on Windows first and them verified that it exists on Linux as well, bot with Wayland and X11.

    To Reproduce

    • Run WezTerm
    • Select a word with the mouse
    • While holding Shift, try selecting another word

    Configuration

      bypass_mouse_reporting_modifiers = 'SHIFT',
    

    Expected Behavior

    The new word is selected. No other text is selected.

    Logs

    Not sure it's relevant, these are the only logs I'm seeing

    23:59:53.445  WARN   wezterm_term::terminalstate > save/restore dec mode HighlightMouseTracking unimplemented
    00:00:13.816  WARN   wezterm_term::terminalstate > save/restore dec mode HighlightMouseTracking unimplemented
    00:00:21.799  WARN   wezterm_term::terminalstate > save/restore dec mode HighlightMouseTracking unimplemented
    

    Anything else?

    I had to move my development from Linux to Windows recently due to VPN requirements, and I really need a terminal that would allow me to work as before without relearning, especially because I'm still using Linux computers when not on VPN. There are many good Windows terminal emulators that don't implement mouse copy with Shift correctly. WezTerm is almost there, but it's still letting me down when I'm not running Midnight Commander.

    bug 
    opened by proski 0
  • Wezterm window glitches and lags behind cursor when moved between 2 windows on 150% window scale

    Wezterm window glitches and lags behind cursor when moved between 2 windows on 150% window scale

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

    Windows

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

    Windows, scale: 150% display 1: 2560 x 1440 display 2: 1680 x 1050

    WezTerm version

    20221227-101049-8b05fdba

    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

    Wezterm window glitches and lags behind cursor when moved between 2 windows on 150% window scale. The issue is not present on 100% scale or with any other programs I tried. https://user-images.githubusercontent.com/46792251/210055956-e780424b-3439-4618-a684-72b76e1dd68f.mp4

    To Reproduce

    Have 2 different screens, side by side, with different resolutions and windows scale at 150%. Move Wezterm window between them.

    Configuration

    local wezterm = require 'wezterm'

    return { font = wezterm.font 'Fira Code', default_prog = { 'C:\Program Files\PowerShell\7\pwsh.exe', '-NoLogo' }, color_scheme = "Dracula (Official)", harfbuzz_features = { 'calt=0', 'clig=0', 'liga=0' }, -- Start-Process wezterm pwsh -Verb runAs

    use_fancy_tab_bar = false,

    window_frame = { -- The font used in the tab bar. -- Roboto Bold is the default; this font is bundled -- The size of the font in the tab bar. -- Default to 10. on Windows but 12.0 on other systems font_size = 10.0,

    -- The overall background color of the tab bar when
    -- the window is focused
    active_titlebar_bg = '#333333',
    
    -- The overall background color of the tab bar when
    -- the window is not focused
    inactive_titlebar_bg = '#333333',
    

    },

    colors = { tab_bar = { inactive_tab_edge = '#575757', }, }, ssh_domains = {}, }

    Expected Behavior

    No response

    Logs

    No response

    Anything else?

    No response

    bug 
    opened by anzepintar 1
  • wezterm record - paste clipboard inserts additional chars at random positions

    wezterm record - paste clipboard inserts additional chars at random positions

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

    Windows

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

    No response

    WezTerm version

    20221122-154621-68c754b1

    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

    if i paste from system clipbard something into the terminal while recording the session the content is been destroyed with multiple chars at different positions.

    To Reproduce

    1. start a new wezterm wezterm -n start to get a clean configuration (I also unregistered clink)
    2. start a new record session inside this terminal wezterm record
    3. copy a new text to system clipboard (e.g. with notepad.exe), in my example TestTestTest
    4. press <ctrl><shift><v> to paste it

    it will produce TestT1;1;0;1_stTes_Test

    Configuration

    no config

    Expected Behavior

    No response

    Logs

    No response

    Anything else?

    No response

    bug 
    opened by Grueslayer 0
  • wezterm imgcat with vifm

    wezterm imgcat with vifm

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

    Windows

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

    No response

    WezTerm version

    20221122-154621-68c754b1

    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

    wezterm and vifm using imgcat don't work quite well together, some behaviour maybe is Windows specific other maybe a global issue.

    adding this to vifmrc will add a preview (when using :view in vifm) for picture files

      fileviewer {*.bmp,*.jpg,*.jpeg,*.png,*.gif,*.xpm},<image/*>
             \ wezterm imgcat --width %pw --height %ph %c:p %pd
    

    for windows maybe using escaped filepath is better

      fileviewer {*.bmp,*.jpg,*.jpeg,*.png,*.gif,*.xpm},<image/*>
             \ wezterm imgcat --width %pw --height %ph %"c:p %pd
    

    On MacOS it will correctly displays the image but the file list pane will get corrupted. Maybe that can be fixed by not changing the cursor?

    So we need to add an option to wezterm imgcat. By the way, it would be nice to have the upper left position X/Y also as new parameters like imgcat support.

    On Windows it looks quite different: No image (or any other thing) is been displayed, the area keeps empty. Calling wezterm imgcat with the same parameters diplays it the right way.

    So I can only assume

    a) it is been displayed outside the area (because vifm has a different cursor position on windows, so having x/y as parameter like described above may help) b) vifm has a different / alternative screen area than wezterm uses

    Would be fine to fix both things (maybe we need the help from vifm maintainer).

    I can help to setup vifm for testing purposes on your system.

    To Reproduce

    No response

    Configuration

    no config

    Expected Behavior

    No response

    Logs

    No response

    Anything else?

    No response

    bug 
    opened by Grueslayer 2
  • High cpu usage for Xorg

    High cpu usage for Xorg

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

    Linux X11

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

    i3-gaps. I tried with lightdm and gdm - the same.

    WezTerm version

    20221225-233013-ff2caf4f

    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 i open wezterm, Xorg uses a lot of cpu resource. It doesn't always happen right away, sometimes after a while. And value of cpu usage gradually increases before 100%. I see freezes in wezterm in the same time. image image

    It doesn't happen with alacritty and kitty. It doesn't happen in gnome ubuntu, only when i use i3wm.

    To Reproduce

    No response

    Configuration

    local wezterm = require 'wezterm'
    
    -- FONTS --
    
    local font = function(name, params)
      local names = {
        name,
        'Iosevka Nerd Font',
      }
    
      return wezterm.font_with_fallback(names, params)
    end
    
    local font_config = ({
      jet_brains = {
        font_size = 9.5,
        font = wezterm.font('JetBrainsMono Nerd Font'),
        cell_width = 0.87,
        font_rules = {
          {
            font = wezterm.font('JetBrainsMono Nerd Font', { weight = 'Medium' }),
          },
        },
        line_height = 0.9,
      },
      iosevka = {
        font_size = 10.7,
        font = wezterm.font('Iosevka Nerd Font'),
        line_height = 0.9,
        font_rules = {
          {
            font = font('Iosevka Nerd Font', { italic = false, weight = 'Medium' })
          }
        }
      },
      victor_mono = {
        font_size = 10,
        font = font('VictorMono'),
        line_height = 0.80,
        font_rules = {
          {
            font = font('VictorMono', { italic = false })
          }
        }
      },
      caskaydia = {
        font_size = 10.2,
        line_height = 1,
        cell_width = 1,
        font = wezterm.font('CaskaydiaCovePL Nerd Font'),
        font_rules = {
          {
            italic = true,
            font = wezterm.font('CaskaydiaCovePL Nerd Font', { italic = false, weight = 'Regular' })
          },
          {
            intensity = 'Bold',
            font = wezterm.font('CaskaydiaCovePL Nerd Font', { italic = false, weight = 'Regular' })
          },
          {
            font = wezterm.font('CaskaydiaCovePL Nerd Font', { italic = false, weight = 'Regular' })
          }
        }
      },
      mononoki = {
        font_size = 10.3,
        font = font 'mononoki Nerd Font',
        cell_width = 0.87,
        line_height = 1,
        font_rules = {
          {
            font = font('mononoki Nerd Font', { italic = false, weight = 'Bold' })
          }
        }
      },
      fira = {
        font_size = 9.4,
        font = wezterm.font 'FiraCode Nerd Font',
        line_height = 1,
        cell_width = 0.83,
        font_rules = {
          {
            font = wezterm.font('FiraCode Nerd Font', { italic = false, weight = 'Medium' })
          }
        }
      },
      hack = {
        font_size = 10.2,
        font = font 'Hack Nerd Font',
        line_height = 1,
        font_rules = {
          {
            font = wezterm.font('Hack Nerd Font', { italic = false, weight = 'Regular' })
          }
        }
      },
    }).jet_brains
    
    -- UTILS --
    
    local merge = function(list)
      local result = list[1]
    
      for i = 2, #list do
        for key, value in pairs(list[i]) do
          result[key] = value
        end
      end
    
      return result
    end
    
    -- EVENTS --
    
    wezterm.on('gui-startup', function(cmd)
      local _, _, window = wezterm.mux.spawn_window(cmd or {})
      window:gui_window():maximize()
    end)
    
    -- THEME --
    
    local colors = {
      foreground = "#787C99",
      background = "#202837",
      cursor_bg = "#ffcc66",
      cursor_border = "#ffcc66",
      cursor_fg = "#404060",
      selection_fg = "#333355",
      selection_bg = "#787c99",
      scrollbar_thumb = "#222222",
      compose_cursor = "orange",
      ansi = {
        '#404060',
        '#F7768E',
        '#9CC4B2',
        '#88C0D0',
        '#6e88a6',
        '#9398cf',
        '#c8ae9d',
        '#E5E9F0',
      },
      brights = {
        '#9CC4B2',
        '#F7768E',
        '#9CC4B2',
        '#ffcc66',
        '#6e88a6',
        '#9398cf',
        '#c8ae9d',
        '#ACB0D0',
      },
    }
    
    local padding = {
      left = 0,
      right = 0,
      top = 0,
      bottom = 0,
    }
    
    -- RESULT --
    
    local config = {
      colors = colors,
      window_padding = padding,
      enable_tab_bar = false,
      scrollback_lines = 10000,
      cursor_blink_rate = 700,
      max_fps = 60,
      animation_fps = 30,
      window_background_opacity = 0.93,
      enable_kitty_graphics = true,
      default_cursor_style = 'BlinkingBlock',
      freetype_load_target = 'HorizontalLcd',
    }
    
    return merge {
      config,
      font_config,
    }
    

    Expected Behavior

    No response

    Logs

    No response

    Anything else?

    No response

    bug 
    opened by kaiphat 4
Releases(20221119-145034-49b9839f)
Distributed compute platform implemented in Rust, and powered by Apache Arrow.

Ballista: Distributed Compute Platform Overview Ballista is a distributed compute platform primarily implemented in Rust, powered by Apache Arrow. It

Ballista 2.3k Jan 3, 2023
Cross-platform tool to update DNS such as Gandi.net with your dynamic IP address

GDU | Generic DNS Update A cross-platform tool to update DNS zonefiles (such as Gandi.net) when you have a dynamic public IP address. It's a DynDNS or

Damien Lecan 10 Jan 20, 2022
Bindings for Binomial LLC's basis-universal Supercompressed GPU Texture Codec

basis-universal-rs Bindings for Binomial LLC's basis-universal Supercompressed GPU Texture Codec basis-universal functionality can be grouped into two

Philip Degarmo 27 Dec 3, 2022
A new kind of terminal

notty - not a typewriter notty is a virtual terminal like xterm, gnome-vte, sh, or rxvt. Unlike these programs, notty is not intended to emulate a DEC

Saoirse Shipwreckt 2.2k Jan 6, 2023
A terminal IRC client

tiny - Yet another terminal IRC client tiny is an IRC client written in Rust. Features Clean UI: consecutive join/part/quit messages are shown in a si

Ömer Sinan Ağacan 812 Dec 20, 2022
A (self hosted) pastebin for easily sharing text right from the terminal

termpad termpad allows you to easily host a pastebin server for saving and viewing text right from the terminal, or the browser. Client Usage Assuming

Spyros Roum 28 Aug 29, 2022
A genetic algorithm for bechmark problems, written to learn Rust.

Genetic Algorithm A genetic algorithm in Rust for the following benchmark problems: Ackley Griewangk Rastrigin Rosenbrock Schwefel Sphere Usage: Insta

Andrew Schwartzmeyer 73 Dec 25, 2022
interative assembly shell written in rust

Overview this project is inspired by https://github.com/poppycompass/asmshell Preview Build from source git clone https://github.com/keystone-engine/k

Xargin 236 Dec 23, 2022
Drill is a HTTP load testing application written in Rust inspired by Ansible syntax

Drill Drill is a HTTP load testing application written in Rust. The main goal for this project is to build a really lightweight tool as alternative to

Ferran Basora 1.5k Dec 28, 2022
An experimental HTTP load testing application written in Rust.

Herd Herd was a small side project in building a HTTP load testing application in Rust with a main focus on being easy to use and low on OS level depe

Jacob Clark 100 Dec 27, 2022
A purpose-built proxy for the Linkerd service mesh. Written in Rust.

This repo contains the transparent proxy component of Linkerd2. While the Linkerd2 proxy is heavily influenced by the Linkerd 1.X proxy, it comprises

Linkerd 1.7k Jan 7, 2023
Full fake REST API generator written with Rust

Weld Full fake REST API generator. This project is heavily inspired by json-server, written with rust. Synopsis Our first aim is to generate a fake ap

Seray Uzgur 243 Dec 31, 2022
pastebin written in pure rust. A rewrite of ptpb/pb.

rspb rust fork of ptpb/pb TL;DR Create a new paste from the output of cmd: cmd | curl -F c=@- https://pb.mgt.moe/ Usage Creating pastes > echo hi | c

mgt 39 Jan 4, 2023
A Rust serverless function to retrieve and relay a playlist for Twitch livestreams/VODs.

City17 A Rust serverless function to retrieve and relay a playlist for Twitch livestreams/VODs. By running this in specific countries and using a brow

Malloc Voidstar 5 Dec 15, 2021
Userspace WireGuard® Implementation in Rust

BoringTun BoringTun is an implementation of the WireGuard® protocol designed for portability and speed. BoringTun is successfully deployed on millions

Cloudflare 4.8k Jan 8, 2023
A fast data collector in Rust

Flowgger is a fast, simple and lightweight data collector written in Rust. It reads log entries over a given protocol, extracts them, decodes them usi

Amazon Web Services - Labs 739 Jan 7, 2023
kytan: High Performance Peer-to-Peer VPN in Rust

kytan: High Performance Peer-to-Peer VPN kytan is a high performance peer to peer VPN written in Rust. The goal is to to minimize the hassle of config

Chang Lan 368 Dec 31, 2022
The LibreTranslate API for Rust.

libretranslate-rs A LibreTranslate API for Rust. libretranslate = "0.2.4" libretranslate allows you to use open source machine translation in your pr

Grant Handy 51 Jan 5, 2023
Yet another pager in Rust

rust-pager Yet another pager in Rust Features Vim like keybindings Search substring Mouse wheel support Install cargo install rust-pager Usage <comman

null 19 Dec 7, 2022