zsh 5.6.2 When using menu select with a command that has many options, all rows in the terminal may be filled, and the context is lost (i.e. any previous commands and their output disappear past the top of the terminal, so needing to scroll back up to see them.) What I would like to do is limit the number of rows. I tried doing something like: LINES=10 grep -<tab> Which doesn't work. I'm using the following options: autolist listpacked listrowsfirst menucomplete nolistbeep zstyle ':completion:*' menu true select zstyle ':completion:*' single-ignored 'menu' Is there a way to accomplish this? Thanks
On 2020-04-05 15:38,
Dave Woodfall <dave@tty1.uk> put forth the proposition:
> zsh 5.6.2
>
> When using menu select with a command that has many options, all rows
> in the terminal may be filled, and the context is lost (i.e. any
> previous commands and their output disappear past the top of the
> terminal, so needing to scroll back up to see them.)
>
> What I would like to do is limit the number of rows.
>
> I tried doing something like:
>
> LINES=10 grep -<tab>
And typically, after asking a question we find the solution
ourselves. I defined a custom function that contains:
LINES=15 zle complete-word
It seems to work so far.
On Sun, Apr 5, 2020 at 8:01 AM Dave Woodfall <dave@tty1.uk> wrote:
>
> LINES=15 zle complete-word
>
> It seems to work so far.
This confuses ZLE a lot, as far as I can tell. Try for example typing
^L to clear the screen, then do your completion, but instead of
accepting the result, back out of the menu and try to edit the command
line.
Currently the best thing here is to set LISTMAX or the corresponding
zstyle list_max, to avoid entering the menu if it is going to scroll
too far.
Limiting the number of rows occupied by a listing seems like something
that could be added, but it probably needs more care than simply
making a temporary change to the value of the internal zterm_lines
value, because the editor needs to know what the complist module has
done to the screen.
On 2020-04-05 16:00,
Dave Woodfall <dave@tty1.uk> put forth the proposition:
> On 2020-04-05 15:38,
> Dave Woodfall <dave@tty1.uk> put forth the proposition:
> > zsh 5.6.2
> >
> > When using menu select with a command that has many options, all rows
> > in the terminal may be filled, and the context is lost (i.e. any
> > previous commands and their output disappear past the top of the
> > terminal, so needing to scroll back up to see them.)
> >
> > What I would like to do is limit the number of rows.
> >
> > I tried doing something like:
> >
> > LINES=10 grep -<tab>
>
> And typically, after asking a question we find the solution
> ourselves. I defined a custom function that contains:
>
> LINES=15 zle complete-word
I spoke too soon.
It looks using a custom function bound to the tab key causes some
problems, even without setting LINES.
Now when I get to the end and cycle back to the top, the prompt goes
up and overwrites the previous line.
This is what I'm using:
zle -N _vi-tab
_vi-tab() {
LINES=15 zle complete-word
}
bindkey '\t' _vi-tab
Any ideas?
--
Dave
On 2020-04-05 11:28, Bart Schaefer <schaefer@brasslantern.com> put forth the proposition: > On Sun, Apr 5, 2020 at 8:01 AM Dave Woodfall <dave@tty1.uk> wrote: > > > > LINES=15 zle complete-word > > > > It seems to work so far. > > This confuses ZLE a lot, as far as I can tell. Try for example typing > ^L to clear the screen, then do your completion, but instead of > accepting the result, back out of the menu and try to edit the command > line. You are correct. Using ^L or accepting the line, and probably other things, prints the current selected entry twice at the prompt. Scrolling off the end and back to the top eats the previous line. > Currently the best thing here is to set LISTMAX or the corresponding > zstyle list_max, to avoid entering the menu if it is going to scroll > too far. > > Limiting the number of rows occupied by a listing seems like something > that could be added, but it probably needs more care than simply > making a temporary change to the value of the internal zterm_lines > value, because the editor needs to know what the complist module has > done to the screen. I did try using LISTMAX, but it doesn't really help for what I want. I'll try to find some other way. -- Dave
On 2020-04-05 23:13,
Dave Woodfall <dave@tty1.uk> put forth the proposition:
> On 2020-04-05 11:28,
> Bart Schaefer <schaefer@brasslantern.com> put forth the proposition:
> > On Sun, Apr 5, 2020 at 8:01 AM Dave Woodfall <dave@tty1.uk> wrote:
> > >
> > > LINES=15 zle complete-word
> > >
> > > It seems to work so far.
> >
> > This confuses ZLE a lot, as far as I can tell. Try for example typing
> > ^L to clear the screen, then do your completion, but instead of
> > accepting the result, back out of the menu and try to edit the command
> > line.
Resetting LINES afterwards fixes ^L and the printing of the selected
word twice, but it doesn't stop the previous line from being eaten:
_vi-tab() {
local OLDLINES=$LINES
LINES=15
zle complete-word
local LINES=$OLDLINES
}
I'm not sure why it only works by setting a local LINES at the end,
but it seems to be the only combination that works.
--
Dave
On 2020-04-05 22:29, Dave Woodfall <dave@tty1.uk> put forth the proposition: > Now when I get to the end and cycle back to the top, the prompt goes > up and overwrites the previous line. > > This is what I'm using: > > zle -N _vi-tab > > _vi-tab() { > LINES=15 zle complete-word > } > > bindkey '\t' _vi-tab Turning off show-completer fixed the problem with lines being eaten, and doing a zle -R help clean up the prompt. I also turned off predict messages to be on the safe side. _vi-tab() { zstyle ':predict' verbose false local OLDLINES=$LINES LINES=15 zle complete-word zle -R local LINES=$OLDLINES } -- Dave The antibloat squad! For those interested in no bloat, minimal desktop Linux gopher://tty1.uk/1/?minimal-linux http://tty1.uk/minimal-linux #minimallinux @ chat.freenode.net
On 4/5/20, Dave Woodfall <dave@tty1.uk> wrote:
> On 2020-04-05 16:00,
> Dave Woodfall <dave@tty1.uk> put forth the proposition:
>> On 2020-04-05 15:38,
>> Dave Woodfall <dave@tty1.uk> put forth the proposition:
>> > zsh 5.6.2
>> >
>> > When using menu select with a command that has many options, all rows
>> > in the terminal may be filled, and the context is lost (i.e. any
>> > previous commands and their output disappear past the top of the
>> > terminal, so needing to scroll back up to see them.)
>> >
>> > What I would like to do is limit the number of rows.
>> >
>> > I tried doing something like:
>> >
>> > LINES=10 grep -<tab>
>>
>> And typically, after asking a question we find the solution
>> ourselves. I defined a custom function that contains:
>>
>> LINES=15 zle complete-word
>
> I spoke too soon.
>
> It looks using a custom function bound to the tab key causes some
> problems, even without setting LINES.
>
> Now when I get to the end and cycle back to the top, the prompt goes
> up and overwrites the previous line.
>
> This is what I'm using:
>
> zle -N _vi-tab
>
> _vi-tab() {
> LINES=15 zle complete-word
> }
>
> bindkey '\t' _vi-tab
>
> Any ideas?
Normally you would use zle -C for custom completer functions, but I
don't want to get involved further than this :).
--
Mikael Magnusson