Re: _complete: insert unambiguous when globbing

[Tomasz Pala <gotar@xxxxxxxxxx>]

On Wed, Jan 05, 2022 at 20:46:43 +0100, Tomasz Pala wrote:

> However since it sacrifices ZLE-provided pattern it's not perfect.
> 
> $ cd empty
> $ touch 2021.12.29-14:41:02.xz 2021.12.29-19:41:02.xz 2021.12.30-03:41:03.xz 2021.12.30-14:41:04.xz 2021.12.30-19:41:02.xz 2021.12.31-03:41:02.xz 2021.12.31-14:41:04.xz 2021.12.31-19:41:03.xz
> 
> $ ls 2*04[tab]	=> 2021.12.3
> files
> 2021.12.30-14:41:04.xz  2021.12.31-14:41:04.xz
> 
> so the compstate[old_list]=keep was required for the second [tab] not to
> follow the updated ZLE contents. It works like a charm, but I wonder -
> what cases would be broken by compstate[old_list]=keep with such a weak
> condition? It would be much safer to have something like:
> 
> if [[ $PREFIX = *'*'* ]]; then
> 	compstate[pattern_insert]=not_menu
> 	compstate[eat_globbing]=yes
> elif [ "$compstate[eat_globbing]" = 'true' ]; then
> 	compstate[old_list]=keep
> fi
> 
> but I can't find a way to pass this down.

OK, this was pretty straightforward:

if [[ $PREFIX = *'*'* ]]; then
	compstate[pattern_insert]=not_menu
	_eat_asterisk=true
elif [ "$_eat_asterisk" = 'true' ]; then
	compstate[old_list]=keep
fi


It sacrifices *-using glob only (more robust test required?) because
that signals rough pattern (we do not want to break some refined ones).


And the problem is "provided pattern" vs "unambiguous prefix"...

In general this problem is not trivial, since preserving the ZLE-provided
pattern while completing unambiguous part would require to distinguish,
how much of that pattern was already consumed and needs to be
dropped, preserving the rest; the remaining part must match the same
items being prepended by the unambiguous part.


Having said that - does this behaviour deserve upstreaming with it's own
zstyle, or is it too hacky?

This allows for incremental completion with repeating (manual) globbing
provisioning, which seems fine for some quick and dirty patterns like *z
(for *.xz files), tastes best with undo/redo in finger memory.

-- 
Tomasz Pala <gotar@xxxxxxxxxxxxx>