Reproduction steps:

1. Create a workspace manifest ./Cargo.toml:

   [workspace]
   members = [
       "crate-a",
       "crate-b",
   ]

2. Create two member crates:

   cargo new --lib crate-a
   cargo new --lib crate-b
   

3. Make crate-b depend on crate-a (in ./crate-b/Cargo.toml):

   [package]
   name = "crate-b"
   version = "0.1.0"
   edition = "2018"
   
   [dependencies]
   crate-a = { path = "../crate-a" }

4. Run bacon in workspace root, or in either of the crate directories. It fails with message:

   Error: `cargo metadata` exited with an error: error: package collision in the lockfile: packages crate-a v0.1.0 (... dir1 ...) and crate-a v0.1.0 (... dir2 ...) are different, but only one can be written to lockfile unambiguously

Meanwhile cargo metadata and cargo check work correctly when ran in any of those 3 directories.

OS: Windows 10
cargo --version: cargo 1.54.0 (5ae8d74b3 2021-06-22)
bacon --version: bacon 1.2.3

Having a failing doctest causes bacon to just display the raw test output instead of formatting it nicely for the user

Reproduction

Having a lib with the doctest

//! ```
//! panic!()
//! ```

and then running bacon -j test results in

Thanks for such a useful tool!

In addition to the standard jobs, I'd like to use bacon with some custom jobs. When these jobs fail they exit with a non-zero status and print some useful error messages.

I propose changing bacons behavior so that it does the following:

1. Try to parse and display warnings and errors as it normally does. If it finds any, use current behavior (ie: display them in a structured fashion and report the warning/failure count).
2. Otherwise (no warnings and errors were detected in stderr), check the job process' exit status. If it's 0, report "pass!" and display no output just as it currently does.
3. Otherwise (if exit status was non-zero), report failure and display the (unparsed) contents of stderr (as opposed to the current behavior of reporting "pass!" and displaying no output).

The idea is that this would support lots of new kinds of jobs right away and if new parsers are ever added, the output just gets better (and more structured) over time.

If this sounds like a reasonable feature I'd be happy to take a try at implementing it.

Thanks for considering the idea!

I'm using bacon 0.2.1 installed from cargo and if I open it, and then press q, my cursor which I have set to a solid block turns into a flashing block (Opening and closing vim restores it back to a solid block).

Here's cargo check:

error[E0277]: the size for values of type `()` cannot be known at compilation time
   --> /home/joshua/.local/lib/cargo/registry/src/github.com-1ecc6299db9ec823/time-0.1.43/src/lib.rs:597:10
    |
597 | #[derive(Debug)]
    |          ^^^^^ doesn't have a size known at compile-time
    |
    = help: the trait `Sized` is not implemented for `()`
    = note: this error originates in a derive macro (in Nightly builds, run with -Z macro-backtrace for more info)

error[E0277]: the size for values of type `std::fmt::Error` cannot be known at compilation time
   --> /home/joshua/.local/lib/cargo/registry/src/github.com-1ecc6299db9ec823/time-0.1.43/src/lib.rs:597:10
    |
597 | #[derive(Debug)]
    |          ^^^^^ doesn't have a size known at compile-time
    |
    = help: the trait `Sized` is not implemented for `std::fmt::Error`
    = note: this error originates in a derive macro (in Nightly builds, run with -Z macro-backtrace for more info)

error: aborting due to 226 previous errors

and here's bacon:

 rustc   1 warning  

 1  warning: unknown lint: `non_autolinks`
    --> library/core/src/lib.rs:290:34
     |
 290 | #[cfg_attr(not(bootstrap), allow(non_autolinks))]
     |                                  ^^^^^^^^^^^^^
     |
     = note: `#[warn(unknown_lints)]` on by default

It's definitely seeing the errors because they show up in the initial screen, before cargo finishes running. I guess it's not recognizing them as errors, though?

Bacon 2 is developed in the "bacon2" branch.

It makes possible to

• run jobs like cargo run (and see the output)
• run jobs like cargo doc --open (but not have it opening again and again)
• bind a job to a key combination of your choice
• change the key combinations for all internal functions (wrapping, quitting, etc.)

It comes with a help page listing all the configured key combinations, and I'll set up a site because while the simple use didn't change, some more complex uses are less obvious.

This will solve #47 and #52

