In Gnome Terminal I use the binding Ctrl-Shift-PageUp/Down to move the current tab relative to its neighbours. For example, Ctrl-Shift-PageUp will move the current tab to the left, unless its already the leftmost tab.

There doesn't seem to be an equivalent action documented in https://wezfurlong.org/wezterm/configuration.html.

I'm thinking something similar to ActivateTabRelative except MoveTabRelative, with an arg of 1/-1.

Roughly:

• Obtain https://github.com/rprichard/winpty/releases/download/0.4.3/winpty-0.4.3-msys2-2.7.0-x64.tar.gz
• Install the 64-bit version of msys2: https://www.msys2.org/
• copy C:\msys64\usr\bin\msys-2.0.dll alongside the winpty.dll in the extracted winpty dir
• copy wezterm.exe alongside both msys-2.0.dll and winpty.dll
• Set pty = WinPty in the wezterm.toml
• Start wezterm.exe

Currently dragging to select is clipped to the viewport. It would be nice if dragging off the top or bottom implicitly scrolled the viewport and allowed selecting more than the visible screen of text.

Currently we don't handle this at all, so we end up printing unhandled vte execute 7 to stderr.
There are varying degrees of support:

• Print bell! to stderr instead of letting it hit the unhandled case. This is lameish.
• Don't print anything to stderr at all, but do nothing. This is logically equivalent to explicitly configuring that the bell be disabled.
• Hook up an audible bell tone. This definitely should be something that we can turn off because I totally hate audible bells.
• Hook up a visual bell rendering of some kind. There are simplistic approaches of forcing the inverse video bit on, but I'd like something more tasteful and less bright. This also definitely needs an option to turn it off because I hate visual bells too, but they've always been super bright and distracting.
• Teach tabs about being in an alert state and render some kind of bell graphic in the tab UI that sticks until acknowledged in some way
• On systems that allow bouncing icons in the dock area, add configurable support for doing that
• Generate a system "toast" notification

others?

wezterm 20191124-233250-cb9fd7d-110-g8950c6c
(not sure why the date is 20191124, this is supposed to be the nightly?)

