RFC/WIP: make common "before editing" keys accept selection

[martinetd]

Looking for old commands through ctrl-r I might often accept the command as is, but using the up key I'll almost always want to edit it.

When editing a command, I'll almost always want to move the cursor (home or left key) or try to delete something (backspace); this patch is just something to get a feeling of how that'd be and confirm that'd be useful as a feature (could be an option, or wait for #193)

However just custom key bindings isn't enough: when exiting through the home key you'd want to go to the begining of the line. This is easy enough to do the same way we're doing the enter_accept code: just pass some position argument with the command back for shells to parse (only implemented bash in this poc)

I'd be tempted to be greedy and also want to emulate stuff like alt-left/^W etc but that'd require computing the exact position and passing an exact position to handle in each shells instead of the beginning of line token I've used here, so that'll wait for more feedback -- I'm also still in a 'trying atuin out' phase so I might just drop this all tomorrow for all I know -- feel free to give this low priority and only consider it a source of idea for a few weeks if you want to make sure I'll finish it.

so:

• what do you think of having such a feature?
• how do you want to go about differentiating this from editing the search query? honestly I don't think I'll ever edit the search query in up mode, but in ctrl-r mode I might miss the backspace key..

(aaaand I just saw the PR template comment saying you prefer discussing in issues or forum, happy to open an issue and move discussion there if you prefer, but as far as I'm concerned a poc PR and an issue are the same thing and this gives something concrete to describe what I'm trying to do -- I'm obviously not intending for this to be merged in this form)

[martinetd]

hmm actually played with this some more, and I guess I'm just not getting used to the up key, at multiple levels:

• I keep getting surprised that the current readline buffer is taken in consideration and end up clearing it with ctrl-u quite a few times -- in a sense, the atuin's up key binding behavour is closer to the default "page up" shell history key binding than the up key
• I do end up missing ^W, alt-backspace, ctrl/alt-left etc more than I thought, but also just expecting typing more things to continue where the selected line is left off -- so really instead of trying to emulate everything the ideal behaviour would to be in a mode where only up/down are considered for up/down, at which point 1/ I'll just keep being annoyed a key is eaten to validate input, and 2/ might just as well use the shell bindings since most of the search features won't be usable (I guess something akin to vim modes to "switch" to more powerful search seamlessly might be possible, but I don't see how to make the last key be replayed by readline for the key being eaten problem, so that'll require emulating readline before returning the line and I'm not going into this hole)
• (add to that that with bash, fix(bash): rework #1509 to recover from the preexec failure #1729 fixed some of the history being added but comments aren't processed by the debug trap so with that fix comments would only be added after a search; I had to kludge bash-preexec a bit to make it register all comments)

So I'll just give up on this idea and disable the up/down search -- I'll just bind it to page up instead ;)

(It's a bit of a shame as I kind of liked seeing the few previous choices with --inline-height on up key, but it's just too different a behaviour for me)

Thanks for atuin, I'll go back to master and keep using it for ctrl-r/page up a bit longer!
Closing this as not expecting to continue, but feel free to discuss a bit more if you have an opinion you'd like to share on anything.