Re: Regression: broken completion on modification time

[Oliver Kiddle <okiddle@yahoo.co.uk>]

Bart wrote:
> } How would you want to present the exactly match given that it inserts
> } nothing? In the past with the match -- description form, we didn't
> } include it. With the description only form it is less out-of-place.
>
> Isn't there a way to stick a dummy match into the listing just to take
> up space so that only the description will appear?

Without the verbose style, descriptions are
  »before«, »exactly« and »since«
You can select »exactly« but it inserts nothing.
With verbose (and the recent patch), they are:
  »+ -- before« and »- -- since«  exactly is omitted
So if exactly is to be included there as requested by Daniel, it would
need to be something like »'' -- exactly«, » -- exactly« or just
»exactly«.

> I think that in any case where the calendar won't be displayed [almost]
> immediately, an entirely different set of matches should be passed to
> compadd, or at least they should be added in a different order.  The

Okay, lets try the following. Looking at _main_complete, checking
$MENUSELECT is perhaps better than $_def_menu_style.

If someone has a setup where they defer menu selection and are bothered
that they now miss out on the calendar, we can add a style or something.
Or is there some way to prevent the completion system from saving the
old_list?

Matches can't be added in a different order while preserving the layout.
Without the layout, the numbers alone are useless regardless of their
order.

Oliver

diff --git a/Completion/Unix/Type/_dates b/Completion/Unix/Type/_dates
index 83397b4..0b9cead 100644
--- a/Completion/Unix/Type/_dates
+++ b/Completion/Unix/Type/_dates
@@ -37,6 +37,7 @@ _tags dates || return 0
 _comp_mesg=yes
 _description -2V -x dates expl date
 compadd "${@:/-X/-x}" "$expl[@]" -
+[[ -z $MENUSELECT && $WIDGET != menu-select ]] && return
 [[ -n $PREFIX$SUFFIX ]] && return 0
 (( rows )) || return 0
 compstate[list]='packed rows'