Zsh-autocomplete: max-lines range based on prompt's vertical position

[artfulrobot]

Is your feature request related to a problem? Please describe.

It's great that we can restrict max-lines with a % or an integer number of lines. However this leads to two different experiences depending on where your cursor is on the screen.

If you have a new terminal, or have just Ctrl-L or cleared your screen then the menu does not cause any scrolling. But if you're near the bottom, it forces scrolling. Scrolling is a nuicance because (a) you lose where your cursor is, it's jarring on the eyes, and (b) you lose sight of the text content above your cursor when it is scrolled off screen.

Describe the solution you'd like

I was wondering if it would be a good idea to set a range , with a min and a max.

e.g. LINES_MIN=10 LINES_MAX=50 given a terminal with ROWS=60 and CURSOR_ROW defining which row the cursor is on, with 1 being the top.

lines to use = max(LINES_MIN, min(ROWS - CURSOR_ROW, LINES_MAX))

• when cursor is in row 1: 50 (no scroll)
• when cursor is in row 20: 40 (no scroll)
• when cursor is in row 55: 10 (scrolls 5 lines to allow the LINES_MIN of 10)
• when cursor is in row 60: 10 (scrolls 10 lines)

Describe alternatives you've considered

I've considered a fixed number of lines to limit scrolling, but that impacts the usefulness when you have a whole screen available.

[marlonrichert]

@artfulrobot I like the idea. I don’t think we need two values, though. If LINES_MIN is equal to max-lines and LINES_MAX is always equal to 100%, that would be enough.

In addition to this, whenever a new prompt gets drawn, I could tell the terminal to scroll in such a way that you always have LINES_MIN empty lines below it. Then each prompt would “jump” only when it gets drawn and not while you are typing.

[artfulrobot]

@marlonrichert agree re max.

Ideally the "always have LINES_MIN empty lines below it" bit I think might need to be an option. I use another autocomplete tool (mycli, I think it is) and it's annoying that so much of my screen is reserved for completions.

[marlonrichert]

I use another autocomplete tool (mycli, I think it is) and it's annoying that so much of my screen is reserved for completions.

Thanks, that's good to know. Perhaps it would be a good tradeoff if only, say, 0.5 * LINES_MIN at the bottom of the screen would be reserved for completions? Then the screen would at least jump less when the completions kick in.

[artfulrobot]

I'm not sure that's worth it: ends up creating a problem and not fully being a solution!

I often find myself working with very shallow terminals, as I tend to use tmux split windows a lot. I suppose this would be ok if I set the variable to a percentage, but it would be quite a problem if it meant I'd be losing ROWS and could not see the results of previous commands.

[marlonrichert]

@artfulrobot I just implemented #109. Does that in any way influence this issue?

[artfulrobot]

Hmm.

So now I get a (partial list; press Ctrl+Space to expand) message with a few options, but then pressing Ctrl+Space does nothing; there's no way I can then get the completions up.

[marlonrichert]

@artfulrobot Can you please open a bug report for that? I'm unable to reproduce it.

[artfulrobot]

@marlonrichert ok, it only happens inside tmux, and only with my full .zshrc loaded. As and when I figure out which part of my config is causing Ctrl-Space to not work I'll open a bug report. It's not a mapping I know I use anywhere, but clearly something's up. Thanks.

[nisegami]

@artfulrobot what Terminal are you using? In my experience, Windows Terminal breaks Ctrl-Space.

[artfulrobot]

@nisegami Mate Terminal 1.24.0-2ubuntu1 (it's a fork from Gnome Terminal)

[marlonrichert]

@artfulrobot All right, it's there and it seems to work well. Let me know what you think. 🙂

[artfulrobot]

@marlonrichert thanks for your work on this :-)

OK, so now I don't get any completions until I press Ctrl-Space, even at the top of the window.

Pressing Ctrl-Space then does show the completions, but it also selects the first item, which I then have to delete in order to use the fuzzy competion. i.e. my use case is "I'm looknig for something. What was it? Type ls to remind myself of what's in this dir. Need to press Ctrl+Space to list the files, which then starts menu completion and selects the top dir. On seeing the list of files and reminding myself which one I wanted, I then have to either navigate with menu to it (awkward if lots of files) or press CtrlW to delete the inserted entry and then start typing the name of the file. When I do that I then don't get any completions until I press ctrl space again.

e.g. here I'm trying to enter the civicrm-cron-art.log file. But entering civicrm does not show it, entering civicrma does not show it (but does show something) until I press Ctrl-Space.

I also find I get recent-directories listed before local files/dirs which is confusing.

So to me:

• I haven't been able to observe anything about the vertical position of the cursor on the screen affecting what's shown or not.
• Not enough completions shown immediately now
• Ctrl-Space being required after every bit of input is a bit clunky - it's a good idea to use it as the initial gateway to prevent scrolling everything out of view, but having to press it after each keypress is too much
• Ctrl-Space inserting the top item from a list you've not even seen yet seems counter-intuitive.

[marlonrichert]

@artfulrobot It's not supposed to work like that at all and it doesn't on my end. Have you yet tried deleting ~/.zcompdump?

[artfulrobot]

@marlonrichert ah yes, testing it with a fresh shell, it works beautifully

I narrowed the problem down to my function which sets PS1, but I don't know why.

# This causes it to fail:
PS1='%{%F{yellow}%}%n%{%f%}%{%F{red}%}%m:%~%{%f%}'

# However, the first part works fine
PS1='%{%F{yellow}%}%n%{%f%}'
# ...and the second part works fine:
PS1='%{%F{red}%}%m:%~%{%f%}'

# It seems to be the length of it, so this works (37 chars)
PS1=1234567890123456789012345678901234567
# and this fails (38 chars)
PS1=12345678901234567890123456789012345678

(testing the above in a new shell seems to require a few more characters before it fails, but it could be to do with terminal size?, I may have resized)

[marlonrichert]

it could be to do with terminal size?, I may have resized

Yeah, Zsh doesn't handle it very well if you resize the terminal and then continue typing on the same prompt. But if you press Enter after resizing, then the issue should correct itself.

# This causes it to fail:
PS1='%{%F{yellow}%}%n%{%f%}%{%F{red}%}%m:%~%{%f%}'

Ah, this the result of an annoying way that Zsh's $# works: If used on an array of length longer than 1, it returns the array length, but if used on an array that has length 1, it will return the string length instead. Thanks for reporting; I will fix this.

[marlonrichert]

OK, should be fixed now.

[artfulrobot]

Great! I think it's working now! Many thanks!