"recent_change" filter mode + filter_mode fallback

Ideas
1

A thought that occurred to me while making my “sometimes trigger on up arrow” hook (atuin-up-search-if-prefix zle widget)¹

was "how do I want to handle the situation where ↑ is the first keystroke in a brand new shell?"²

which in turn made me think about the probably slightly more common variations of that and their “potentially likeliest” answers.

It seems to my mind like—regardless of what someone’s preference for a default/“steady state” filter_mode is:

(out of global, host, and session, at least):

  • if they trigger atuin immediately (or indeed shortly) after changing working directories (first/next thing after running cd, j, z, etc.):

    there’s a good chance it would be helpful for the next invocation(s)³ to take on directory scope.

  • likewise, if atuin is invoked immediately⁴ after entering a (login) shell [via ssh (/mosh/et, not sure about direct on a tty or pty]:

    there’s a good chance it would be helpful for the next invocation(s)³ to take on host scope

That is, generalized, I am suggesting the principle

if a user runs a command that changes the evaluation of a filter_mode shortly before invoking atuin search,

then that filter_mode is most likely to provide the next command they want to run

while there are definitely exceptions to that principle, it seems to me like it might hold enough to be a reasonable option or even a reasonable default

One can also go one further and say broadly:

whenever execution context changes, the next command [with side effects*] to run is very likely to be a function of that change in context

[*this is to exclude merely “context checking” commands like ls, git status, other things that might be understood to replace or elaborate on a rich prompt]

as such one could imagine further versions of this contextual triggering on the basis of e.g.:

  • recently run git/[other vcs] commands (in particular like checkout, switch, or other movement of HEAD;

    and in a ~different way rebase -i or merge),

  • invocations like eval "$(x)", source y.sh, [various things that use the word activate, like virtualenv]

  • (specific) recently changed/initialized environment variables ($PATH being the main one which leaps to mind; but if you were watching any, watching $PWD, $HOST, maybe some of the prompt-related vars

  • as well as the deeper rabbit holes of simply ~clustering of prefixes of recently run commands, or e.g. what commands are frequently run after certain files are edited (whether that knowledge was derived ~only by previous command being of the form $editor $file or more involved fs watching)

¹ in the bottom section of Atuin "off the bottom" of local history (i.e. bound on ⬇️)

² I decided for now just trigger atuin same as for ↑-after-return-to-end-of-line and ↓-at-end-of-history; but really the right answer might be something else entirely like firing a “project picker” menu of some sort (in the simplest case maybe zoxide’s zi)

³ perhaps up to the point that they start typing commands without using history, and/or perchance on some actual cooldown timer from cd or equivalent, and/or a “warmup counter” on length of session history.

⁴ as above there are various ways to interpret/scope “immediately after” - it seems worth pointing out that if making this decision, moreso than for working dir, time-based is well-provided for by external native data sources such as:

  1. the $SECONDS variable provided by at least bash and zsh ,
  2. the recorded session start times you’d get from who, w, finger, or directly from whatever utmp files
2

It also [related but potentially separately] seems to me that— whereas global, host, and (to a lesser extent) directory as defaults are apt to be helpful most of the time and with little change from start— on the other hand,

if one uses session, there is really some number of commands you need to have actually executed in the session before that choice becomes truly desirable

(before which it might be preferable either to fallback to global, host, or directory; or for atuin to duck out from capturing [especially] up-arrow at all).

This dovetails to a premise that probably would enhance the above proposal (but is perhaps most relevant to this “early in session” case):

in many situations, it might be more helpful for atuin to offer/use:

  1. one prioritized/default filter_mode that provides a ~fixed number of results for the top of the list / search results

  2. a broader¹ fallback filter_mode that provides less-prioritized results to fill down to bottom of screen height

    AND/OR

    provides results only when a provided query reduces results from default mode {to 0 or to <= another low threshold}

I imagine this as UXed with a horizontal rule and possibly a small label between sections.

One could conceivably also color and/or sigil (e.g. [D], [H], [G])-code more freely mixing weighted-by-context results

I think my suggestion above is a better feature if it could be like:

  • right after cd (after $PWD changes), you get suggested first 3-5 most frequently run commands in this directory (or specifically most frequently run after changing to this directory), then back to stuff from your default scope

  • right after you ssh (when $SECONDS is below some threshold), you get most frequently run commands on this host (or specifically most frequently first run commands on this host), then back to stuff from your default

  • when you start a new session, the session commands accumulate until they push out a first screen of whatever else commands; but the initial usage is still more useful

¹ broader: so … global for host > host for session and directory ; host and possibly directory for young sessions, but likely session for directory for young directories and lengthy sessions)