alacritty / copypasta

Cross-platform Rust system clipboard library

Alacritty - A fast, cross-platform, OpenGL terminal emulator

About

Alacritty is a modern terminal emulator that comes with sensible defaults, but allows for extensive configuration. By integrating with other applications, rather than reimplementing their functionality, it manages to provide a flexible set of features with high performance. The supported platforms currently consist of BSD, Linux, macOS and Windows.

The software is considered to be at a beta level of readiness; there are a few missing features and bugs to be fixed, but it is already used by many as a daily driver.

Precompiled binaries are available from the GitHub releases page.

Join #alacritty on libera.chat if you have questions or looking for a quick help.

Features

You can find an overview over the features available in Alacritty here.

Further information

• Announcing Alacritty, a GPU-Accelerated Terminal Emulator January 6, 2017
• A talk about Alacritty at the Rust Meetup January 2017 January 19, 2017
• Alacritty Lands Scrollback, Publishes Benchmarks September 17, 2018

Installation

Alacritty can be installed by using various package managers on Linux, BSD, macOS and Windows.

Prebuilt binaries for macOS and Windows can also be downloaded from the GitHub releases page.

For everyone else, the detailed instructions to install Alacritty can be found here.

Requirements

• At least OpenGL ES 2.0
• [Windows] ConPTY support (Windows 10 version 1809 or higher)

Configuration

You can find the documentation for Alacritty's configuration in man 5 alacritty, or by looking at the website if you do not have the manpages installed.

Alacritty doesn't create the config file for you, but it looks for one in the following locations:

1. $XDG_CONFIG_HOME/alacritty/alacritty.toml
2. $XDG_CONFIG_HOME/alacritty.toml
3. $HOME/.config/alacritty/alacritty.toml
4. $HOME/.alacritty.toml

On Windows, the config file will be looked for in:

• %APPDATA%\alacritty\alacritty.toml

Contributing

A guideline about contributing to Alacritty can be found in the CONTRIBUTING.md file.

FAQ

Is it really the fastest terminal emulator?

Benchmarking terminal emulators is complicated. Alacritty uses vtebench to quantify terminal emulator throughput and manages to consistently score better than the competition using it. If you have found an example where this is not the case, please report a bug.

Other aspects like latency or framerate and frame consistency are more difficult to quantify. Some terminal emulators also intentionally slow down to save resources, which might be preferred by some users.

If you have doubts about Alacritty's performance or usability, the best way to quantify terminal emulators is always to test them with your specific usecases.

Why isn't feature X implemented?

Alacritty has many great features, but not every feature from every other terminal. This could be for a number of reasons, but sometimes it's just not a good fit for Alacritty. This means you won't find things like tabs or splits (which are best left to a window manager or terminal multiplexer) nor niceties like a GUI config editor.

License

Alacritty is released under the Apache License, Version 2.0.

copypasta's Issues

Improve/more specific error if TTY/CI?

the hello world example gets the following error

    Finished dev [unoptimized + debuginfo] target(s) in 0.03s
     Running `target/debug/examples/hello_world`
thread 'main' panicked at 'called `Result::unwrap()` on an `Err` value: XcbConn(ClosedParseErr)', examples/hello_world.rs:4:43
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

If you recon it's pointless, feel free to close the issue.

I'm just sharing my finding and I'm curious what you think.

Android support

Hi! I see two possible uses of this library on Android:

• By some JVM apps, through their own rust library (e.g. game engines)
• By cross-platform term apps, through Termux (e.g. jmacdonald/amp)

The latter probably can be done by simply running process 'termux-clipboard-get/set'. About the first case — there is an easy way in SDK to use the clipboard, however, it needs to be used through JNI. This crate is used by Servo among others, so I think it'll be fine to use.

Things to think about:

• Can the Termux case be covered by the JNI thing?
• How to handle different Android SDKs?
• How to test?

Feature Request: Android support via Termux.

Hi! a text editor I use on my Android tablet via Termux, uses this lib, so I am unable to copy/paste.
I was wondering if you would be kind enough to support this OS also?
The two commands are:

• termux-clipboard-set
• termux-clipboard-get

They work just like xclip but take no extra args, just whatever you want on the clipboard, kinda like pbcopy.
Thank you.

Migrate from Travis CI to github actions

Since travis discontinues its free macOS builds we should migrate to combination of sr.ht and github actions like we did in alacritty/alacritty#4387.