Apart the web site, bacon 2 is mostly done. Now would be a good time to test it, comment.

This is a screenshot of bacon after saving a modified file, after bacon starts up for the first time.

I would expect the extra output to be either hidden or shown with proper line wrapping, not with weird indentation.

You can reproduce by running bacon on rustc (rustc strikes again!) with the following bacon.toml:

default_job = "check"

[jobs]

[jobs.check]
command = ["x", "check", "--color", "always"]

[jobs.clippy]
command = ["x", "clippy", "--color", "always"]

Hi, thanks for the excellent tool! Would it be possible to add vim-keybindings?

In particular:

• j to scroll down
• k to scroll up
• G to scroll to the bottom
• g to scroll to the top

I've got a dashboard monitor that sits up above my monitors and Bacon's top-focused UI would be better consumed if laid out with an emphasis on the bottom of the window instead of the top.

As far as features / requirements that would be useful for this, off the top of my head:

1. The top UI of [name] [X warnings] [X errors] would be at the bottom of the UI.
2. The hit q to quit, ... UI would be at the top.
3. The listing of warnings, errors, etc would be prioritized bottom to top. So the #1 error would be on the bottom. The #2 error would be above #1. The #3 warning would be above #2, and so on.

How difficult would this feature be to include? Would the author be interested in it at all?

Some parts of bacon were designed for Rust and are tied to cargo:

• default bacon.toml file
• compiler output parsing
• test output parsing
• documentation
• the use of TOML (which is just totally unknown outside the Rust ecosystem)

That's not much. Bacon could be used for other build chains.

But as I don't currently have a personal need, I'll progress there only if there's some interest.
Comment if you're interested.

