Ultracompact Mode for Inspector (was RfC: Ultracompact Mode)

[philtweir]

What does this PR do?

Adds an ultracompact mode for the inspector.

• introduces a simplified inspector tab, with only previous-current-next commands as rows, in compact mode
• allows navigation through session history within the inspector (so compact inspector view is still useful)

It also (see comments below):

• makes compact into compactness, an enum (to better standardize across inspector/interactive)
• makes the inspector only change on ultracompact mode, which is still compact+(height<8)
• clippy's complexity limit wanted draw split up a little, so not sure if this is a reasonable minimal way to do so for now
• adds a (none) theme to the theming to enable output testing without styling
• additional tests, although keen for input on how best to do these one functional test, as a starting point
• documentation minor doc changes only, as I am not sure there is much to say

Was stacked on #2357, which is now in main

Checks

• I am happy for maintainers to push small adjustments to this PR, to speed up the review cycle
• I have checked that there are no existing pull requests for the same thing

[ellie]

Generally all good, thank you! Ultra-compact works nicely.

However the inspector might need some adjusting. I run compact mode all the time (as do some others), and it will likely become the default in the future. In compact mode, the inspector looks like this regardless of size

I think it would make sense to continue to show the stats/etc if the terminal is large enough, but I do really like the scrolling through history/session.

Do you think you'd be able to split the inspector changes into a separate PR? Other than those commits, I'm happy to merge this as-is

[philtweir]

Yep, sure! Good point - thinking about your comment, I realise I haven't properly thought about that stylistically-compact vs limited-space difference, so could I suggest I do two new PRs, if that makes sense:

• inspector in ultracompact mode (so compact and <8 lines), including the interactivity (as otherwise it's a bit redundant)
• inspector in compact mode, to start the discussion about what would be useful in general to change/keep/rearrange when compact is on (as I think you & others would need to input first to make sure I go in a sensible direction)

[ellie]

That sounds good to me!

[philtweir]

I have split out #2357 as requested, which this PR is now stacked on. It has been updated to:

• make compact into compactness, an enum (to better standardize across inspector/interactive)
• made the inspector only change on ultracompact mode, which is still compact+(height<8)
• clippy's complexity limit wanted draw split up a little, so not sure if this is a reasonable minimal way to do so for now

The intention (as above) would be to open a comment/forum-post to work out behaviour for a new PR for the inspector in (non-ultra-) compact mode, but this PR no longer has any change to the inspector except in ultracompact mode.

[philtweir]

Updated with a test - this turned out to be the hardest bit of the whole process, as the only sensible way I could see of testing a layout switch like this was to compare the output with TestBackend::assert_buffer_lines, but I could not for the life of me get it to match, likely due to ANSI code placement and how buffer area is calculated in different places in Crossterm/Ratatui :/

However, this forced me to take the PR beyond the inspector to enable a more sensible approach, by tweaking the new theming module -- this makes it possible to do the comparison without any styling. Obviously, this means the ultracompact-inspector styling is not checked, but the rest of the test is essential a functional test of ultracompact inspector layout, which is what I really wanted, rather than a brittle integration test tied to the default theme behaviour.

The downside is that I needed to add a new in-built theme called (none) (parentheses to highlight it is special, not general purpose). This only ever returns ContentStyle::default() so nothing is ever styled up, regardless of the Meaning passed. This might be separately useful where ANSI codes are not desirable or a theme author wishes to avoid inheriting anything from default now or in future, they could name (none) explicitly as a parent theme.

There is not much to put in the docs, but I have updated that PR too, so marking this ready-for-test.

[philtweir]

As a side-note, to make boldness a property the theming can control, it also adds StyleFactory::from_fg_color_with_attributes so that in-built themes can pass Crossterm Attributes as well as a foreground colour. Given agreement on syntax, this could be exposed to the theming YAML (as could background properties). Would be keen to know if that is desirable first before proposing changes.

[atuin-bot]

This pull request has been mentioned on Atuin Community. There might be relevant details there:

https://forum.atuin.sh/t/feedback-playing-with-inspector/218/6