Re: accept-and-hold in interactive mode of menu select

[Bart Schaefer <schaefer@xxxxxxxxxxxxxxxx>]

On Dec 16, 11:18pm, Jun T. wrote:
}
} >>> type ab
} 
} % ls test/ab
} interactive: test/abb[]
} abbb*  abbc
} 
} >>> hit ^L
} 
} % ls test/ab test/abbc
} abbb  abbc*
} 
} Note that the 1st word on the command line is not updated to test/abbb.

I'm not entirely sure that's wrong; accept means to accept what is on the
command line, not to accept what is highlighted in the menu.  You have to
finish the action of choosing one of the menu items so that the command
line is updated, before you accept.

On the other hand I can see where there might be confusion about that,
and this is a little-used and therefore little-tested corner of complist,
so implicitly choosing the currently highlighted item (even though in
this situation it will always be whichever one came first in sort order)
may be a reasonable thing to do.

} >>> type ab
} 
} % ls test/{ab
} interactive: test/{abb[]
} abbb* abbc
} 
} >>> hit ^L
} 
} then zsh goes into an infinite loop; ^C does not work.

I'm not able to reproduce this with a completion that does not use a
brace expansion, so I wonder if there's something about that which is
involved.  Brace expansion has always been a bit of a problem child,
and in a brace expansion you're accepting a partial completion rather
than an entire command-line "word", so we try to re-enter selection
in a different state.

} I tried the patch below, and it does avoid the infinite loop. But it
} is far from sufficient; for example, the ^L above now gives (as I
} expect)
} 
} % ls test/{abbb,abbc
} 
} but if I hit ^K to go to the interactive mode again, then I get
} 
} % ls test/{ab

Entering interactive mode always returns to the original state of the
command line before menu-selection was started.   I don't remember why
this is the case, or if it was intentional.

-- 
Barton E. Schaefer