I'm glad you told me about RUST_LOG=warn because apparently I wasn't paying attention before (and I haven't been having to use the terminal due to the holidays). When It had stopped throwing toml parseing errors I thought it was working. But I don't think it is. I'm using Fira Code from here to test with.

[[font.font]]
# The font family name.  The default is "Menlo" on macOS,
# "Consolas" on Windows and "monospace" on X11 based systems.
# "Fira Code" to enjoy ligatures without buying an expensive font!
font_system = "FontKitAndFreeType"
font_dir = ["fonts"]
family = "myfont"

Without the 'family' line it throws a parsing failure error. I also tried "myfont.ttf" in family, no luck.

The output:

ERROR wezterm::font::parser > Did not locate a font match for FontAttributes { family: "myfont", bold: false, italic: false }
 ERROR wezterm::font::parser > Did not locate a font match for FontAttributes { family: "Segoe UI", bold: false, italic: false }
 ERROR wezterm::font::parser > Did not locate a font match for FontAttributes { family: "Segoe UI Emoji", bold: false, italic: false }
 ERROR wezterm::font::parser > Did not locate a font match for FontAttributes { family: "Segoe UI Symbol", bold: false, italic: false }
 ERROR term::terminalstate   > unhandled TerminalMode 25

For user error auditing purposes, here's the output of tree /f /a:

|   wezterm.exe
|   wezterm.pdb
|   wezterm.toml
|
\---fonts
        myfont.ttf

and here's myfont.ttf showing Fira Code Regular:

Is it a build problem?

Yes.

$ rustup show
command not found.

I do not use rustup on my Arch Linux.

Did something not work the way you expected?

The build system can't be instructed to use system libraries of freetype, libpng and zlib, which is unexpected.

By making use of system libraries, I have the following benefits:

• much less download time (I'm in a sad place where the speed of cloning from GitHub is about 15KB/s)
• less build time
• receives updates from the distribution

What did you try?

Read the source to see if I can set any environment variables to achieve this.

Originally reported in markbt/streampager#1

The TL;DR is that macOS is a bit of a disaster when it comes to poll(2) and we need to use select(2) instead on that platform.

In particular, the tab related hotkeys don't work well on Windows systems because the use of the windows key as the modifier collides with higher precedence defaults in windows.

Suggestions:

• WIN-\ for SpawnTab. Rationale: CTRL-T would be an obvious choice, but would prevent sending that in eg: vim, which is bad. \ is close to the [ and ] in qwerty keyboards and those keys have a default binding for navigating tabs
• CTRL-0 for ActivateTab. Don't have a solution in mind for this yet, but: Win-0 (which would take you to the first tab) doesn't function on windows. I'm not sure if we should use CTRL-0 through CTRL-9 for this in case it collides with something useful

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!

Did something not work the way you expected?

Using the config:

scrollback_lines = 10000
default_cursor_style = "BlinkingUnderline"

there's a speckled background to the window which changes when its resized.

I originally also had enable_scroll_bar = true, but that wasn't necessary to repro.

What did you try?

1. Started wezterm with no (default) config.
2. Created config as above
3. Ctrl-Shift-R to reload config

What did you expect to happen?

Blinking underline cursor (yes, got that), large scrollback (yep), no speckles (nope)

What actually happened?

Speckles (a bit hard to see unless at 1:1 or magnified).

Is it a build problem?

No

Did something not work the way you expected?

Selecting text with the mouse seems to have a slow animation applied instead of being instant.
Running on Windows 10 Pro

What did you try?

What did you expect to happen?

Instant text selection

What actually happened?

Slow and animated text selection

Once #5 is done it would be good to evaluate this. The idea is that the user should only need to specify the base font and we'll auto-gen appropriate rules, because this sort of thing is a bit too boiler-platey and would be great to do automatically for a great first run experience:

font_size = 10
font = { fontconfig_pattern = "Operator Mono SSm Lig Medium" }

[[font_rules]]
italic = true
font = { fontconfig_pattern = "Operator Mono SSm Lig Medium:style=Italic" }

[[font_rules]]
italic = true
intensity = "Bold"
font = { fontconfig_pattern = "Operator Mono SSm Lig:style=Italic:weight=bold" }

[[font_rules]]
intensity = "Bold"
font = { fontconfig_pattern = "Operator Mono SSm Lig:style=Italic:weight=bold" }

[[font_rules]]
intensity = "Half"
font = { fontconfig_pattern = "Operator Mono SSm Lig Light" }

Without any line number being reported, TOML parsing errors are difficult to debug. I think it would be good to try to ignore a line that failed and continue parsing, and then afterward, list all line numbers that failed. If this makes wezterm.exe unable to launch, then it should still launch, but with -n.

Lastly, I think the TOML parse errors should be listed within wezterm.exe itself, because RUST_LOG=warn only works when it's launched from a CLI. Actually printing it in the console would be the simplest method, but that could lead to unexpected consequences. Maybe a notification that tells them to use a certain command to see the errors? (Ideally the user would be able to just click on the notification but experience tells me you should never fully rely on a DE-provided notification system.)

Wow, I've been looking for something like this for quite some time. I'd really like to use this on a thumbstick so I can use it instead of command prompt, only problem is, I'd have to put a config file on the computer I'm working on.

Could you make wezterm check its own directory for its toml file before it checks the $HOME locations? (After all, on the off-chance that someone else is using it as well, I'd want my own configuration to take priority.)

Initially from #73 (comment)

While this has already been implemented on Windows per my initial request, @wez has expressed interest in making the font loader more flexible for all platforms and asked me to open an issue.

The Windows implementation is here 1e9d357 and consists of using the following configuration:

font_system = "FontKitAndFreeType"
font_dir = ["fonts"]

This expands into a relative path and loads in a font from the fonts subdirectory. The Linux and MacOS versions of wezterm could be afforded a similar option.

Is it a build problem?

No, build happens happens happily!
I use --release

Did something not work the way you expected?

Yes, I cannot type any of this characters:

~ ç Ç á è Ï õ Ũ ñ

As well as anything that uses "Alt Gr" mod, as /?(I'm on a notebook) ¹²³£¢¬{[}§ªº€, also, nothing on numpad works /*--+789456123.
Tabs hotkey (Super-T, Super-[, Super-]) don't works either....

What did you try?

Do what I always do, from bash, fish, tmux, vim...
Can't even cd ~/Projects

Trace:
https://drive.google.com/open?id=1rQVuDGW1Gjf-KNWJkQFzXAQ7yAQ8YIUJ

What did you expect to happen?

The same behavious as anywhere

What actually happened?

Any other thing I typed worked, It's way faster than konsole, ligatures, colors and text effects (bold) are fine too.

Others note:

I use i3, on archlinux, with latest NVIDIA drivers and libglvnd. Only setting is font = { fontconfig_pattern = "Fira Code" }

There is also this error, visible with RUST_BACKTRACE:
https://gist.github.com/PedroHLC/0e8b46a77f6925136842110bab4cdded

Did something not work the way you expected?

When running Linux command yes nothing is rendered and no way to terminate until it completes. Though time for processing is almost 2 times faster than in alacritty.

Try:

time yes | head -n 1000000

What did you expect to happen?

See flow of y and ability to terminate before head terminates.

What actually happened?

Nothing. Window doesn't repaint itself and doesn't react to Ctrl-C that usually manage to stop current command.
Window updated and gains control only after command completes.

Assumption

Looks like rendering and signals sending have lower priority than servicing PTY (or whatever is there).

This will really be CTRL - to decrease and CTRL = to increase (because actually using + is two modifiers and awkward), and CTRL 0 to reset to the configured value.

The changes required are:

• Introduce a current font size member variable to track what size we're at. The hotkeys can adjust by, say, 1pt increments. Maybe make that increment configurable? Should it be 10% instead of a fixed point size?
• Allow that to override the base font size in the configuration
• Probably just recreate the fontconfiguration when the font size is adjusted
• Recreating the font configuration also needs to blow the glyph cache and texture atlas similar to the changes in 981d939
• When the DPI scaling factor changes we should map that to a corresponding font size change

If you have long lines and resize the window smaller, most other terminals will re-wrap the text to fit the new dimensions, and remember the original boundaries when the terminal is later sized larger.

This is a UI artifacts issue that typically manifest with alt-screen apps.
If you have selected some text and then switch to a different tmux tab, the selection should be cleared, but isn't.

This page has a plan for fixing input in terminals:
http://www.leonerd.org.uk/hacks/fixterms/

Would it be possible to publish the pty module as a crate that can be reused by other programs?
Currently there is non in rust that works on all 3 major OS.

I had made similar request here alacritty/alacritty#2079

Allsorts is a new font shaper implemented purely in Rust.
It's still a bit young with some features to be fleshed out, notably:

• they mention that emoji are not yet supported, but I'm not super sure what that means
• shaping is handled by code outside of the crate at the moment, but it is possible to call a number of functions to do it yourself (see yeslogic/allsorts#8)

It may (should!) be possible to get sane font metrics from this crate, too.

Steps to reproduce:

1. Open Wezterm on Windows
2. Minimize the window.
3. Wezterm will exit

unhandled key: KeyboardInput { scancode: 68, state: Pressed, virtual_keycode: Some(F10), modifiers: ModifiersState { shift: false, ctrl: false, alt: false, logo: false } }

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!

Did something not work the way you expected?

When settings a blinking cursor mode, the cursor should always be visible after moving. The blinking is only relevant while it sits in one place in the window.

What did you try?

Set default_cursor_style = "BlinkingUnderline"

What did you expect to happen?

Cursor blinking while idle, but visible while typing.

What actually happened?

Cursor blinking is independent of motion, and so is often invisible while typing.

Instead of minimizing the window, it types an m into the terminal.

Current Behavior: Pressing <CTRL-V><CTRL-J>, WezTerm will send ^M to the terminal.

Expected Behaivor: Pressing <CTRL-V><CTRL-J>, WezTerm should send \n to the terminal.

This is the last big piece that I think is needed to unlock macOS support.
Implement the traits defined in src/font/system.rs for macOS; those include functions to enumerate fonts with fallback and to rasterize the glyph data.

It seems that the site is using some sort of ruby-based system to manage the website with markdown files, I can see how it works but I'm not familiar with its full feature set, so I'll put different ways of accomplishing my suggestions in sub-points.

• Nightly differences: Not only is this good from an end-user point of view, but it should also be good to have this all in one place for when the next stable is ready.
  • Move the nightly download to a different page and list the differences alongside it.
  • Maintain a stable and nightly version of the site. When a new stable is ready, overwrite the stable docs with the nightly docs.
  • Use some sort of diff system to generate a nightly version of the site dynamically.
• 'Smart' documentation: Be it directly or indirectly, the documentation should be linked to the build process, particularly for configuration docs.
  • Generate a warning in the build process when the nightly docs references something that no longer exists
  • Generate documentation from the code directly by putting strings in the functions that need to be documented and doing something clever with github-actions
  • Unfortunately I don't know how projects normally do this so there's probably something way more obvious I haven't thought of.
• Dark Mode: It's like staring at the sun.
  • Add a button to toggle a dark theme, like a light bulb.
  • Just make it dark for everyone because who the hell doesn't use dark mode?

Diagnosis report: https://gist.github.com/fanzeyi/3b61be83b7abb0ebf19d718b4fdb1f20

I haven't tried if I can reproduce this consistently. This happened when I unplugged my laptop from the monitor and WezTerm was running in the background while in macOS's native fullscreen mode.

If you decrease the width of the terminal and then drag to select a multi-line region, what gets copied to the buffer includes the data that was in the screen buffer prior to shrinking. We should only include what we can see in the terminal display.

We can either fix this by physically shrinking the lines on resize, or by explicitly clipping while populating the copy buffer. The former is more likely to avoid surprising future similar issues.

This is potentially related to #14

We currently just use a block cursor.
It would be great to add support for DECSCUSR sequences and configuration options for:

• Blinking block cursor CSI 1 SP q
• Steady block (we already have this) CSI 2 SP q
• Blinking underline CSI 3 SP q
• Steady underline CSI 4 SP q
• Blinking bar CSI 5 SP q
• Steady bar CSI 6 SP q

We should also support DECTCEM

It seems other terminals (Terminal.app, iTerm2, Alacritty are the ones I surveyed) by default will send ^? 0x7F DEL for backspace keys but WezTerm sends ^H 0x08 BS for backspace instead. This is causing an issue for my tmux configuration (see christoomey/vim-tmux-navigator#59).

iTerm2 made this behavior configurable:

This isn't really directly configurable with current keybindings. It seems WezTerm doesn't allow to configure a keybinding without modifier. :(

Options:

1. Making keybindings without modifier customizable (sounds kinda bizarre).
2. Adding an option to just change how backspace works. (I think it's probably better to switch to ^? as default?)

Something is up with new lines being added erroneously in this case:

$ printf 'a.out\$ printf 'a.out\t\t\tcython.platform007\t     glibc-2.23.tar.zst\t\t  Pub\n' | wc -L
85
$ echo $COLUMNS
227
$ printf 'a.out\t\t\tcython.platform007\t     glibc-2.23.tar.zst\t\t  Pub\n'
a.out                   cython.platform007           glibc-2.23.tar.zst
 Pub

Removing the tabs gives the expected output

$ printf 'a.out\t\t\tcython.platform007\t     glibc-2.23.tar.zst\t\t  Pub\n' | expand
a.out                   cython.platform007           glibc-2.23.tar.zst           Pub

Did something not work the way you expected?

When specifying [window_padding], it should be OK to leave out some sides.

What did you try?

I had this in my config:

[window_padding]
left = 5
right = 5

What did you expect to happen?

Set left and right padding, but leave top and bottom as defaults.

What actually happened?

When I reloaded the config I got the error:

 ERROR wezterm::config                    > While (re)loading configuration: Error parsing TOML from /home/jeremy/.config/wezterm/wezterm.toml: missing field `top` for key `window_padding`

Is it a build problem?

   Compiling freetype v0.1.0 (/builddir/wezterm-20191218-101156-bf35707/deps/freetype)
error: failed to run custom build command for `freetype v0.1.0 (/builddir/wezterm-20191218-101156-bf35707/deps/freetype)`

Caused by:
  process didn't exit successfully: `/builddir/wezterm-20191218-101156-bf35707/target/release/build/freetype-2592e6c7ec0b4511/build-script-build` (exit code: 1)
--- stdout
TARGET = Some("x86_64-unknown-linux-gnu")
OPT_LEVEL = Some("3")
HOST = Some("x86_64-unknown-linux-gnu")
CC_x86_64-unknown-linux-gnu = None
CC_x86_64_unknown_linux_gnu = None
HOST_CC = None
CC = Some("cc")
CFLAGS_x86_64-unknown-linux-gnu = None
CFLAGS_x86_64_unknown_linux_gnu = None
HOST_CFLAGS = None
CFLAGS = Some("-fstack-clash-protection -D_FORTIFY_SOURCE=2 -mtune=generic -O2 -pipe   ")
CRATE_CC_NO_DEFAULTS = None
DEBUG = Some("true")
CARGO_CFG_TARGET_FEATURE = Some("fxsr,sse,sse2")
running: "cc" "-O3" "-ffunction-sections" "-fdata-sections" "-fPIC" "-g" "-fno-omit-frame-pointer" "-m64" "-fstack-clash-protection" "-D_FORTIFY_SOURCE=2" "-mtune=generic" "-O2" "-pipe" "-I" "zlib" "-DHAVE_SYS_TYPES_H" "-DHAVE_STDINT_H" "-DHAVE_STDDEF_H" "-D_LARGEFILE64_SOURCE=1" "-o" "/builddir/wezterm-20191218-101156-bf35707/target/x86_64-unknown-linux-gnu/release/build/freetype-f0a65fb7ff931d73/out/zlib-build/zlib/adler32.o" "-c" "zlib/adler32.c"
cargo:warning=cc: error: zlib/adler32.c: No such file or directory
cargo:warning=cc: fatal error: no input files
cargo:warning=compilation terminated.
exit code: 1
running: "cc" "-O3" "-ffunction-sections" "-fdata-sections" "-fPIC" "-g" "-fno-omit-frame-pointer" "-m64" "-fstack-clash-protection" "-D_FORTIFY_SOURCE=2" "-mtune=generic" "-O2" "-pipe" "-I" "zlib" "-DHAVE_SYS_TYPES_H" "-DHAVE_STDINT_H" "-DHAVE_STDDEF_H" "-D_LARGEFILE64_SOURCE=1" "-o" "/builddir/wezterm-20191218-101156-bf35707/target/x86_64-unknown-linux-gnu/release/build/freetype-f0a65fb7ff931d73/out/zlib-build/zlib/compress.o" "-c" "zlib/compress.c"
cargo:warning=cc: error: zlib/compress.c: No such file or directory
cargo:warning=cc: fatal error: no input files
cargo:warning=compilation terminated.
exit code: 1

--- stderr


error occurred: Command "cc" "-O3" "-ffunction-sections" "-fdata-sections" "-fPIC" "-g" "-fno-omit-frame-pointer" "-m64" "-fstack-clash-protection" "-D_FORTIFY_SOURCE=2" "-mtune=generic" "-O2" "-pipe" "-I" "zlib" "-DHAVE_SYS_TYPES_H" "-DHAVE_STDINT_H" "-DHAVE_STDDEF_H" "-D_LARGEFILE64_SOURCE=1" "-o" "/builddir/wezterm-20191218-101156-bf35707/target/x86_64-unknown-linux-gnu/release/build/freetype-f0a65fb7ff931d73/out/zlib-build/zlib/adler32.o" "-c" "zlib/adler32.c" with args "cc" did not execute successfully (status code exit code: 1).

What did you try?

Building the project from source, using the xbps/void linux build system.

What did you expect to happen?

A successful build

What actually happened?

Build failed with log above ^

With the following config:

[[keys]]
key = "m"
mods = "CMD"
action = "SendString"
args = "\x01\x02"

WezTerm fails with the following error message:

Error parsing TOML from /Users/fanzeyi/.wezterm.toml: invalid escape character in string: `x` at line 21

If I directly put the byte sequence in the configuration file like this (in Vim, ^V^B):

[[keys]]
key = "m"
mods = "CMD"
action = "SendString"
args = "�"

It fails with the following error message:

 ERROR wezterm > Error parsing TOML from /Users/fanzeyi/.wezterm.toml: invalid character in string: `\u{2}` at line 21
145:146: syntax error: Expected “"” but found unknown token. (-2741)
Error: ErrorMessage { msg: "Error parsing TOML from /Users/fanzeyi/.wezterm.toml: invalid character in string: `\\u{2}` at line 21" }

Byte escaping support is intentionally removed from TOML standard (toml-lang/toml#173).

Proposal: Adding another action SendByte. Since TOML standard does not support byte sequence escaping, "\x01\x02" is an invalid TOML string. Instead, we could be using TOML array to specify bytes in the form of [0x1, 0x2]. The configuration would look like:

[[keys]]
key = "m"
mods = "CMD"
action = "SendByte"
args = [0x02, 0x3b]

Version: WezTerm-macos-azure-20190626-162911-cc019ce-265-g30c6ac7
OS Version: macOS Mojave 10.14.6 (18G103)

The following key binding does not work:

[[keys]]
key = "Enter"
mods = "ALT"
action = "SendString"
arg = "hello"

I also tried other modifiers (CTRL, CMD and SHIFT). None of these works :(

I deleted ~/.cargo, reran rustup to get everything installed again, and:

naga:~/projects/wezterm $ cargo run
    Updating crates.io index
    Updating git repository `https://github.com/wez/ssh2-rs`
error: checksum for `xcb-util v0.2.0` changed between lock files

this could be indicative of a few possible errors:

    * the lock file is corrupt
    * a replacement source in use (e.g., a mirror) returned a different checksum
    * the source itself may be corrupt in one way or another

unable to verify that `xcb-util v0.2.0` is the same as when the lockfile was generated

[Exit 101 in 50s]

Ubuntu 18.04, stable rust

snipped from readme "alacritty has no scrollback". That is actually no longer true. You may like to try your benchmark again with alacritty's scrollback enabled if you're curious.

To make it easier to diagnose errors when spawned entirely from a GUI context, it would be desirable to add an error log window.

• Default to not showing the window on startup (but config to make it show anyway)
• Key assignment to show the window manually
• Allow certain conditions (such as error loading config, or connectivity errors with ssh/mux) to show the window
• The window would show a capture of the most recent log messages from the standard rust logging layer

Wezterm reliable crashes when making the window so small that the VisibileRowIndex becomes -1. This is due to term/screen.rs:143 (assert!(row >= 0, "phys_row called with negative row {}", row))

What did you try?

Make the windows as small as possible (only the window bar exists).

What did you expect to happen?

no crash

What actually happened?

resize 120x19@1 -> 120x8@1
resize 120,8
Renderer resize 120,8
thread 'main' panicked at 'phys_row called with negative row -1', term\src\screen.rs:144:9
note: Run with RUST_BACKTRACE=1 environment variable to display a backtrace.
error: process didn't exit successfully: target\debug\wezterm.exe (exit code: 101)

Doesn't work when using remote desktop. Alacritty also seems to face the same issue and there is more details here alacritty/alacritty#1976

New windows terminal works so could be an issue with opengl.

My ls listing is rendering dirs as red instead of blue. Specifically:

$ ls -1 --color=always ci -d | od -Ax -tx1z -v
000000 1b 5b 30 6d 1b 5b 33 38 3b 35 3b 33 33 6d 63 69  >.[0m.[38;5;33mci<
000010 1b 5b 30 6d 0a                                   >.[0m.<
000015

What did you try?

1. Open a wezterm terminal on macOS
2. /bin/ed
3. Type i (to enter insert-mode in ed)
4. Type some characters, e.g. foo.
5. Use [backspace] to delete the typed characters.

What did you expect to happen?

Typed characters should be erased, one for each key press of the backspace button.

What actually happened?

For each key press of the backspace button on the keyboard a ^H character is printed on the screen.

(Delete key correctly backspaces characters).

Is it a build problem?

No, builds runs fine!

Did something not work the way you expected?

When a try to spawn a new window with the hotkey Super-N, process crashes.

What did you try?

Happens in any time Super-N is pressed. No other problem or activity is related.
Recording: https://drive.google.com/open?id=1yNzQzsdtTg_Cx72HIuhMSNvLYxQFWzUb

I'm using archlinux, i3, compton, nvidia dkms drivers, zen kernel. Everything is up to date.

What did you expect to happen?

Spawn a new window!

What actually happened?

It crashes with log: https://gist.github.com/PedroHLC/3921865cf9df583c25cd0c93df982e31

I've been playing around with the font settings, experimenting with the DPI sizes - taking it as low as 60 and as high as 144 and then adjusting the font size to compensate, and I even tried out the Allsorts shaper (briefly), but honestly, the text is nowhere near as sharp as the bog-standard command prompt or powershell terminal. (Also, don't use any DPI scaling, as I'm still on a 1920x1080 monitor.)

For all I know this might be a limitation of actually being able to support things like ligatures, emojis, and powerline, but just in case it's not intended or if I'm doing something wrong, I figured an issue is warranted.

When hovering over a hyperlink that was not implicitly created (eg: was created by the application using https://gist.github.com/egmontkob/eb114294efbcd5adb1944c9f3cb5feda) we should give the user an idea of where the link leads.

A tool-tip style display that shows up in the bottom left corner, similar to Chrome/Safari when hovering over an A tag would be nice. The challenge is figuring out how to make that work simply with glutin/winit.

Some color artefacts shows up around the font on certain fg / bg combinations :

Instead if i use color.rgb = o_fg_color.rgb in place of the multiply in the fragment shader, artefacts are gone.

In my case, Freetype returns a gray-level bitmap, so all color rgba are the same value (between 0 & 1.0). But it works also with a colored font.

is there a better fragment shader ?

screenshots are outputs of https://github.com/eikenb/terminal-colors/blob/master/terminal-colors with -o

https://github.com/servo/rust-harfbuzz