This fixes the issue that spawning the editor trashes the terminal.
The signature of the Runtime::editor() function changed, which has to be
fixed in using code.
do inherit stdin and stderr from parent process, to not break terminal
editors when editing stuff.
vim printed "Input not from terminal" warning messages. This was fixed
by this commit.
When we merged the changes in libimagrt so that it automatically detects
whether stdin/stdout is a TTY and provides the user with stderr in case
stdout is not a TTY, we forgot that things like
imag foo | grep bar
becomes impossible with that, because imag detects that stdout is not a
tty and automatically uses stderr for output.
But in this case, we don't want that. The output has to be stdout in
this case.
With this change, we have a flag in the runtime ("--pipe-magic" or "-P",
globally available) which turns on "pipe magic".
The expected behaviour is the following, if "-P" is passed:
* If stdout is a TTY, we print to stdout
* If stdout is not a TTY, we print to stderr
* If stdin is not a TTY, we do not provide it
If "-P" is not passed, we allow the user of libimagrt to use stdin for
interactive stuff (the interactive stuff is not yet implemented).
Signed-off-by: Matthias Beyer <mail@beyermatthias.de>
This is another approach for providing access to stdin/out/err via
libimagrt::runtime::Runtime.
The Runtime object does configure which output gets returned (stdout if
stdout is a tty, else stderr).
With this we can change libimagrt to read/write the store from/to
stdin/stdout without the user noticing that she does not write to stdout
but stderr.
Reading from stdin is not possible then, though.
This way we can control whether "out" output goes to stdout or stderr
without the user of the functionality knowing.
This is useful for later when we use libimagrt to automatically
read and write the store from and to stdout/in depending on whether we
are talking to a TTY or a pipe.
Adapt libimagrt interface to export the functions we need to do this.
This is not that nice, but the best approach without rewriting large
parts of libimagrt.
Before we extracted the store configuration from the configuration
toml::Value object and passed it to the store.
This is unecessary overhead.
Now we pass the whole configuration object and let the store extract the
required values.
Before the configuration object (the raw TOML object) was provided via a
wrapper object `Configuration`. This was ugly and not very nice to use.
Now, we only have the `toml::Value` object we lend out from
`Runtime::config()`.
The changes included libimagrt internal rewrites, which are not visible
to the user. Anyways, this change changes the API for config-fetching
from the runtime, so fixes for all other crates may follow.
The changes also removed the support for reading the "editor" setting
from the configuration file, which was not used anyways (in the example
imagrc.toml file).
The CLI-reading and ENV-reading are still supported, though.
This merge solved a _LOT_ of conflicts and was a rather complicated one,
as parts of the conflict-resolution involved rewriting of half the
stuff.
This merge commit fixes all the things so a `cargo check --all`
succeeds, but I did not yet check whether tests run without failure.
This is the first part of a series of patches that reimplements the
logging backend to be more powerful and configurable.
This first patch adds types and infrastructure to be able to implement a
powerful logging abstraction.
It does not implement much functionality, except for a check whether a
module is enabled or not when logging (if configured in the config
file).
This is necessary to be able to re-build a Runtime object with an new
set of "commandline arguments". For example if a test wants to test two
calls to imag, for example a "add" operation followed by a "remove" operation.
These functions are feature-gated therefor and should only be used in
tests.
Matthias Beyer