wez / wezterm

A GPU-accelerated cross-platform terminal emulator and multiplexer written by @wez and implemented in Rust
https://wezfurlong.org/wezterm/
Other
16.56k stars 742 forks source link

Hex colour #XYZ expands to #X0Y0Z0 (XParseColor style), and not #XXYYZZ (web style) #1734

Open jgcodes2020 opened 2 years ago

jgcodes2020 commented 2 years ago

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

I first observed this bug using neofetch, while copying my GNOME Terminal color scheme to WezTerm. In WezTerm, the color bright red (configured to #F55) yields this: image This is the same colour in GNOME Terminal: image

If you look closely, you'll notice that the colour in GNOME Terminal is a bit brighter.

To Reproduce

Using my config file, run the following:

echo -e '\033[91mHello, world!\033[0m'

Configuration

local wezterm = require 'wezterm'

local pwd = select(2, wezterm.run_child_process({"pwd", "-L"}))

wezterm.log_info('Starting wezterm at '..pwd)
return {
  enable_wayland = true,
  window_decorations = "TITLE | RESIZE",
  -- Font
  font = wezterm.font("Ubuntu Mono"),
  font_size = 13,
  -- Misc stuff
  default_gui_startup_args = {"start", "--cwd", pwd},
  enable_scroll_bar = true,
  -- Color schemes
  color_scheme = 'Neat and Simple',
  color_schemes = {
    ['Neat and Simple'] = {
      -- BG/FG
      background = '#1B1726',
      foreground = '#D0CFCC',

      scrollbar_thumb = '#888',

      ansi =    {'#000', '#A00', '#0A0', '#C80', '#00A', '#A0A', '#0AA', '#AAA'},
      brights = {'#555', '#A55', '#5A5', '#FF5', '#55F', '#F5F', '#5FF', '#FFF'}
    }
  }
} 

Expected Behavior

Wezterm takes #F55 to mean #F05050, when other terminals (and web browsers) will use #FF5555.

Logs

18:26:48.727 INFO config::lua > lua: Starting wezterm at /home/jacky

Anything else?

No response

wez commented 2 years ago

It's not actually a bug; the parsing/interpretation is compatible with https://linux.die.net/man/3/xparsecolor which explicitly defines the behavior this way.

We're compatible with xparsecolor so that we match xterm's behavior when processing true color escapes.

jgcodes2020 commented 2 years ago

Closing this as "working as intended".

wez commented 2 years ago

Needs docs