The warning and error messages now don't overwrite other terminal
content anymore but instead resize the terminal to make sure that text
can always be read.
Instead of just showing that there is a new error and pointing to the log,
errors will now be displayed fully in multiple lines of text, assuming that
there is enough space left in the terminal.
Explicit mouse click handling has also been added to the message bar,
which made it possible to add a simple `close` button in the form of
`[X]`.
Alacritty's log file location is now stored in the `$ALACRITTY_LOG`
environment variable which the shell inherits automatically.
Previously there were some issues with the log file only being deleted
when certain methods for closing Alacritty were used (like typing
`exit`). This has been reworked and now Ctrl+D, exit and signals should
all work properly.
Before the config is reloaded, all current messages are now dropped.
This should help with multiple terminals all getting clogged up at the
same time when the config is broken.
When one message is removed, all other duplicate messages are
automatically removed too.
The clippy tests had to be run on nightly previously since it wasn't
available with the stable compiler yet, however this had the potential
to fail a lot since not all nightly builds offer clippy.
Since clippy is now available for stable rust, moving clippy to a stable
build should make sure that the failure rate of the CI job is cut down
to a minimum.
This fixes https://github.com/jwilm/alacritty/issues/2007.
The general style for errors, warnings and info messages is to start
with a capitalized letter and end without a period. The main exception
is when dealing with nouns that are clearer with special case handling,
e.g. "macOS failed to work" or "ioctl is borked".
To make sure that all error and information reporting to the user is
unified, all instances of `print!`, `eprint!`, `println!` and
`eprintln!` have been removed and replaced by logging.
When `RUST_LOG` is not specified, the default Alacritty logger now also
prints to both the stderr and a log file. The log file is only created
when a message is written to it and its name is printed to stdout the
first time it is used.
Whenever a warning or an error has been written to the log file/stderr,
a message is now displayed in Alacritty which points to the log file
where the full error is documented.
The message is cleared whenever the screen is cleared using either the
`clear` command or the `Ctrl+L` key binding.
To make sure that log files created by root don't prevent normal users
from interacting with them, the Alacritty log file is `/tmp/Alacritty-$PID.log`.
Since it's still possible that the log file can't be created, the UI
error/warning message now informs the user if the message was only
written to stderr. The reason why it couldn't be created is then printed
to stderr.
To make sure the deletion of the log file at runtime doesn't create any
issues, the file is re-created if a write is attempted without the file
being present.
To help with debugging Alacritty issues, a timestamp and the error
level are printed in all log messages.
All log messages now follow this format:
[YYYY-MM-DD HH:MM] [LEVEL] Message
Since it's not unusual to spawn a lot of different terminal emulators
without restarting, Alacritty can create a ton of different log files.
To combat this problem, logfiles are removed by default after
Alacritty has been closed. If the user wants to persist the log of a
single session, the `--persistent_logging` option can be used. For
persisting all log files, the `persistent_logging` option can be set in
the configuration file
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.
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.
For some reason, log 0.4 requires that we explicitly set the log level
with log::set_max_level or it defaults to Off. The documentation
isn't clear but suggests we must do this in addition to doing the
filtration ourselves in the Log impl.
Unwrapping inside the config file parsing can lead to some issues that
prevent us from falling back to a default configuration file.
One instance of that issue was mentioned in #1135.
Now all instances of `unwrap()` have been removed and replaced with
proper error handling. This will make the config more robust and
prevents live reload from silently breaking while alacritty is running.
This also fixes a few currently existing clippy issues.
Clippy added an additonal lint which complains about `MyStruct { field:
field }`.
These issues have been fixed, except for some false-positives and issues
in external macros which will probably be fixed with future updates (rust-lang-nursery/bitflags#149)
Updated the version of some dependencies.
This also changes to a new clippy version so clippy can work with the latest nightly compiler again. Some issues created by new lints have been fixed.
Because there are so many clippy warnings in the current codebase,
this commit removes '#![cfg_attr(feature = "clippy", deny(clippy))]',
to make it easier to fix warnings incrementally.
The logger implementation will now only show items from Alacritty.
Additionally, the module info is omitted from the log output. If the
origin of a log item must be found, it can easily be grepped for.
