Add option to stop down arrow exiting search

Ideas
1

When scrolling through the interactive search, scrolling up scrolls the list down when the selected line is a few (10?) lines from the top so you have context when scrolling. When you scroll down, the selected line gets to the bottom of the screen before the list shifts up. This means it’s difficult to know when the next key is going to exit the search.

It’s a bit jarring to enter a search term, scroll a bit, then bit dropped back to the prompt (losing the search filter) because you’ve hit down too many times.

I can imagine that when you have the up-arrow key binding set up and “return-query” on exit enabled, you can scroll back up into the search without too much faff (although even then you’re back to default search filter/mode), but with only ctrl-r bound, it can be a pain.

At risk of having far too much configuration available, would it make sense to have a down_exits = false config option?

Slightly off-topic but what does the scroll_context_lines option do? I was hoping it would help here but it doesn’t seem to change anything.

2 Likes
2

Is there any way we can solve this problem without config additions?

It sounds like this is the real issue we’re working around here:

If it were very obvious when a line is at the bottom, would we still need to be able to stop the down arrow from exiting?

I think it was added to add an offset to scrolling by pages (pgup/pgdown), to try and maintain context. I don’t know if it’s ever actually been used though, and I wouldn’t be against removing it

3

Make it the default? /s?

I’m not sure, if scrolling down kept the selected line a few lines off the bottom it might be enough. If scroll_context_lines is unused, could it be repurposed for that?

1 Like
4

It is used, but I’ve not got my head around what it’s doing yet
It changes how many lines pageup/down scroll by, but not the position of where the selected line end up on the screen.

1 Like
5

hm I think this could be jarring in other ways

I think this would be the easiest thing to go for right now. It’s probably a good idea to introduce a “keys” struct as part of settings, rather than have lots of key-related things phrased differently in the root of the settings

something like this

[keys]
scroll_exits = true/false

down_exits would make sense, but in an inverted UI makes less sense. Also when using a keybinding that isn’t down to scroll, it’s a bit less clear

in the future I could see

[keys]
mapping = blah

existing too

1 Like
6

This makes sense to me and I would probably use it. Altough I use Atuin in fullscreen so I rarely need to scroll the past the shown commands.

Having key mappings mixed with other options seems a bit messy to me. I would suggest creating a separate (sub)section for key mappings. For example:

[keys]
scroll_exits = false 
[keys.mappings]
C-m = change_filter_mode
A-k = change_search_mode

I think this makes it really easy to distinguish between key mappings and other keys-related options as well as keeps the config well-organized.

1 Like
7

I also just wanted to ask for such an option. The current behavior is especially taxing when you use invert = true and hit the up key twice by mistake.

If you point me to the part in the code where the test takes place whether it is the first/last entry to exit, I am more than happy to submit a PR. I haven’t read the code too much, so I will certainly have to get more familiar with it, but I believe it is here:

Would a PR be accepted?

1 Like
8

Yes, that is the line to change. Go ahead!

1 Like
9
2 Likes