Skip to content

Latest commit

 

History

History
77 lines (52 loc) · 3.38 KB

README.md

File metadata and controls

77 lines (52 loc) · 3.38 KB

term_size

Crates.io Crates.io license license Coverage Status Join the chat at https://gitter.im/kbknapp/term_size-rs

Linux: Build Status Windows: Build status

A Rust library to enable getting terminal sizes and dimensions

Documentation

Usage

First, add the following to your Cargo.toml:

[dependencies]
term_size = "1"

Next, add this to your crate root:

extern crate term_size;

To get the dimensions of your terminal window, simply use the following:

fn main() {
  if let Some((w, h)) = term_size::dimensions() {
    println!("Width: {}\nHeight: {}", w, h);
  } else {
    println!("Unable to get term size :(")
  }
}

License

Copyright Benjamin Sago, Kevin Knapp, and term_size contributors.

Licensed under either of

at your option. Unless you explicitly state otherwise, any contribution intentionally submitted for inclusion in the work by you, as defined in the Apache-2.0 license, shall be dual licensed as above, without any additional terms or conditions.

Contributing

  1. Fork it!
  2. Create your feature branch: git checkout -b my-new-feature
  3. Commit your changes: git commit -am 'Add some feature'
  4. Push to the branch: git push origin my-new-feature
  5. Submit a pull request :D

Minimum Version of Rust

term_size will officially support current stable Rust, minus two releases, but may work with prior releases as well. For example, current stable Rust at the time of this writing is 1.22.1, meaning term_size is guaranteed to compile with 1.20.0 and newer.

At the 1.23.0 stable release, term_size will be guaranteed to compile with 1.21.0 and newer, etc.

Upon bumping the minimum version of Rust (assuming it's within the stable-2 range), it must be clearly annotated in the CHANGELOG.md

Breaking Changes

term_size takes a similar policy to Rust and will bump the major version number upon breaking changes with only the following exceptions:

  • The breaking change is to fix a security concern
  • The breaking change is to be fixing a bug (i.e. relying on a bug as a feature)
  • The breaking change is a feature isn't used in the wild, or all users of said feature have given approval prior to the change