Re: reduce number of lines available for completion

[Tomasz Pala <gotar@xxxxxxxxxx>]

Thanks for the suggestions and insights!

On Sun, Feb 02, 2025 at 12:36:06 -0800, Bart Schaefer wrote:

> You need to create a wrapper widget around the whole operation, something like
> 
> function short-menu-complete {
>   integer LINES=$((LINES/2))
>   zle menu-complete
>   zle -I
> }
> zle -N short-menu-complete

I've been trying similar approaches (and did test above of course),
however there are several problems with these.

1. Apparently changing LINES forces zle menu-complete to repeat the
current buffer and then redraw it -- step by step "buffer-cast":

$ ls a b c[tab]
$ ls a b cls a b c
$ ls a b c[menu selection active]

and while some screen flickering it causes might be acceptable,
as soon as buffer lenght is more than half of $COLUMNS it fails to
restore the original buffer:
----------------screen--------widt|h----------------------------------
$ ls aaaaaaaa bbbbbbbbbb ccccccccccccc[tab]
$ ls aaaaaaaa bbbbbbbbbb cccccccccccccls aaaaaaaa bbbbbbbbbb ccccccccc
cccc
$ ls aaaaaaaa bbbbbbbbbb cccccccccccccls aaaaaaaa bbbbbbbbbb ccccccccc
cccc[menu selection active, inserting here]

- as the line wraps, it isn't restored and remains duplicated, with
newly selected completions being inserted after and piling up...

This issue seems to happen due to some terminal recalculations during
completion (?), so apparently changing LINES here is too late...

Well, OK - changing terminal parameters seems to be hackery anyway,
shouldn't expect this to work reliably.

> created with zle -C) that invokes completion inside.  The "zle -I"
> alerts the editor that completion changed the display during execution
> of the wrapper widget.

2. The `zle -I` seems to create new line (leaving behind previous one),
but apparently `zle redisplay` takes care of it.

3. During the test I've found something looking like a bug (SEGV).
My reproducer:

================================
setopt no_beep

autoload -U compinit
compinit

zstyle ':completion:*' list-prompt ''
zstyle ':completion:*' menu select=long-list select=1

function interruptible-expand-or-complete {
	local _saved_LINES="$LINES"
	integer LINES=$((LINES/2))
	COMPLETION_ACTIVE=1
	zle menu-expand-or-complete
	zle redisplay
	# COMPLETION_ACTIVE=0 - apparently not needed
}
zmodload zsh/complist
zle -N interruptible-expand-or-complete
bindkey -e '^I' interruptible-expand-or-complete

function TRAPINT {
	# BTW - why [[ such ]] not [ plain ] tests?
	if [[ $COMPLETION_ACTIVE = 1 ]]; then
		LINES="$_saved_LINES"
		zle -M "completion cancelled: $LINES"
		sleep 2
		zle send-break
	fi
	return 1
}
================================

I've noticed that "completion cancelled" message is not being displayed
when ctrl-c happens at the _very_ first menu-selection (in terms of
"just entered" not "first position" - moving around fixes some internal
state, even when moved back to first entry).

When playing with this I've found, that `zle send-break` in this state
terminates zsh with segfault, which confirms my suspicion something is
not properly initialized at menu-selection start.

This is zsh-5.9.


As for the recursive-edit method, I have no idea how to approach this...
I've been also reading about PREDISPLAY/POSTDISPLAY:
https://www.zsh.org/mla/workers//2002/msg00932.html
and narrow-to-region, but it all seems to be a dead end to me.


I'm just thinking if that shouldn't be just a regular parameter.

-- 
Tomasz Pala <gotar@xxxxxxxxxxxxx>