Re: Regression: broken completion on modification time

[Bart Schaefer <schaefer@brasslantern.com>]

On Jun 17,  6:19pm, Oliver Kiddle 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?
 
} > I tried to reproduce this in 'zsh -f', but "echo *(m<TAB>" simply cycled
} > between various integers after the 'm'; it didn't give the calendar
} 
} This could be adjusted so normal completion would dump the calendar.
} But is a calendar without menu selection at all useful?

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
current ordering of the numbers etc. makes very little sense without
the visual of the calendar, and they're inserted directly into the
command line so completing after e.g. "ls *(m" you get things like

    *(m0
    *(m32
    *(m31
    ...
    *(m17
    *(ms
    *(mm
    *(mh
    *(md
    *(mw
    *(mM
    *(m+
    *(m-
    *(m108
    *(m107
    ...

The user is left wondering "why 0 then 32 ?" and will never get to the
s/m/h/d/w/M unless he perseveres whacking TAB 15 times, at which point
"why did it stop at 17 ?"

Also even when using list-choices:

torch% ls *(m0
zsh: do you wish to see all 233 possibilities (18 lines)? 

If I don't know there's a calendar coming, why would I answer "yes"?
And if menu selection is not enabled, I won't have any idea which of
the elements being inserted on the command line corresponds to what
part of the calendar even after I can see it (you already alluded to
this in a previous message).