--help takes too long to type :(

$ bacon -h
Unrecognized argument: -h

Bacon doesn't react to changed files on Windows.

(in my short tests using a VM)

So, this one is going to be hard to replicate and it's probably better to wait until some other bugs are fixed before looking too hard at it. I have this setup to workaround #10 and #9:
src is a soft-link to the current directory, the current directory is in a subfolder of the main project, and I replaced "cargo" with "x.py" in the source code:

diff --git a/src/report.rs b/src/report.rs
index 9b2e397..3087957 100644
--- a/src/report.rs
+++ b/src/report.rs
@@ -55,10 +55,10 @@ impl Report {
     pub fn compute(root_dir: &Path, use_clippy: bool) -> Result<Report> {
         let command = if use_clippy { "clippy" } else { "check" };
         debug!("starting cargo {}", command);
-        let output = Command::new("cargo")
+        let output = Command::new("x.py")

x.py check tells me I have an error:

    Finished dev [unoptimized + debuginfo] target(s) in 0.09s
    Finished release [optimized] target(s) in 0.09s
    Finished release [optimized] target(s) in 0.12s
    Checking rustdoc v0.0.0 (/home/joshua/rustc/src/librustdoc)
error[E0308]: mismatched types
    --> src/librustdoc/passes/collect_intra_doc_links.rs:2098:25
     |
2098 |       if param_depth == 0 {
     |  _________________________^
2099 | |         //Ok(stripped_segment)
2100 | |     } else {
     | |_____^ expected enum `std::result::Result`, found `()`
     |
     = note:   expected enum `std::result::Result<std::string::String, ResolutionFailure<'static>>`
             found unit type `()`

error: aborting due to previous error

For more information about this error, try `rustc --explain E0308`.
error: could not compile `rustdoc`

To learn more, run the command again with --verbose.
command did not execute successfully: "/home/joshua/rustc/build/x86_64-unknown-linux-gnu/stage0/bin/cargo" "check" "--target" "x86_64-unknown-linux-gnu" "-Zbinary-dep-depinfo" "-j" "8" "--release" "--manifest-path" "/home/joshua/rustc/src/tools/rustdoc/Cargo.toml" "--message-format" "json-render-diagnostics"
expected success, got: exit code: 101

but bacon does not:

 librustdoc   pass!  

I have several jobs in my bacon.toml and I'd like to run them all. I could open a terminal for each job, but that is tedious.

Is it possible to tell bacon to run all my jobs?

There will probably be a 'w' command to toggle the wrapping mode

Trying to install as per the readme (cargo install bacon) fails with:

error[E0599]: no function or associated item named `new_immediate` found for trait object `dyn Watcher` in the current scope
  --> /Users/max/.cargo/registry/src/github.com-1ecc6299db9ec823/bacon-1.1.7/src/app.rs:16:52
   |
16 |     let mut watcher: RecommendedWatcher = Watcher::new_immediate(move |res| match res {
   |                                                    ^^^^^^^^^^^^^ function or associated item not found in `dyn Watcher`

This is due to the newly released version 5.0.0-pre.11 of the notify crate which removed the new_immediate constructor.

Workaround for anyone who wants to install bacon right now:

• clone the repository
• install with cargo install --path . --locked (as that respects the Cargo.lock of the repository)

I was trying to find an issue with bacon unable to detect any changes (always display pass), but cargo check works just fine.
I was trying GH and cargo version, still the same issue. I was debugging this with: @Canop
These are logs from bacon from cargo:

17:39:44 [ INFO] Starting Bacon v0.2.3 with log level DEBUG
17:39:44 [DEBUG] (1) bacon::cli: args: Args { version: false, summary: false, clippy: false, root: None }
17:39:44 [DEBUG] (1) bacon::app: root_dir: "\\\\?\\D:\\Projects\\legendary-rover\\legendary-rover-hub"
17:39:44 [DEBUG] (1) bacon::report: starting cargo check
17:39:45 [DEBUG] (1) bacon::report: cargo check finished
17:39:45 [DEBUG] (1) bacon::report: status: ExitStatus(ExitStatus(101))
17:39:45 [DEBUG] (1) bacon::report: report: 0 warnings and 0 errors
17:41:14 [DEBUG] (3) bacon::app: notify event received
17:41:14 [DEBUG] (3) bacon::app: notify event received
17:41:14 [DEBUG] (1) bacon::app: got a watcher event
17:41:14 [DEBUG] (4) bacon::computer: COMPILER got task
17:41:14 [DEBUG] (4) bacon::report: starting cargo check
17:41:14 [DEBUG] (1) bacon::app: got a watcher event
17:41:14 [DEBUG] (1) bacon::app: error sending task: sending on a full channel
17:41:14 [DEBUG] (3) bacon::app: notify event received
17:41:14 [DEBUG] (3) bacon::app: notify event received
17:41:14 [DEBUG] (1) bacon::app: got a watcher event
17:41:14 [DEBUG] (1) bacon::app: error sending task: sending on a full channel
17:41:14 [DEBUG] (1) bacon::app: got a watcher event
17:41:14 [DEBUG] (1) bacon::app: error sending task: sending on a full channel
17:41:14 [DEBUG] (3) bacon::app: notify event received
17:41:14 [DEBUG] (3) bacon::app: notify event received
17:41:14 [DEBUG] (1) bacon::app: got a watcher event
17:41:14 [DEBUG] (1) bacon::app: error sending task: sending on a full channel
17:41:14 [DEBUG] (1) bacon::app: got a watcher event
17:41:14 [DEBUG] (1) bacon::app: error sending task: sending on a full channel
17:41:14 [DEBUG] (3) bacon::app: notify event received
17:41:14 [DEBUG] (1) bacon::app: got a watcher event
17:41:14 [DEBUG] (1) bacon::app: error sending task: sending on a full channel
17:41:14 [DEBUG] (4) bacon::report: cargo check finished
17:41:14 [DEBUG] (4) bacon::report: status: ExitStatus(ExitStatus(101))
17:41:14 [DEBUG] (4) bacon::report: report: 0 warnings and 0 errors
17:41:38 [DEBUG] (3) bacon::app: notify event received
17:41:38 [DEBUG] (1) bacon::app: got a watcher event
17:41:38 [DEBUG] (3) bacon::app: notify event received
17:41:38 [DEBUG] (4) bacon::computer: COMPILER got task
17:41:38 [DEBUG] (4) bacon::report: starting cargo check
17:41:38 [DEBUG] (1) bacon::app: got a watcher event
17:41:38 [DEBUG] (1) bacon::app: error sending task: sending on a full channel
17:41:38 [DEBUG] (3) bacon::app: notify event received
17:41:38 [DEBUG] (3) bacon::app: notify event received
17:41:38 [DEBUG] (1) bacon::app: got a watcher event
17:41:38 [DEBUG] (1) bacon::app: error sending task: sending on a full channel
17:41:38 [DEBUG] (1) bacon::app: got a watcher event
17:41:38 [DEBUG] (1) bacon::app: error sending task: sending on a full channel
17:41:38 [DEBUG] (3) bacon::app: notify event received
17:41:38 [DEBUG] (3) bacon::app: notify event received
17:41:38 [DEBUG] (1) bacon::app: got a watcher event
17:41:38 [DEBUG] (1) bacon::app: error sending task: sending on a full channel
17:41:38 [DEBUG] (1) bacon::app: got a watcher event
17:41:38 [DEBUG] (1) bacon::app: error sending task: sending on a full channel
17:41:38 [DEBUG] (3) bacon::app: notify event received
17:41:38 [DEBUG] (1) bacon::app: got a watcher event
17:41:38 [DEBUG] (1) bacon::app: error sending task: sending on a full channel
17:41:38 [DEBUG] (4) bacon::report: cargo check finished
17:41:38 [DEBUG] (4) bacon::report: status: ExitStatus(ExitStatus(101))
17:41:38 [DEBUG] (4) bacon::report: report: 0 warnings and 0 errors
17:41:40 [DEBUG] (3) bacon::app: notify event received
17:41:40 [DEBUG] (1) bacon::app: got a watcher event
17:41:40 [DEBUG] (4) bacon::computer: COMPILER got task
17:41:40 [DEBUG] (4) bacon::report: starting cargo check
17:41:40 [DEBUG] (3) bacon::app: notify event received
17:41:40 [DEBUG] (1) bacon::app: got a watcher event
17:41:40 [DEBUG] (1) bacon::app: error sending task: sending on a full channel
17:41:40 [DEBUG] (3) bacon::app: notify event received
17:41:40 [DEBUG] (3) bacon::app: notify event received
17:41:40 [DEBUG] (1) bacon::app: got a watcher event
17:41:40 [DEBUG] (1) bacon::app: error sending task: sending on a full channel
17:41:40 [DEBUG] (1) bacon::app: got a watcher event
17:41:40 [DEBUG] (1) bacon::app: error sending task: sending on a full channel
17:41:40 [DEBUG] (3) bacon::app: notify event received
17:41:40 [DEBUG] (3) bacon::app: notify event received
17:41:40 [DEBUG] (1) bacon::app: got a watcher event
17:41:40 [DEBUG] (1) bacon::app: error sending task: sending on a full channel
17:41:40 [DEBUG] (1) bacon::app: got a watcher event
17:41:40 [DEBUG] (1) bacon::app: error sending task: sending on a full channel
17:41:40 [DEBUG] (3) bacon::app: notify event received
17:41:40 [DEBUG] (1) bacon::app: got a watcher event
17:41:40 [DEBUG] (1) bacon::app: error sending task: sending on a full channel
17:41:40 [DEBUG] (4) bacon::report: cargo check finished
17:41:40 [DEBUG] (4) bacon::report: status: ExitStatus(ExitStatus(101))
17:41:40 [DEBUG] (4) bacon::report: report: 0 warnings and 0 errors
17:41:44 [DEBUG] (3) bacon::app: notify event received
17:41:44 [DEBUG] (1) bacon::app: got a watcher event
17:41:44 [DEBUG] (3) bacon::app: notify event received
17:41:44 [DEBUG] (4) bacon::computer: COMPILER got task
17:41:44 [DEBUG] (4) bacon::report: starting cargo check
17:41:44 [DEBUG] (1) bacon::app: got a watcher event
17:41:44 [DEBUG] (1) bacon::app: error sending task: sending on a full channel
17:41:44 [DEBUG] (3) bacon::app: notify event received
17:41:44 [DEBUG] (3) bacon::app: notify event received
17:41:44 [DEBUG] (1) bacon::app: got a watcher event
17:41:44 [DEBUG] (1) bacon::app: error sending task: sending on a full channel
17:41:44 [DEBUG] (1) bacon::app: got a watcher event
17:41:44 [DEBUG] (1) bacon::app: error sending task: sending on a full channel
17:41:44 [DEBUG] (3) bacon::app: notify event received
17:41:44 [DEBUG] (3) bacon::app: notify event received
17:41:44 [DEBUG] (1) bacon::app: got a watcher event
17:41:44 [DEBUG] (1) bacon::app: error sending task: sending on a full channel
17:41:44 [DEBUG] (1) bacon::app: got a watcher event
17:41:44 [DEBUG] (1) bacon::app: error sending task: sending on a full channel
17:41:44 [DEBUG] (3) bacon::app: notify event received
17:41:44 [DEBUG] (1) bacon::app: got a watcher event
17:41:44 [DEBUG] (1) bacon::app: error sending task: sending on a full channel
17:41:44 [DEBUG] (4) bacon::report: cargo check finished
17:41:44 [DEBUG] (4) bacon::report: status: ExitStatus(ExitStatus(101))
17:41:44 [DEBUG] (4) bacon::report: report: 0 warnings and 0 errors
17:41:46 [DEBUG] (3) bacon::app: notify event received
17:41:46 [DEBUG] (1) bacon::app: got a watcher event
17:41:46 [DEBUG] (3) bacon::app: notify event received
17:41:46 [DEBUG] (4) bacon::computer: COMPILER got task
17:41:46 [DEBUG] (4) bacon::report: starting cargo check
17:41:46 [DEBUG] (1) bacon::app: got a watcher event
17:41:46 [DEBUG] (1) bacon::app: error sending task: sending on a full channel
17:41:46 [DEBUG] (3) bacon::app: notify event received
17:41:46 [DEBUG] (3) bacon::app: notify event received
17:41:46 [DEBUG] (1) bacon::app: got a watcher event
17:41:46 [DEBUG] (1) bacon::app: error sending task: sending on a full channel
17:41:46 [DEBUG] (1) bacon::app: got a watcher event
17:41:46 [DEBUG] (1) bacon::app: error sending task: sending on a full channel
17:41:46 [DEBUG] (3) bacon::app: notify event received
17:41:46 [DEBUG] (3) bacon::app: notify event received
17:41:46 [DEBUG] (1) bacon::app: got a watcher event
17:41:46 [DEBUG] (1) bacon::app: error sending task: sending on a full channel
17:41:46 [DEBUG] (1) bacon::app: got a watcher event
17:41:46 [DEBUG] (1) bacon::app: error sending task: sending on a full channel
17:41:46 [DEBUG] (3) bacon::app: notify event received
17:41:46 [DEBUG] (1) bacon::app: got a watcher event
17:41:46 [DEBUG] (1) bacon::app: error sending task: sending on a full channel
17:41:47 [DEBUG] (4) bacon::report: cargo check finished
17:41:47 [DEBUG] (4) bacon::report: status: ExitStatus(ExitStatus(101))
17:41:47 [DEBUG] (4) bacon::report: report: 0 warnings and 0 errors
17:41:48 [DEBUG] (1) bacon::app: user requests quit
17:41:48 [DEBUG] (4) bacon::computer: closing computer
17:41:48 [DEBUG] (1) bacon: bye

These are from GH:

17:51:45 [ INFO] Starting Bacon v0.2.3 with log level DEBUG
17:51:45 [DEBUG] (1) bacon::cli: args: Args { version: false, summary: false, clippy: false, root: None }
17:51:45 [DEBUG] (1) bacon::app: root_dir: "\\\\?\\D:\\Projects\\legendary-rover\\legendary-rover-hub"
17:51:45 [DEBUG] (1) bacon::report: starting cargo check
17:51:45 [DEBUG] (1) bacon::report: cargo check finished
17:51:45 [DEBUG] (1) bacon::report: status: ExitStatus(ExitStatus(101))
17:51:45 [DEBUG] (1) bacon::report: report: 0 warnings and 0 errors
17:51:48 [DEBUG] (1) bacon::app: user requests quit
17:51:48 [DEBUG] (4) bacon::computer: closing computer
17:51:48 [DEBUG] (1) bacon: bye

There doesn't appear to be a way to show more errors than the top 4 without changing to summary mode.

I tried both 'q' and ctrl+c. It freezes until cargo check finishes no matter what.

Right now, bacon will show computing... until it finishes running for the first time. Especially for large codebases, this is a very long time to go without feedback. It would be nice to show cargo's progress bar so I know what's taking so long.

I just updated to bacon 0.5.1 and now when I start it I get Error: No such file or directory (os error 2).

Not having a file name happens when the Cargo.toml file is at the root (for example / on linux, or c:\ on Windows).

I'm unsure if this is a bug or design: The integration-test folder /tests/ is ignored (not watched) by bacon.

I think I've fixed it by adding watch = ["tests"] to a toml file, but I think this folder should be watched by default.

There will be a few things to configure, most notably the options to add to cargo watch or cargo test for the default bacon launch in the project.

Right now the idea is to have a bacon.toml file in the project's dir but I'd like to have opinions about that.

I am working on a project (https://github.com/timberio/vector) that uses a large number of features in cargo. I frequently want to run the compilation with ad-hoc features turned on, typically using --no-default-features to reduce the rebuild cycle time. It is infeasible to create a bacon.toml file that contains a job specification for each one of the features, particularly when combined with permutations of flags like --lib, --tests, or using clippy. As such, I am reduced to editing bacon.toml each time I need different feature flags enabled. Support for adding these options dynamically using command line flags would be very helpful.

I find that bacon does not re-run checks when modifying a file under src/. Adding watch = ["src"] to the job does not help. If I restart bacon the tests are run.

cargo watch does rerun the tests, so I'm guessing it uses a different file watcher?

It would be awesome if bacon could support compiler feature flags. Namely --features <FEATURES>... and `--no-default-features.

$ cargo build --help | grep feature
        --features <FEATURES>...     Space or comma separated list of features to activate
        --all-features               Activate all available features
        --no-default-features        Do not activate the `default` feature

I'm not sure how bacon calls the Rust compiler. If it's invoking the cargo command on your system, you might add a flag or environment variable to modify the command it uses as well. That might be easier to implement, and does support setting feature flags as well.

It runs cargo check, finishes seeing all the 'duplicate lang error's, then immediately exits with

Error: No space left on device (os error 28)

df -h reports 300 GB free, so I don't expect that to be the issue.

 1  error: duplicate lang item in crate `core` (which `rustc_std_workspace_core` depends on): `bool`.
   |
 2  error: duplicate lang item in crate `core` (which `rustc_std_workspace_core` depends on): `char`.
   |

The original errors were

 1  error: duplicate lang item in crate `core` (which `rustc_std_workspace_core` depends on): `bool`.
   |
   = note: the lang item is first defined in crate `core` (which `atty` depends on)
   = note: first definition in `core` loaded from /home/joshua/.local/lib/rustup/toolchains/nightly-x86_64-unknown-linux-gnu/li   = note: second definition in `core` loaded from /home/joshua/rustc/target/debug/deps/libcore-b870ac597eff48a7.rmeta
 
 2  error: duplicate lang item in crate `core` (which `rustc_std_workspace_core` depends on): `char`.
   |
   = note: the lang item is first defined in crate `core` (which `atty` depends on)
   = note: first definition in `core` loaded from /home/joshua/.local/lib/rustup/toolchains/nightly-x86_64-unknown-linux-gnu/li   = note: second definition in `core` loaded from /home/joshua/rustc/target/debug/deps/libcore-b870ac597eff48a7.rmeta

Goals would be to see the results of test units if it compiles, by parsing the output of "cargo check".

specification updated following program evolution and experimentation

I am on Ubuntu Linux 21.10. When I run cargo install bacon I get several errors.

Often when I'm doing major refactorings I end up with lots of warnings about unused imports, etc. It would be nice to be able to disable these.

Here's the script I used before bacon, for reference:

$ cat $(which check-color)
#!/bin/sh
# This script is meant for when you have so many errors the first ones go off the screen.
cargo rustc --lib --profile check --color always -- --cap-lints warn -A warnings "$@" 2>&1 | less -R

Note how it uses --cap-lints warn to avoid codebases adding forbid(warnings) at the top of the file.

Right now bacon doesn't check examples.

A solution is to add a job for each example but it's not very convenient as it means you bot have to add the entry in bacon.toml and to choose it when launching bacon, and to select the example directory to have it watched.

So I'd like something better. And before implementing anything here, I'd like to decide on a design.

Ideas:

1. automatically add --example [..] when the path can be detected to be one of an example

2. have a special syntax for the command where "<filename>" would be expanded

[jobs.example]
command = ["cargo", "check", "--example", "<filename>", "--color", "always"]

I'm not sure exactly how to describe this, and it's a bit niche so maybe it doesn't need to change.

By default, when you run bacon and don't type anything else, it will follow the cargo output as it runs, and earlier output will scroll off the screen. If you scroll the output while the inital output is still being collected, it will always stay at the location you scrolled to - even if you scroll back to the bottom, it won't follow the new output. It would be nice to toggle that somehow.

Running bacon -j check-all reports errors in the examples, but if examples are changed, bacon does not rerun the check. I attempted to solve this in #38, but @Canop suggested that the following would be preferable:

[jobs.test]
command = ["cargo", "test", "--color", "always"]
need_stdout = true
watch = ["tests"]

Therefore, only the directories that the job depends on are watched.

One question I have: should src be included implicitly? Or should the user have to specify "src", "tests"?

First of all thanks for this great tool.
I use and like it a lot.

I'm currently wondering, if it's possible to run a check of the test configuration.
I do not want to actually run the tests, but just check the build. So not what bacon test does.
If the check of the normal build succeeds, I'd like bacon to also check the test build.

So something equivalent to this shell code:

cargo check && cargo check --tests

Is that possible (to add)?

Trying to upgrade bacon from v1.1.8 to v1.2.1 on Rust 1.55.0, I get the following build errors:

error[E0659]: `minimad` is ambiguous (name vs any other name during import resolution)
 --> $HOME/.cargo/registry/src/github.com-1ecc6299db9ec823/bacon-1.2.1/src/list_jobs.rs:3:5
  |
3 |     minimad::*,
  |     ^^^^^^^ ambiguous name
  |
  = note: `minimad` could refer to a crate passed with `--extern`
  = help: use `::minimad` to refer to this crate unambiguously
note: `minimad` could also refer to the crate imported here
 --> $HOME/.cargo/registry/src/github.com-1ecc6299db9ec823/bacon-1.2.1/src/list_jobs.rs:4:5
  |
4 |     termimad::*,
  |     ^^^^^^^^^^^
  = help: use `self::minimad` to refer to this crate unambiguously

error[E0308]: mismatched types
  --> $HOME/.cargo/registry/src/github.com-1ecc6299db9ec823/bacon-1.2.1/src/list_jobs.rs:26:32
   |
26 |     skin.print_owning_expander(&expander, &TextTemplate::from(MD));
   |                                ^^^^^^^^^ expected struct `termimad::minimad::OwningTemplateExpander`, found struct `minimad::OwningTemplateExpander`
   |
   = note: expected reference `&termimad::minimad::OwningTemplateExpander<'_>`
              found reference `&minimad::OwningTemplateExpander<'_>`

error[E0308]: mismatched types
  --> $HOME/.cargo/registry/src/github.com-1ecc6299db9ec823/bacon-1.2.1/src/list_jobs.rs:26:43
   |
26 |     skin.print_owning_expander(&expander, &TextTemplate::from(MD));
   |                                           ^^^^^^^^^^^^^^^^^^^^^^^ expected struct `termimad::minimad::TextTemplate`, found struct `minimad::TextTemplate`
   |
   = note: expected reference `&termimad::minimad::TextTemplate<'_>`
              found reference `&minimad::TextTemplate<'_>`

error[E0308]: mismatched types
   --> $HOME/.cargo/registry/src/github.com-1ecc6299db9ec823/bacon-1.2.1/src/state.rs:254:17
    |
254 |                 Composite::from_inline(&status),
    |                 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ expected struct `termimad::minimad::Composite`, found struct `minimad::Composite`

error[E0308]: mismatched types
   --> $HOME/.cargo/registry/src/github.com-1ecc6299db9ec823/bacon-1.2.1/src/state.rs:256:17
    |
256 |                 Alignment::Left,
    |                 ^^^^^^^^^^^^^^^ expected enum `termimad::Alignment`, found enum `minimad::Alignment`

Some errors have detailed explanations: E0308, E0659.
For more information about an error, try `rustc --explain E0308`.
error: failed to compile `bacon v1.2.1`, intermediate artifacts can be found at `/tmp/cargo-installEksTGS`

Let me know if you need more info.

Discussions and even a PR have already occurred on this topic with @nikhilmitrax and @jyn514 but I'd like to decide on a specification before going further.

Goals

• allow watching only parts of the source, to prevent inotify from using excessive resources on huge repositories
• being compatible with workspaces
• not be painful to launch or configure

Proposal

• I call intended directory:
  • the closest directory of the path given as argument or if none
  • the current directory
• the package directory is the closest one from the intended one containing a Cargo.toml file
• the Cargo.toml file is watched by notify
• we also watch with notify
  • the intended directory if given explicitly or
  • the source directories given by the Cargo.toml file (using the cargo_metadata crate)
• cargo check (or other commands, see other issues) is launched in the package directory

(edited)

Some editors create temporary or lock files in the same directory as the file being edited. For example vi/vim will create a file named .FILENAME.swp when the file is first opened for editing, and emacs will create a link named .#FILENAME when a file open for editing has unsaved changes. When these files are created, they trigger an unnecessary extra run of the current job.

See https://github.com/watchexec/watchexec/blob/35e39afb95d5c66b41f843ce8850ee8da37a5516/src/cli.rs#L265 for a good starting point on which file patterns can be safely ignored. Obviously the *.py? patterns don't apply here.

bacon doc may be used on its own but some users may want to have the doc open in the browser when the command is launched, similarly to cargo doc --open.

Several strategies are possible (see discussion in PR #46 for some).

This issue will make it easier to track progress.

Examples:

bacon -- -p my_crate_in_workspace

bacon exec -- bla

The first one add ["-p", "my_crate_in_workspace"] to the default job. The second one adds ["bla"] to a job called exec.

Thanks for a great project!

bacon check-all is arguably the most common command for bacon, yet it is not mentioned in the help text of bacon --help.

Reproduction

A crate with

#[test]
fn demo() {
    println!("    Space    Separated");
    println!("\tTab\tSeparated");
    panic!();
}

and then running bacon -j test results in

So tabs aren't present from the second println!() even though the tabs are present in the output of cargo test

bacon already has the --no-default-features and --features flags. --all-features would be a useful addition.

I would expect it to give either an error or a warning. Instead it does nothing.

Steps to reproduce:

1. touch bacon.toml
2. bacon --init

I've been using bacon for quite a while and it's very useful. The way I seem to use it most often is:

1. Edit things
2. Switch to terminal where bacon is running, check if any things need fixing
3. [repeat]
4. Once all is good, quit bacon, hit "up twice" to recall some kind of cargo run ... command and run that
5. Once done, relaunch bacon (up+up+return) and repeat the whole process

For this, it would be nice if there was a way to configure a key I could press in bacon which would execute an arbitrary command. So instead I could:

1. Edit
2. Switch to bacon
3. Press "r" - this would run, say, cargo run -- --customthing=1

Basically I can configure a keyboard key and the command it will invoke.

Such a feature would probably need some careful thought as to constrain the scope of what can and cannot be done (to avoid it being a few "what if it could also.." steps away from becoming a full terminal multiplexer!) - as such, at least for the above I imagine it would be limited as follows:

1. When invoking the command, everything else is stopped - the main checking command is no longer run, no further shortcuts are accepted, etc (to prevent having to mix multiple outputs somehow)
2. The output from the custom command is presented as-is in the scrollable output window - no parsing, just appending each line to output (if it could entirely stop the TUI interface, run the command in plain terminal, and restore, then even better)
3. Once the command exits, there is maybe some "press enter to return" prompt (so the terminal output remains visible in event of crash)
4. After that, the output is cleared and the normal checking is resumed

Aside from my use-case above, this might be a nice solution to #47 - you could bind, say, d to run cargo doc --open then when you run bacon doc you can press d at any time to (re)open the docs in browser

Hope that makes sense! Feel free to close this if it seems outside the scope of what you thing bacon should do!

I've been testing various custom jobs by adding them to and editing "bacon.toml".

Currently my flow is:

1. Edit "bacon.toml".
2. Kill current bacon.
3. Re-run bacon <custom_job>.

I think it would be nice if bacon watched "bacon.toml" for updates and restarted itself to load the new configuration and try any changes.

If this sounds like a useful feature I wouldn't mind taking a try at implementing it.

Thanks for a great tool!

Would it be possible to run bacon without having to create a bacon.toml?
There are times where I just want to watch compilation/tests without having to make a bacon.toml file.

What I'm envisioning is running something like:

bacon --job "cargo clippy --color always"

Is this something that is possible to implement?

Hello,

Thanks for the tool! I noticed it does not directly support compiling workspaces. That's a situation where, imho, this tool would be quite valuable. I don't know about the effort involved, but it would be useful to support workspaces.