Feedback & Playing with Inspector

[philtweir]

Hello - thanks for great utility @ellie & co! I heard about it first at the FOSDEM24 Ratatui talk, and really like it - trying to get it into my daily flow more now.

However, I am more used to inline (~5 lines) than full-screen command editing, so I decided to poke a bit more and optimize my config.toml. The one thing I could not see, was a way of hiding the tab-bar? I was wanting to spend some time today trying to practice a simple Rust patch, so tried adding a config option, like show_help that lets it hide when there are very few (inline) lines available, if PR would be useful?

That also flagged the inspector to me, and I saw a request-for-feedback, so here I am

Personally, in full-screen, I really like the stats (I see from @ellie’s posts here that reactions have been mixed) - I guess I am often searching back to remember what happened, and those are the stats I would like to see to contextualize an old command. In 5-lines of real estate, inline for inspector didn’t quite work, so since it was a new feature with WIP comments, and I didn’t think it already had a compact-mode, I had a go at paring that tab back to just prev/next commands vertically, and then making Up/Down move through the session when in the Inspector tab (which seems to work OK in full-screen too). Switching with Ctrl+o seems grand, didn’t hit any conflict, and it seems easy enough to remember.

If I really had to think of an enhancement idea around it, I guess it could be a way of displaying tags or labels in Inspector perhaps? I have used WakaTime with vim, and could be handy to link with timetracking, etc. to programmatically tag commands (by calling an atuin subcommand or via an env?) and see those tags in the inspector - which project was I on then? Was that when I was doing PHP for client A or client B? Can see some super useful new applications of stats then too.

So, in summary, while I’m a complete beginner here, I really love atuin overall, especially in compact mode, as well as the inspector, and am looking forward to seeing what comes next! While I appreciate this way of using the inspector wasn’t quite as intended, it seems really handy for me as an inline two-way search, as well as a stat-viewer - if anything there would be useful, I’d love feedback (even if ultimately rejected!) and happy to PR (also, conscious that the comments indicate a refactor into per-tab widgets is coming, so I tried to bear it in mind when writng, and I’d be interested to hear about that plan too).

[ellie]

Hey! Thanks for the feedback!

Firstly, something like show_help but for tabs was merged here: Add config setting for showing tabs by digital-cuttlefish · Pull Request #1755 · atuinsh/atuin · GitHub

and should be out in a week or so! Available now if you want to run weekly or main.

@philtweir

I had a go at paring that tab back to just prev/next commands vertically, and then making Up/Down move through the session when in the Inspector tab (which seems to work OK in full-screen too). Switching with Ctrl+o seems grand, didn’t hit any conflict, and it seems easy enough to remember.

This looks good and is sorta the direction I’d like to take it. The only issue I can see there is that it’s not immediately obvious from the UI what you are actually scrolling.

@philtweir

programmatically tag commands (by calling an atuin subcommand or via an env?) and see those tags in the inspector

Definitely! We had a discussion along those lines here: Feature idea: Taggable environments to group shell commands

@philtweir

I really love atuin overall, especially in compact mode, as well as the inspector, and am looking forward to seeing what comes next!

Thank you for the kind words

Definitely open to this sort of change

[philtweir]

Thanks for the response @ellie - I had only seen the show_help change after, so reminds me to double-check the open PRs first!

@ellie

This looks good and is sorta the direction I’d like to take it. The only issue I can see there is that it’s not immediately obvious from the UI what you are actually scrolling

I see what you mean, definitely - I will have a bit of a play around at this end and see if I can tighten it up a little, worst case I get more familiar with the codebase

Also, that’s great about tagging - again, a good reminder to search more first

[philtweir]

After rebasing on the show_tabs change, I tidied up a little and put together some ideas based on that feedback:

The thinking is that the original inspected command (the one highlighted when Ctrl+o is pressed) gives a baseline for time. Moreover, the offsets help highlight movement (especially if a series of commands are re-run). In the first example, I switched from the inspector on cargo run search -i and pressed Up once (so the “next command” is now “cargo run search -i”, and I can see that I ran the same command three times, the first 1m5s before the second, and the final time 21m later). For the previous and next commands, the time from the middle command is given, and from the original inspected command in parentheses. I did think it might make sense to switch to Left/Right in the full view? It’s probably not a great example given it has the same command text three times, but I promise that the stats are being shown for whatever is currently in the middle block

Still a PoC (Comparing atuinsh:main...philtweir:compact-inspector · atuinsh/atuin · GitHub for code) but happy to tidy up for PR if aligned with what you were thinking, or just enjoy by myself otherwise I did note in the code there was mention of a refactor to give the inspector its own state - I have tried to encapsulate the relevant state, but not separated it, so if it would help to do that first, makes sense.

[adamr]

Inspector is a really, really good idea! Thank you for implementing it.

I have two issues with it, though. One is that it is not friendly with low value on inline_height setting - as illustrated in the picture. Someone mentioned a “compact mode” - how do I switch to it?

The other one is that it does not allow you to scroll through the adjacent commands in the history around the command found. It only shows you the previous and last one. I understand, that the concept of the “next command” is ambiguous, as the entry is an aggregate of de-duplicated command instances, and each copy can have a different adjacent history. That may well call for another view - one that allows for easy browsing around a set of relevant sequences (vectors) of cammands containing and centered on the command in question, with the ability to scroll through the items in each sequence, so I can select it and re-play it in real life.