Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add support for dim foreground color #1448

Closed
dsifford opened this issue Jul 19, 2018 · 2 comments · Fixed by #1452
Closed

Add support for dim foreground color #1448

dsifford opened this issue Jul 19, 2018 · 2 comments · Fixed by #1452

Comments

@dsifford
Copy link

Which operating system does the issue occur on? ==> Arch Linux

If on linux, are you using X11 or Wayland? ==> X11

Hello there.

To my knowledge, it appears that alacritty does not support the dim escape sequence (and associated color setting in alacritty.yml) for the foreground color.

Could this be added? Or if it exists, how do I adjust?

Thanks in advance.

@dsifford
Copy link
Author

dsifford commented Jul 19, 2018

Example: This works in xterm (and others), but not alacritty:

echo -e "Normal \e[2mDim \e[22mNormal"

enizor added a commit to enizor/alacritty that referenced this issue Jul 20, 2018
Optional color for the dim foreground (`\e[2m;`)
Defaults to 2/3 of the foreground color. (same as other colors)
Fixes alacritty#1448
@chrisduerr
Copy link
Member

Just to clarify here: Dim colors in general work, it's only the dim (bright) foreground color that does not.

chrisduerr pushed a commit that referenced this issue Jul 23, 2018
Add optional color for the dim foreground (`\e[2m;`)
Defaults to 2/3 of the foreground color. (same as other colors).

If a bright color is dimmed, it's displayed as the normal color. The
exception for this is when the bright foreground is dimmed when no
bright foreground color is set. In that case it's treated as a normal
foreground color and dimmed to DimForeground.

To minimize the surprise for the user, the bright and dim colors have
been completely removed from the default configuration file.
Some documentation has also been added to make it clear to users what
these options can be used for.

This fixes #1448.
chrisduerr added a commit that referenced this issue Jul 28, 2018
* Allow disabling DPI scaling

This makes it possible to disable DPI scaling completely, instead the
the display pixel ration will always be fixed to 1.0.

By default nothing has changed and DPI is still enabled, this just seems
like a better way than running `WINIT_HIDPI_FACTOR=1.0 alacritty` every
time the user wants to start alacritty.

It would be possible to allow specifying any DPR, however I've decided
against this since I'd assume it's a very rare usecase. It's also still
possible to make use of `WINIT_HIDPI_FACTOR` to do this on X11.

Currently this is not updated at runtime using the live config update,
there is not really much of a technical limitation why this woudn't be
possible, however a solution for that issue should be first added in
#1346, once a system is established for changing DPI at
runtime, porting that functionality to this PR should be simple.

* Add working --class and --title CLI parameters

* Reduce Increase-/DecreaseFontSize step to 0.5

Until now the Increase-/DecreaseFontSize keybinds hand a step size of 1.0. Since the font size however is multiplied by two to allow more granular font size control, this lead to the bindings skipping one font size (incrementing/decrementing by +-2).

To fix this the step size of the Increase-/DecreaseFontSize bindings has been reduced to the minimum step size that exists with the current font configuration (0.5). This should allow users to increment and decrement the font size by a single point instead of two.

This also adds a few tests to make sure the methods for increasing/decreasing/resetting font size work properly.

* Add Copy/Cut/Paste keys

This just adds support for the Copy/Cut/Paste keys and sets up
Copy/Paste as alternative defaults for Ctrl+Shift+C/V.

* Move to cargo clippy

Using clippy as a library has been deprecated, instead the `cargo
clippy` command should be used instead. To comply with this change
clippy has been removed from the `Cargo.toml` and is now installed with
cargo when building in CI.

This has also lead to a few new clippy issues to show up, this includes
everything in the `font` subdirectory. This has been fixed and `font`
should now be covered by clippy CI too.

This also upgrades all dependencies, as a result this fixes #1341 and
this fixes #1344.

* Override dynamic_title when --title is specified

* Change green implementation to use the macro

* Ignore mouse input if window is unfocused

* Make compilation of binary a phony target

* Add opensuse zypper install method to readme

* Fix clippy issues

* Update manpage to document all CLI options

The introduction of `--class` has added a flag to the CLI without adding
it to the manpage. This has been fixed by updating the manpage.

This also adds the default values of `--class` and `--title` to the CLI
options.

* Remove unnecessary clippy lint annotations

We moved to "cargo clippy" in 5ba34d4 and
removing the clippy lint annotations in `src/lib.rs` does not cause any additional warnings.

This also changes `cargo clippy` to use the flags required for checking integration tests.

* Enable clippy in font/copypasta crates

Enabled clippy in the sub-crates font and copypasta. All issues
that were discovered by this change have also been fixed.

* Remove outdated comment about NixOS

* Replace debug asserts with static_assertions

To check that transmutes will work correctly without having to rely on
error-prone runtime checking, the `static_assertions` crate has been
introduced. This allows comparing the size of types at compile time,
preventing potentially silent breakage.

This fixes #1417.

* Add `cargo deb` build instructions

Updated the `Cargo.toml` file and added a `package.metadata.deb`
subsection to define how to build a debian "deb" install file using
`cargo deb`. This will allow debian/ubuntu users to install `alacritty`
using their system's package manager. It also will make it easier to
provide pre-built binaries for those systems.

Also fixed a stray debug line in the bash autocomplete script that was
writting to a tempfile.

* Add config for unfocused window cursor change

* Add support for cursor shape escape sequence

* Add bright foreground color option

It was requested in #825 that it should be possible to
add an optional bright foreground color.

This is now added to the primary colors structure and allows the user to
set a foreground color for bold normal text. This has no effect unless
the draw_bold_text_with_bright_colors option is also enabled.

If the color is not specified, the bright foreground color will fall
back to the normal foreground color.

This fixes #825.

* Fix clone URL in deb install instructions

* Fix 'cargo-deb' desktop file name

* Remove redundant dependency from deb build

* Switch from deprecated `std::env::home_dir` to `dirs::home_dir`

* Allow specifying modifiers for mouse bindings

* Send newline with NumpadEnter

* Add support for LCD-V pixel mode

* Add binding action for hiding the window

* Switch to rustup clippy component

* Add optional dim foreground color

Add optional color for the dim foreground (`\e[2m;`)
Defaults to 2/3 of the foreground color. (same as other colors).

If a bright color is dimmed, it's displayed as the normal color. The
exception for this is when the bright foreground is dimmed when no
bright foreground color is set. In that case it's treated as a normal
foreground color and dimmed to DimForeground.

To minimize the surprise for the user, the bright and dim colors have
been completely removed from the default configuration file.
Some documentation has also been added to make it clear to users what
these options can be used for.

This fixes #1448.

* Fix clippy lints and run font tests on travis

This fixes some existing clippy issues and runs the `font` tests through travis.

Testing of copypasta crate was omitted due to problens when running on headless travis-ci environment (x11 clipboard would fail).

* Ignore errors when logger can't write to output

The (e)print macro will panic when there is no output available to
write to, however in our scenario where we only log user errors to
stderr, the better choice would be to ignore when writing to stdout or
stderr is not possible.

This changes the (e)print macro to make use of `write` and ignore
any potential errors.

Since (e)println rely on (e)print, this also solves potential failuers
when calling (e)println.

With this change implemented, all of logging, (e)println and (e)print
should never fail even if the stdout/stderr is not available.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Development

Successfully merging a pull request may close this issue.

2 participants