Copying to clipboard not working under Wayland/Hyprland

I'm using copypasta v0.10.1 and when I use the:

    let mut ctx = copypasta::ClipboardContext::new().unwrap();
    ctx.set_contents("test".to_owned()).unwrap();

It clears my copied buffer, but doesn't set it to "test".
I know that It should work because I have a clipboard manager and other applications are able to change my clipboard (i.e. https://gitlab.gnome.org/World/secrets)

Add Send + Sync + 'static bounds to the Error type

Add Send + Sync + 'static bounds to the error type, i. e. change dyn Error to dyn Error + Send + Sync + 'static.

In addition to being able to modify the clipboard and handle the error in a different thread, this change would enable interoperability with anyhow, failure and other error handling libraries.

x11_clipboard's Error type has these bounds (I have tried adding it to rust-clipboard), but I'm not sure about macos / windows / wayland. I'm happy to research it and create a PR to test all the platforms if CI tests all environments? I only have access to Linux.

Is Wayland supported by default, or is additional logic required for this?

It is unclear to me how Wayland support works.

The crate provides the wayland_clipboard module for interacting with the Wayland clipboard. The copypasta::ClipboardContext definition always provides a X11 context (on Linux) though.

So, does this mean Wayland isn't automatically supported? And does this mean that adding Wayland support requires additional logic by the implementer to determine at runtime whether to construct an X11 or a Wayland clipboard context, including figuring out the Wayland display pointer?

Add support for non-text clipboard content

Some data that goes through the clipboard is not necessarily text, one example is images. Currently copypasta uses Strings to transfer all clipboard data, which all guarantee that the data inside is valid UTF-8, and panic if it's not. This prevents users from transferring non-text data through the clipboard.

Reading the clipboard is surprisingly slow

I'm using copypasta within an egui app, and due to the nature of the immediate mode rendering I noticed that the UI shortly freezes when I read from the clipboard. A short measurement

use std::time::Instant;

use copypasta::{ClipboardContext, ClipboardProvider};

fn main() {
    let mut ctx = ClipboardContext::new().unwrap();

    let content = {
        let now = Instant::now();
        let content = ctx.get_contents().unwrap();
        let elapsed = now.elapsed().as_millis();
        println!("Time to get context: {} ms", elapsed);
        content
    };

    println!("Content: {}", content);
}

reveals that it always seems to take 50 ms. Within an egui app it would be nice to stay well below 16.6 ms to keep constant 60 fps in the UI.

Cross checking with other programming language and/or solutions indicates that reading the clipboard isn't that slow per se. For instance, here is a short benchmark in Python:

OS: Ubuntu 22.04, X11

update x11-clipboard to 0.9.2

Hi,

Could you please update the x11-clipboard dependency to the newly released v0.9.2?
See, quininer/x11-clipboard#48 for the reason

Thanks!

request to feature gate backends

I'm using this on linux and its great. but i don't actually care about wayland at all (as i use some x11 commands directly). every time i see a lot of compilation time taken by wayland dependencies, it feels really sad. can there be feature gates for separate backends ? other platforms only have single backend, so it works out fine when gated by the platform. but for linux, i think it would be useful if wayland (or maybe even x11) are feature gated to reduce compile times.

Using xcb which is unmaintained and has multiple soundness issues

This is a great library, but it's started breaking my build because it's using a unmaintained library that has a number of vulnerabilities.

cargo audit
    Fetching advisory database from `https://github.com/RustSec/advisory-db.git`
      Loaded 278 security advisories (from /Users/billie/.cargo/advisory-db)
    Updating crates.io index
    Updating crates.io index
    Scanning Cargo.lock for vulnerabilities (48 crate dependencies)
error: Vulnerable crates found!

ID:       RUSTSEC-2021-0019
Crate:    xcb
Version:  0.9.0
Date:     2021-02-04
URL:      https://rustsec.org/advisories/RUSTSEC-2021-0019
Title:    Multiple soundness issues
Solution:  No safe upgrade is available!
Dependency tree: 
xcb 0.9.0
└── x11-clipboard 0.5.1
    └── copypasta 0.7.1

error: 1 vulnerability found!

Please document Wayland usage

The main selling feature for this crate is its Wayland support. However, the instructions on how to actually use it under Wayland are unclear. From #27 I know that it still defaults to XOrg on Linux and some manual intervention is required.

I think some kind of new() method that simply builds a matching clipboard provider for the current system would really help here too.

copypasta: Fix build on ios

Having the clipboard be a noop would be good enough for my purposes. The build currently detects it as a unix and tries to link against x11 libraries.

docs bug

If you don't use copypasta::{ClipboardContext, ClipboardProvider} your example is missing the trait in scope in a lot of situations I think? This is what I had to do with my own use of this library.

HTH! Thank you for the great work.

Element not found on Win11

use copypasta::{ClipboardContext, ClipboardProvider};

fn main() {
    let mut ctx = ClipboardContext::new().unwrap();
    let content = ctx.get_contents().unwrap();
    println!("{content}");
}

Results in:

thread 'main' panicked at 'called `Result::unwrap()` on an `Err` value: Os { code: 1168, kind: Uncategorized, message: "Element not found." }', src\main.rs:5:38
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
error: process didn't exit successfully: `target\release\rs-type-clipboard.exe` (exit code: 101)

edit; Cargo.toml:

[package]
name = "rs-type-clipboard"
version = "0.1.0"
edition = "2021"

[dependencies]
copypasta = "0.8.2"

edit; It works when first doing set_content but I'm not interested in using only what I set in the code itself, I'm interested in the Windows clipboard from outside of the application I'm writing.

Proposal to change the x11 clipboard implementation

Hi,

I've been working a bit with x11rb for interfacing with x11 without any c-library dependencies.
Currently x11-clipboard uses the xcb-crate which is rust bindings for libxcb. x11rb is like libxcb implemented in rust and avoids the c-library dependencies as well as unsoundness issues. I'm considering creating a fork of x11-clipboard which uses that implementation instead.

If I did, would you be okay with using that instead in this crate?

set_contents doesn't work on x11

hello pasta people! <3

get_contents works fine, but set_contents just results in an empty clipboard

i've tried searching and found this: https://stackoverflow.com/questions/73190617
which describes it exactly, only difference is that for me, even using get_contents afterwards still doesn't work

the rust-clipboard crate works as expected, so i looked and can only see the absence of the Box<Error> from the return result, but i don't know if that's the cause
https://github.com/aweinstock314/rust-clipboard/blob/master/src/x11_clipboard.rs#L66

Setting clipboard on Fedora 33 / GNOME / Wayland does not work

I have this simple code from example:

use copypasta::{ClipboardContext, ClipboardProvider};

fn main() {
    let mut ctx = ClipboardContext::new().unwrap();
    println!("{:?}", ctx.get_contents());
    ctx.set_contents("some string".to_owned()).unwrap();
}

Running it twice shows:

❯ cargo run
    Finished dev [unoptimized + debuginfo] target(s) in 0.05s
     Running `target/debug/foo`
Ok("master")

foo on  master [?] is 📦 v0.1.0 via 🦀 v1.43.1 
❯ cargo run
    Finished dev [unoptimized + debuginfo] target(s) in 0.04s
     Running `target/debug/foo`
Ok("")

foo on  master [?] is 📦 v0.1.0 via 🦀 v1.43.1 

so it seems it sets buffer to empty instead of some string. I am not sure how to debug this, so let me know and I will happily provide as much details as needed.

Clipboard not working on wayland

I have added copypasta to my project and tried to use the example to insert something into the clipboard, but its not working.
No error given, it just doesn't happen.
I am on latest Fedora with wayland, but it seems its picking x11 clipboard for some reason.
I even tried to explicitely tell the wayland feature in toml, but it didn't help.

copypasta = { version = "0.10.0", features = ["wayland"] }

Any ideas?

let mut ctx = ClipboardContext::new().unwrap();
ctx.set_contents(code.to_owned()).unwrap();

Edit:
I have tried the complete code and added also this part:

let content = ctx.get_contents().unwrap();
println!("Clipboard content: {}", content);

And now it works. So I have to read the clipboard after changing it - then it works...

Clipboard is cleared when the process exits on Linux

Any plans to address this inherited persistence issue?
aweinstock314/rust-clipboard#61

Below code to reproduce

extern crate copypasta;

use copypasta::ClipboardContext;
use copypasta::ClipboardProvider;

fn main() {
    let mut ctx = ClipboardContext::new().unwrap();

    ctx.set_contents("Test".to_owned()).unwrap();

    dbg!(ctx.get_contents().unwrap());  // CONTAINS "Test"
}
// dbg!(ctx.get_contents().unwrap(); CONTAINS "";

`set_contents` not working on Ubuntu 22.04?

Hi,

I have a machine running Ubuntu 22.04 and set_contents does not seem to be working? It doesn't return an error and it seems to set the clipboard to an empty string. I have however found that if I call get_contents right afterwards it does work properly?

Please update smithay-clipboard to 0.7.1 to fix a bug in WSL2

The new version fixes this bug: Smithay/smithay-clipboard#52

I have got the same bug with alacritty-0.13.1 in WSL2.

clipboard-win dependency is outdated

Currently this crate depends on clipboard-win v3 but the version is quite old. clipboard-win v4 was released 3 years ago and the latest version v4.5.0 was released 11 months ago. The implementation would be stable.

https://crates.io/crates/clipboard-win/versions

I want to use more recent version of clipboard-win through copypasta crate. Specifically, clipboard-win v3 does not allow setting an empty string to clipboard. And the limitation was removed at clipboard-win v4.4.0.

copypasta does not build for visionos

Copypasta does not build for the recently added aarch64-apple-visionos target.
Running:

RUSTFLAGS="-Awarnings" cargo +nightly build --target aarch64-apple-visionos -Zbuild-std

produces a bunch of errors that are quite easy to fix, mostly due to missing cfg cases for visionos.

`set_contents` works unexpectedly?

I'm wondering why these two examples behave diffrently

extern crate copypasta;

use copypasta::ClipboardContext;
use copypasta::ClipboardProvider;

fn fails() {
    let mut ctx = ClipboardContext::new().unwrap();
    let mut previous = String::new();
    loop {
        let current = ctx.get_contents().unwrap();
        dbg!(&current);

        if current != previous {
            ctx.set_contents(current.clone()).unwrap();
            previous = current;
            dbg!(&previous);
        }

        std::thread::sleep(std::time::Duration::from_millis(100));
    }
}

fn works() {
    let mut ctx = ClipboardContext::new().unwrap();
    let mut previous = String::new();
    loop {
        let current = ctx.get_contents().unwrap();
        dbg!(&current);

        if true {
            ctx.set_contents(current.clone()).unwrap();
            previous = current;
            dbg!(&previous);
        }

        std::thread::sleep(std::time::Duration::from_millis(100));
    }
}

fn main() {
    fails();
    //works();
}

Actions to reproduce

1. run the code

cd /tmp
git clone https://github.com/xliiv/copypasta.git --branch loop-error --single-branch
cd copypasta/
cargo run --example echo

2. select some text in some window e.g. Firefox
3. press ctrl+c
4. focus some edit widget, e.g. Firefox's address bar
5. press ctrl+v

I expect the copied text will show up in the widget (see step 4) but it doesn't.

Am i missing something?

OS: Linux, Wayland

Paste functionality uses old, cached values

I use Alacritty on Wayland, specifically with the Sway window manager. Alacritty uses this underlying library to handle text copying and pasting. When pasting text from the clipboard with Alacritty (using default Ctrl+Shift+V key binding) the pasted text will actually be older, previously copied text. Pasting again will eventually paste the most recently copied text, however it may take several repetitions before it "bubbles" up.

This only seems to occur on a very long running Alacritty instance. For example, I have several Alacritty instances open, and the recently started processes do not exhibit this issue, but a very old instance does exhibit this behavior and continues to do so.

Steps to reproduce:

1. Start Alacritty and use the same instance over the course of many days.
2. Copy text to clipboard using any means (other applications that have access to Wayland clipboard or Alacritty itself)
3. Paste text using Alacritty. The pasted text will incorrectly be previously copied text. Subsequent pastes will eventually paste the most recently copied text.

Example:

• Copy "foo" from text using some application.
• In Alacritty at a shell, execute a Paste hot key (Ctrl+Shift+V by default)
• "foo" should be output to the screen. If it isn't, it may be "queued up". Keep retrying the Paste operation until "foo" is outputted.
• Copy "bar" from text using some application.
• Repeat Paste hot key an arbitrary amount of times. Alacritty will output "foo" each time until eventually "bar" is output

Note: In the above, "some application" can be anything that is able to copy text to the Wayland clipboard. The above example occurs for both copying using Alacritty's highlighting and Ctrl+Shift+C, or copying text in Firefox.

Here is a Youtube video I created which demonstrates the issue:

function or associated item not found in `dyn ClipboardProvider`

error[E0599]: no function or associated item named `new` found for trait object `dyn ClipboardProvider` in the current scope
 --> src/clipboard.rs:7:56
  |
7 |     let mut ctx: ClipboardContext = ClipboardProvider::new().unwrap();
  |                                                        ^^^ function or associated item not found in `dyn ClipboardProvider`

so this doesn't work

my pc is

niedzwiedz@niedzwiedz-pc
------------------------
OS: Manjaro Linux x86_64
Kernel: 5.10.7-3-MANJARO
Uptime: 2 days, 19 hours, 26 mins
Packages: 1875 (pacman), 13 (flatpak)
Shell: zsh 5.8
Resolution: 1080x1920, 1920x1080
WM: awesome
Theme: Adapta-Nokto-Eta-Maia [GTK2/3]
Icons: Papirus-Adapta-Nokto-Maia [GTK2/3]
Terminal: alacritty
CPU: AMD Ryzen 9 3900X (24) @ 3.800GHz
GPU: NVIDIA GeForce GTX 1080
Memory: 9786MiB / 32081MiB

Segfault in smithay-clipboard -- dep needs to be bumped to 0.6.2 or later

After a system update, I ran into segfaults from smithay-clipboard:

smithay-clipboa[11623]: segfault at 56225dbf8136 ip 00007fe75d34cd10 sp 00007fe74de0b598 error 4 in libwayland-client.so.0.3.0[7fe75d348000+6000]

The relevant segfault has been fixed upstream and the v0.6.2 release appears to include a patch for it. After that it took me a bit of digging around to figure out what pulls it into my system, but eventually I realised it's from alacritty via copypasta.

Should be straightforward to bump the dependency as far as I can tell. Bumping it, doing a release of copypasta & bumping the copypasta dep in alacritty so it's ready for the next alacritty release would be appreciated!

Listening for changes MacOS

From what I can tell there isnt an existing way to listen for changes right now. Would that be possible to add?
Is there a good or recommended workaround currently? I could go the route of polling, and track the last know new item and compare.

What would be the best way to go about continually checking for new items being added in the background?

SIGSEGV on MacOS

I'm seeing crashes on MacOS Catalina (10.15.3) with Rust 1.43.1. This happens in the original clipboard crate as well, but since that seems unmaintained I'm reporting it here.

You can reproduce the crash by running cargo test in my fork.

You may need to run it a few times, but you will get different errors such as:

failing-517cc89e9cb2a459(35714,0x70000ebe5000) malloc: *** error for object 0x7f8eb170a6e0: pointer being freed was not allocated
failing-517cc89e9cb2a459(35714,0x70000ebe5000) malloc: *** set a breakpoint in malloc_error_break to debug

Or:

failing-517cc89e9cb2a459(35969,0x700000ae7000) malloc: Double free of object 0x7fe935c10a50
failing-517cc89e9cb2a459(35969,0x700000ae7000) malloc: *** set a breakpoint in malloc_error_break to debug

I'm unfortunately no MacOS developer so I have no idea what causes this, but it only seems to occur when I'm accessing the clipboard from both my test code and my regular (under test) code, like in some_other_fn in the code below. Moving the ClipboardContext to a shared static using something like lazy_static! does not help.

The test is fairly simple:

use copypasta::{ClipboardContext, ClipboardProvider};

fn some_other_fn() {
    let mut ctx = ClipboardContext::new().unwrap();
    ctx.get_contents().unwrap();
}

#[cfg(test)]
mod tests {
    use super::*;

    fn clear_clipboard() {
        let mut clipboard: ClipboardContext = ClipboardContext::new().unwrap();
        clipboard.set_contents("".into()).unwrap();
    }

    #[test]
    fn foo() {
        clear_clipboard();

        let mut ctx = ClipboardContext::new().unwrap();
        ctx.set_contents("Dummy".into()).unwrap();
        ctx.get_contents().unwrap();

        some_other_fn();
    }

    #[test]
    fn bar() {
        clear_clipboard();

        let mut ctx = ClipboardContext::new().unwrap();
        ctx.set_contents("Dummy".into()).unwrap();
        ctx.get_contents().unwrap();

        some_other_fn();
    }
}