feat: add --print-command and --print-cheat flags

[kavau]

Summary

This PR adds two new optional flags that print information about the selected
cheat to stdout before executing it.

--print-command / -P

Prints the resolved command before executing it:

% navi --print-command -q "apt list"
navi> apt list --upgradeable
Listing... Done
code/stable 1.110.1-1772839555 arm64 [upgradable from: ...]

Useful for keeping a visible record of what was run in a terminal session.

--print-cheat / -C

Prints a formatted block with the comment and command before executing it:

% navi --print-cheat -q "apt list"
──────────────────────────────────────
# Check updates for installed packages
apt list --upgradeable
──────────────────────────────────────
Listing... Done
code/stable 1.110.1-1772839555 arm64 [upgradable from: ...]

The separator width adapts to the longest line (capped at 80 chars). The
comment and command are coloured using crossterm (already a dependency).

Motivation

Selecting a cheat, having navi execute it, and then seeing only the command output but not the command itself, feels like "flying blind". It's nicer and safer to have a record of exactly what happened in the terminal output.

Changes

• src/config/cli.rs — new --print-command (-P) and --print-cheat (-C) flags, plus examples in --help
• src/config/mod.rs — print_command() and print_cheat() accessors on Config
• src/commands/core/actor.rs — print logic before spawn()
• docs/usage/README.md — new sections documenting --print-command and --print-cheat

Notes

• rust-toolchain.toml was bumped from 1.81.0 to 1.88.0 to resolve a
  build failure caused by transitive dependencies requiring newer editions
  (getrandom 0.4, home 0.5.12). This seems like a pre-existing issue
  worth fixing regardless of this PR.
• When both -C and -P are passed, -C takes precedence.

MAINTAINER EDIT: Partially answers to #1009

[alexis-opolka]

Before doing any actual review on the code, I would like to have the thoughts of @denisidoro and @kit494way with which we've had some discussions about it during different PRs.

This feature has been requested multiple times, for a raw navi call to behave the same way it behaves when used with a shell plugin. In the way that you have an entry of the resolved command in the shell history.

It's also worth mentioning that these kinds of features can also have safety impacts, which were in part discussed in #977, then in #981 and is currently tracked with the feat/variable-history branch where variables could be exposed in the shell history as raw values, which is clearly not recommended.

@kavau have you tried to see if your modifications were impacted with the use of a shell plugin?
In the case the print command is activated, for example. I'm just blindly asking here.😅

[denisidoro]

I'd rather not add the short option, because we'll need to maintain it forever (unless there's a breaking change).

[denisidoro]

Same as above

[denisidoro]

Could you please consider making it print to stderr instead?

This way it won't break commands like navi --print-command -q 'command which echoes to stdout' | grep 'foo'.

By printing to stderr, you can still break commands which read from stderr, but that's much more rare.

[denisidoro]

This feature has been requested multiple times, for a raw navi call to behave the same way it behaves when used with a shell plugin. In the way that you have an entry of the resolved command in the shell history.

@alexis-opolka I'm afraid I don't understand the concern around shell plugins. Could you please elaborate?

[alexis-opolka]

Of course ^^

I might be completely wrong on that, I'm talking about it from some time ago so don't hesitate to correct me if I'm wrong. 😅

There were some concerns about how a command is stored within a shell history when resolving commands and/or variables, in the way that when you type the actual command within a shell (or use the plugins for navi), the actual value of the variable is not recorded in the shell history.
Then that would also mean that if you print the resolved command from a cheat containing variables of sensitive nature (API keys, secrets, etc.) you might be exposing the values. If I remember right, that was one of the reasons I didn't merge #981 into the main branch and instead created a dedicated branch to continue the work on it.

The other one is not an actual concern and more of a question on how printing the resolved command would behave when using a shell plugin. Which would be more impacted if the values are actually part of the configuration, as requested by #1009 .

I don't know if I was clear enough, as I said I might be completely wrong about that. 😅

P.S. The shell plugin would need to call navi with the explicit flags though to actually see the behaviour but it never hurts to ask. ^^

[kit494way]

Wouldn't a shell function be enough for the --print-command option?
Here is an example in fish shell.

function navi-print-command
    set cmd (navi --print)
    echo "navi> $cmd"
    echo "$cmd" | fish
end

Printing a description of a cheat is not mentioned in the relevant issue (#1009).
I wonder if --print-cheat option was implemented because it was needed, or because it was possible to implement?
If it is needed, wouldn't it be better to print JSON (e.g. {"description": "...", "command": "..."}) and implement a shell function that uses it?

IMO, it is better for navi to focus on parsing cheats, launching a fuzzy finder like fzf and outputting the necessary information.
This allows users to freely customize how they use the navi according to their needs.