Re: reduce number of lines available for completion

On Mon, Feb 03, 2025 at 15:03:39 +0100, Tomasz Pala wrote:

>> function short-menu-complete {
>>   integer LINES=$((LINES/2))
>>   zle menu-complete
>>   zle -I
>> }
>> zle -N short-menu-complete
> 
> 1. Apparently changing LINES forces zle menu-complete to repeat the
> current buffer and then redraw it -- step by step "buffer-cast":
[...]
> 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:
[...]
> - as the line wraps, it isn't restored and remains duplicated, with
> newly selected completions being inserted after and piling up...

This one is solved by issuing one more `zle redisplay`, before
	zle menu-expand-or-complete
- however, this seems racy... When another command separates them, the
LINES are reset, so:

function short-menu-complete {
	local _saved_LINES="$LINES"
	integer LINES=$((LINES/2))
	zle redisplay
	usleep 1	# this one makes LINES/2 ineffective
	zle menu-expand-or-complete
	LINES="$_saved_LINES"
	zle redisplay
}

doesn't work. Fixing this... by reconfiguring terminal itself:

function short-menu-complete {
	local _saved_LINES="$LINES"
	stty -F $TTY rows $((LINES/2))
		COMPLETION_ACTIVE=1
	zle menu-expand-or-complete
		COMPLETION_ACTIVE=0
	stty -F $TTY rows "$_saved_LINES"
	LINES="$_saved_LINES"
}

- apparently no `zle redisplay` needed now.

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

I've managed to convert this one to be better visible:

function TRAPINT {
	if [[ $COMPLETION_ACTIVE = 1 ]]; then
		COMPLETION_ACTIVE=0

		# this prevents clearing entire screen
		# - but also from retracting entries...
		# for the cases described below
		zle execute-named-cmd forward-char

		zle -M "completion cancelled: $LINES"
		usleep 600000

		stty -F $TTY rows "$_saved_LINES"
		LINES="$_saved_LINES"
		zle -M "completion cancelled: $LINES"
		usleep 600000
	fi
	return 1
}

Now, when an item is chosen from menu-select using arrows, everything
works as expected.
But - item selected initially (i.e. no cursor movement) OR items selected
and highlighted after alt-a insertion (not followed by cursor keys) don't
get removed from the buffer.

So: for "a" "b" "c" files:
$ ls [tab] [right arrow] [ctrl-c]
$ ls	-- good

$ ls [tab] [ctrl-c]
$ ls a	-- wrong, "a" not cleared

$ ls [tab] [right arrow] [alt-a -- accept-and-hold]
$ ls b c -- wrong, "b" and "c" should be cleared.


The question is: what is the difference? I see none in context
(observed in TRAPINT environment)...

-- 
Tomasz Pala <[email protected]>