| Age | Commit message (Collapse) | Author |
|---|
|
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.
|
|
|
|
The logging macros should be used instead.
|
|
Resolves #23
Resolves #144
|
|
All of the changes in this commit are due to clippy lints.
|
|
Adds a wrapper for the glutin::Window which provides strongly typed
APIs and more convenient interfaces. Moves some gl calls into the
opengl-based renderer.
The point of most of the changes here is to clean up main().
|
|
Also adds a feature `err-println` for enabling `err_println!` printing.
|
|
|
|
Configuration may now be specified in either `$HOME/.alacritty.yml` or
`$HOME/.config/alacritty.yml`. See `alacritty.yml` in the repository
root for an example.
When a configuration file cannot be located, a default configuration is
used.
|
|
|
|
This is the initial terminal stream parsing implementation for
Alacritty. There are currently several TODOs, FIXMEs, and unimplemented!
things scattered about still, but what's here is good enough to
correctly parse my zsh startup.
The `Parser` implementation is largely based on the suck-less _simple
terminal_ parser. Because this is Rust and Rust has a fantastic type
system, some improvements are possible. First, `Parser` is a struct, and
its data is stored internally instead of statically. Second, there's no
terminal updates hard-coded into the parser. Instead, `Parser` is
generic over a `Handler` type which has methods for all of the actions
supported by the parser. Because Parser is generic, it should be
possible (with proper inlining) to have equivalent performance to the
hard-coded version.
In addition to using _simple terminal_ as a reference, there's a doc in
Alacritty's repository `docs/ansicode.txt`, a summary of the ANSI
terminal protocol, which has been referenced extensively.
There's probably a large number escapes we don't handle, and that's ok.
There's a lot that aren't necessary for everyday terminal usage. If you
feel like something that's not supported should be, feel free to add it.
Please try not to become overzealous and adding support for sequences
only used by folks trapped in 1988.
|
