Regression: broken completion on modification time

Regression: broken completion on modification time

[Dima Kogan]

Hi. Let's say I have a trivial .zshrc:

  autoload -Uz compinit
  compinit

In zsh 5.0.5 (Debian version 5.0.5-2) I can type in an interactive
shell:

  $ ls *(m

Then I press TAB to get the different ways to specify modification time,
and I get

  time specifier
  M  -- months
  d  -- days
  h  -- hours
  m  -- minutes
  s  -- seconds
  w  -- weeks
  sense
  +  -- more than
  -  -- less than

This is correct. If I update the zsh package, or use the zsh from git
and do the same thing, I get no message, and instead the completion
cycles between various integers. This is wrong, or at least very
different from before, and not obviously correct. I haven't done any
more bisecting, but hopefully this will be obvious to somebody.

Thanks
dima

Re: Regression: broken completion on modification time

[Bart Schaefer]

On Jun 12,  1:32pm, Dima Kogan wrote:
}
} In zsh 5.0.5 (Debian version 5.0.5-2) I can type in an interactive
} shell:
} 
}   $ ls *(m
} 
} Then I press TAB to get the different ways to specify modification time,
} 
} [...]  If I update the zsh package, or use the zsh from git
} and do the same thing, I get no message, and instead the completion
} cycles between various integers.

This is from zsh-workers/35718 and the behavior you are seeing assumes
that you have menu-selection enabled (which will cause a much more
extensive set of completion responses to appear in a calendar format).
There was some controversy about this when it was added and discussion
of how to keep it from kicking in if menu selection was NOT enabled,
but I guess it never got fully resolved.

In the meantime, to mostly get your old behavior back:

    zstyle ':completion:*:dates' max-matches-length 0

Re: Regression: broken completion on modification time

[Dima Kogan]

Bart Schaefer <schaefer@brasslantern.com> writes:

> On Jun 12,  1:32pm, Dima Kogan wrote:
> }
> } In zsh 5.0.5 (Debian version 5.0.5-2) I can type in an interactive
> } shell:
> } 
> }   $ ls *(m
> } 
> } Then I press TAB to get the different ways to specify modification time,
> } 
> } [...]  If I update the zsh package, or use the zsh from git
> } and do the same thing, I get no message, and instead the completion
> } cycles between various integers.
>
> This is from zsh-workers/35718 and the behavior you are seeing assumes
> that you have menu-selection enabled (which will cause a much more
> extensive set of completion responses to appear in a calendar format).
> There was some controversy about this when it was added and discussion
> of how to keep it from kicking in if menu selection was NOT enabled,
> but I guess it never got fully resolved.
>
> In the meantime, to mostly get your old behavior back:
>
>     zstyle ':completion:*:dates' max-matches-length 0

That's it! Thanks for replying so quickly.

dima

Re: Regression: broken completion on modification time

[Oliver Kiddle]

Bart wrote:
> There was some controversy about this when it was added and discussion
> of how to keep it from kicking in if menu selection was NOT enabled,
> but I guess it never got fully resolved.

It should probably at least bail out if the complist module isn't loaded as
per this patch. Or have you got any better ideas on what to check for?

> In the meantime, to mostly get your old behavior back:
>
>     zstyle ':completion:*:dates' max-matches-length 0

You might also want to try enabling menu selection. At a minimum, that
would be:
  zmodload zsh/complist
  zstyle ':completion*:default' menu 'select=0'

Oliver

diff --git a/Completion/Unix/Type/_dates b/Completion/Unix/Type/_dates
index 83397b4..549bab2 100644
--- a/Completion/Unix/Type/_dates
+++ b/Completion/Unix/Type/_dates
@@ -9,7 +9,7 @@
 #   max-matches-length : maximum number or percentage of lines to use for
 #                        completion listing, if both are specified, the
 #                        lowest takes precedence.
-#   format             : override date format
+#   date-format        : override date format
 
 local -a disp cand expl
 local userformat format spacer=1 spacing month monstart skip match
@@ -37,6 +37,7 @@ _tags dates || return 0
 _comp_mesg=yes
 _description -2V -x dates expl date
 compadd "${@:/-X/-x}" "$expl[@]" -
+zmodload -e zsh/complist || return 0
 [[ -n $PREFIX$SUFFIX ]] && return 0
 (( rows )) || return 0
 compstate[list]='packed rows'

Re: Regression: broken completion on modification time

[Bart Schaefer]

On Jun 14, 12:00am, Oliver Kiddle wrote:
}
} Bart wrote:
} > There was some controversy about this when it was added and discussion
} > of how to keep it from kicking in if menu selection was NOT enabled,
} > but I guess it never got fully resolved.
} 
} It should probably at least bail out if the complist module isn't loaded as
} per this patch. Or have you got any better ideas on what to check for?

You suggested:
> Looking for select in $_def_menu_style 

There's also the issue noted in workers/35770 (hopefully zsh.org is back
up) where the substitution of the descriptions for the actual values
(e.g. before/since for -/+) is confusing if the "format" style is not
set and the layout is poor when the "group-name" style is not set.

Re: Regression: broken completion on modification time

[Oliver Kiddle]

Bart wrote:
> } It should probably at least bail out if the complist module isn't loaded as
> } per this patch. Or have you got any better ideas on what to check for?
>
> You suggested:
> > Looking for select in $_def_menu_style 

I tried a number of combinations to see if this would work. It falls
down where the menu-select widget is used directly. Checking for
$WIDGET wouldn't help with that because the menu-select widget doesn't
cause all the completion functions to run, it just turns on menu
selection with whatever completion list we already have.

Another option would be to set a different value for compstate[list] so
users with default setup get a calendar listed: menu selection is not
actually needed for the calendar to display. I'm not sure this is
especially helpful, however, because it is only by using menu selection
to select a specific date that the function is useful.

> There's also the issue noted in workers/35770 (hopefully zsh.org is back
> up) where the substitution of the descriptions for the actual values
> (e.g. before/since for -/+) is confusing if the "format" style is not
> set and the layout is poor when the "group-name" style is not set.

Not having group-name set results in poor format in general.

Looking back at that mail, the complaint is that it does not tell you
"what the syntax is without selecting the entry itself". I prefer
to keep things compact to allow space for the calendar. How about
using a style such as the following. We have an extra-verbose style in
_path_commands and this uses that though I could be persuaded to use
just verbose. I'll allow time for comments before doing anything for
_find.

Oliver

diff --git a/Completion/Zsh/Type/_globquals b/Completion/Zsh/Type/_globquals
index 2523eb3..4eca7ba 100644
--- a/Completion/Zsh/Type/_globquals
+++ b/Completion/Zsh/Type/_globquals
@@ -1,7 +1,7 @@
 #autoload
 
 local state=qual expl char delim timespec
-local -a alts tdisp sdisp
+local -a alts tdisp sdisp tmatch smatch
 local -A specmap
 
 while [[ -n $PREFIX ]]; do
@@ -118,11 +118,26 @@ while [[ -n $PREFIX ]]; do
       timespec=$PREFIX[1]
       if ! compset -P '[Mwhmsd]' && [[ -z $PREFIX ]]; then
 	tdisp=( seconds minutes hours days weeks Months )
-        alts+=( "time-specifiers:time specifier:compadd -E 0 -d tdisp -S '' - s m h d w M" )
+	tmatch=( s m h d w M )
+	if zstyle -t ":completion:${curcontext}:time-specifiers" extra-verbose; then
+	  zstyle -s ":completion:${curcontext}:time-specifiers" list-separator sep || sep=--
+          print -v tdisp -f "%s ${sep//(#m)[%\\]/$MATCH$MATCH} %s\0" ${tmatch:^^tdisp}
+	  tdisp=( ${(0)tdisp} )
+	fi
+	alts+=( "time-specifiers:time specifier:compadd -E 0 -d tdisp -S '' -a tmatch" )
       fi
       if ! compset -P '[-+]' && [[ -z $PREFIX ]]; then
 	sdisp=( before exactly since )
-        alts+=("senses:sense:compadd -E 0 -d sdisp -S '' - + '' -")
+	smatch=( - '' + )
+	if zstyle -t ":completion:${curcontext}:senses" extra-verbose; then
+	  zstyle -s ":completion:${curcontext}:senses" list-separator sep || sep=--
+	  sdisp=( "- $sep before" "+ $sep since" )
+	  smatch=( - + )
+	else
+	  sdisp=( before exactly since )
+	  smatch=( - '' + )
+	fi
+        alts+=( "senses:sense:compadd -E 0 -d sdisp -S '' -a smatch" )
       fi
       specmap=( M months w weeks h hours m minutes s seconds '(|+|-|d)' days)
       alts+=('digits:digit ('${${specmap[(K)$timespec]}:-invalid time specifier}'):_dates -f ${${timespec/[-+]/d}:-d} -S ""' )

Re: Regression: broken completion on modification time

[Daniel Shahaf]

Oliver Kiddle wrote on Wed, Jun 15, 2016 at 18:32:57 +0200:
> Looking back at that mail, the complaint is that it does not tell you
> "what the syntax is without selecting the entry itself". I prefer
> to keep things compact to allow space for the calendar. How about
> using a style such as the following.

I like this particularly for the "sense" portion of the completion: with
this patch and extra-verbose set, the show-ambiguity style actually
highlights the "next typeable character", just like it does everywhere
else.  For the "time specifier" portion the change is also welcome.

However, with this patch and extra-verbose, the «'' - exactly»
alternative doesn't show.  (It's not just "hidden"; each of "- --
before" and "+ -- after" take half of $COLUMNS.)

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
completion at all.  It still did that with extra-verbose and
group-name='' set, I haven't debugged further yet.

> We have an extra-verbose style in _path_commands and this uses that
> though I could be persuaded to use just verbose.

I don't have an intuition for which of them is more appropriate, but
whichever it ends up being, I will set it in my config...

Cheers,

Daniel

Re: Regression: broken completion on modification time

[Oliver Kiddle]

Daniel Shahaf wrote:
> I like this particularly for the "sense" portion of the completion: with

I think I'll just use the verbose style then.
(As an aside, I notice _git has a max-verbose style. Not sure if we can
change that for consistency with _path_commands.)

> However, with this patch and extra-verbose, the «'' - exactly»
> alternative doesn't show.  (It's not just "hidden"; each of "- --
> before" and "+ -- after" take half of $COLUMNS.)

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.

> 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
> completion at all.  It still did that with extra-verbose and
> group-name='' set, I haven't debugged further yet.

You need to enable menu selection:
  zstyle ':completion*:default' menu 'select=0'
Pressing Ctrl-D (list-choices) a couple of times will also work.

This is a consequence of the line in _dates which does:
  compstate[list]='packed rows'

This could be adjusted so normal completion would dump the calendar.
But is a calendar without menu selection at all useful? Menu selection's
ability to convert a calendar date into relative days is the main use. 

Oliver

Re: Regression: broken completion on modification time

[Bart Schaefer]

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).

Re: Regression: broken completion on modification time

[Nikolay Aleksandrovich Pavlov (ZyX)]

17.06.2016, 21:11, "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"?

I would say “yes” just to check what possibilities is it talking about. Question is why would I hit `<Tab>` in first place: if I did not see this discussion I would not ever suggest that completing a (mostly) numeric and in any case very short argument to `m` has any sense.

Also if I write `ls *(m)` with cursor after `m` and hit `<Tab>` I get “Completing: digit (invalid time specifier)” (nothing if I use `autoload compinit ; compinit` in `zsh -f`, or “Completing: `files'” with no list after `unsetopt completeinword`): the second main reason why I would not try this in the first place is that when you face the necessity of creating nested parenthesis it is far more convenient to use something that will write both parens at once (like various Vim autoclose plugins or my `,s` -> “`()<Left>`” binding) and place cursor in between, otherwise it may be too hard to get the expression closed properly, and zsh completion usually is inadequate if current word continues after the cursor (still sometimes I make use of “completeinword”, but this does not apply to any glob expressions with parenthesis/braces/brackets/etc). I do not think that I am the only programmer that is using this in zsh.

Particularly, the most failing thing is `ls foo{bar<Tab>}`: this usually either does nothing or expands immediately if I already happened to write a comma.

> 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).

Re: Regression: broken completion on modification time

[Oliver Kiddle]

"Nikolay Aleksandrovich Pavlov (ZyX)" wrote:
>
> I would say “yes” just to check what possibilities is it talking about. Question is why would I hit `<Tab>` in first place: if I did not see this discussion I would not ever suggest that completing a (mostly) numeric and in any case very short argument to `m` has any sense.

It may not be useful to "complete" short things but the descriptions can
be very useful. There's quite a few cases where this is done, e.g.:
  printf '%<tab>
  : ${(<tab>
  !!:<tab>

> Also if I write `ls *(m)` with cursor after `m` and hit `<Tab>` I get “Completing: digit (invalid time specifier)” (nothing if I use `autoload compinit ; compinit` in `zsh -f`, or “Completing: `files'” with no list after `unsetopt completeinword`):

Stripping suffixes is easily forgotten when writing completion functions
and this was one such case. Patch below should fix this and make
it indicate the default of "days" when there is no time specifier.

With `unsetopt completeinword', you have the equivalent of moving the
cursor to the end of the word. *(m) is an invalid glob matching no
files. You might also want to consider using the _prefix completer which
ignores the entire suffix.

> Particularly, the most failing thing is `ls foo{bar<Tab>}`: this usually either does nothing or expands immediately if I already happened to write a comma.

Are you using the _expand completer or the default expand-or-complete
widget to do expansion.

Braces are largely handled by internal C code: _prefix doesn't seem able
to help here. You can prevent the expansion with something like:
  zstyle -e ':completion:*::::' completer \
    'reply=( _oldlist _complete ); (( $#SUFFIX )) || reply[1]+=( _expand )'

Oliver

diff --git a/Completion/Unix/Type/_files b/Completion/Unix/Type/_files
index fe0780a..6987824 100644
--- a/Completion/Unix/Type/_files
+++ b/Completion/Unix/Type/_files
@@ -7,6 +7,7 @@ local ret=1
 # we don't want to complete them multiple times (for each file pattern).
 if _have_glob_qual $PREFIX; then
   compset -p ${#match[1]}
+  compset -S '[^\)\|\~]#(|\))'
   if [[ $_comp_caller_options[extendedglob] == on ]] && compset -P '\#'; then
     _globflags && ret=0
   else
diff --git a/Completion/Unix/Type/_path_files b/Completion/Unix/Type/_path_files
index 14c4cc7..6a1e89f 100644
--- a/Completion/Unix/Type/_path_files
+++ b/Completion/Unix/Type/_path_files
@@ -17,6 +17,7 @@ local -a match mbegin mend
 if _have_glob_qual $PREFIX; then
   local ret=1
   compset -p ${#match[1]}
+  compset -S '[^\)\|\~]#(|\))'
   if [[ $_comp_caller_options[extendedglob] == on ]] && compset -P '\#'; then
     _globflags && ret=0
   else
diff --git a/Completion/Zsh/Type/_globquals b/Completion/Zsh/Type/_globquals
index 2523eb3..ed9c008 100644
--- a/Completion/Zsh/Type/_globquals
+++ b/Completion/Zsh/Type/_globquals
@@ -125,7 +125,7 @@ while [[ -n $PREFIX ]]; do
         alts+=("senses:sense:compadd -E 0 -d sdisp -S '' - + '' -")
       fi
       specmap=( M months w weeks h hours m minutes s seconds '(|+|-|d)' days)
-      alts+=('digits:digit ('${${specmap[(K)$timespec]}:-invalid time specifier}'):_dates -f ${${timespec/[-+]/d}:-d} -S ""' )
+      alts+=('digits:digit ('${${specmap[(K)${timespec:-d}]}:-invalid time specifier}'):_dates -f ${${timespec/[-+]/d}:-d} -S ""' )
       _alternative $alts
       return
     fi

Re: Regression: broken completion on modification time

[Nikolay Aleksandrovich Pavlov (ZyX)]

18.06.2016, 01:09, "Oliver Kiddle" <okiddle@yahoo.co.uk>:
> "Nikolay Aleksandrovich Pavlov (ZyX)" wrote:
>>  I would say “yes” just to check what possibilities is it talking about. Question is why would I hit `<Tab>` in first place: if I did not see this discussion I would not ever suggest that completing a (mostly) numeric and in any case very short argument to `m` has any sense.
>
> It may not be useful to "complete" short things but the descriptions can
> be very useful. There's quite a few cases where this is done, e.g.:
>   printf '%<tab>
>   : ${(<tab>
>   !!:<tab>
>
>>  Also if I write `ls *(m)` with cursor after `m` and hit `<Tab>` I get “Completing: digit (invalid time specifier)” (nothing if I use `autoload compinit ; compinit` in `zsh -f`, or “Completing: `files'” with no list after `unsetopt completeinword`):
>
> Stripping suffixes is easily forgotten when writing completion functions
> and this was one such case. Patch below should fix this and make
> it indicate the default of "days" when there is no time specifier.
>
> With `unsetopt completeinword', you have the equivalent of moving the
> cursor to the end of the word. *(m) is an invalid glob matching no
> files. You might also want to consider using the _prefix completer which
> ignores the entire suffix.
>
>>  Particularly, the most failing thing is `ls foo{bar<Tab>}`: this usually either does nothing or expands immediately if I already happened to write a comma.
>
> Are you using the _expand completer or the default expand-or-complete
> widget to do expansion.

I have `_expand _complete` set as completer zstyle. Though I have rechecked this with “zsh -f; autoload compinit; compinit” before posting, don’t know what is being used here.

>
> Braces are largely handled by internal C code: _prefix doesn't seem able
> to help here. You can prevent the expansion with something like:
>   zstyle -e ':completion:*::::' completer \
>     'reply=( _oldlist _complete ); (( $#SUFFIX )) || reply[1]+=( _expand )'
>
> Oliver
>
> diff --git a/Completion/Unix/Type/_files b/Completion/Unix/Type/_files
> index fe0780a..6987824 100644
> --- a/Completion/Unix/Type/_files
> +++ b/Completion/Unix/Type/_files
> @@ -7,6 +7,7 @@ local ret=1
>  # we don't want to complete them multiple times (for each file pattern).
>  if _have_glob_qual $PREFIX; then
>    compset -p ${#match[1]}
> + compset -S '[^\)\|\~]#(|\))'
>    if [[ $_comp_caller_options[extendedglob] == on ]] && compset -P '\#'; then
>      _globflags && ret=0
>    else
> diff --git a/Completion/Unix/Type/_path_files b/Completion/Unix/Type/_path_files
> index 14c4cc7..6a1e89f 100644
> --- a/Completion/Unix/Type/_path_files
> +++ b/Completion/Unix/Type/_path_files
> @@ -17,6 +17,7 @@ local -a match mbegin mend
>  if _have_glob_qual $PREFIX; then
>    local ret=1
>    compset -p ${#match[1]}
> + compset -S '[^\)\|\~]#(|\))'
>    if [[ $_comp_caller_options[extendedglob] == on ]] && compset -P '\#'; then
>      _globflags && ret=0
>    else
> diff --git a/Completion/Zsh/Type/_globquals b/Completion/Zsh/Type/_globquals
> index 2523eb3..ed9c008 100644
> --- a/Completion/Zsh/Type/_globquals
> +++ b/Completion/Zsh/Type/_globquals
> @@ -125,7 +125,7 @@ while [[ -n $PREFIX ]]; do
>          alts+=("senses:sense:compadd -E 0 -d sdisp -S '' - + '' -")
>        fi
>        specmap=( M months w weeks h hours m minutes s seconds '(|+|-|d)' days)
> - alts+=('digits:digit ('${${specmap[(K)$timespec]}:-invalid time specifier}'):_dates -f ${${timespec/[-+]/d}:-d} -S ""' )
> + alts+=('digits:digit ('${${specmap[(K)${timespec:-d}]}:-invalid time specifier}'):_dates -f ${${timespec/[-+]/d}:-d} -S ""' )
>        _alternative $alts
>        return
>      fi

Re: Regression: broken completion on modification time

[Bart Schaefer]

On Jun 17, 10:10pm, Nikolay Aleksandrovich Pavlov (ZyX) wrote:
}
} I would say "yes" just to check what possibilities is it talking
} about. Question is why would I hit `<Tab>` in first place: if I did
} not see this discussion I would not ever suggest that completing a
} (mostly) numeric and in any case very short argument to `m` has any
} sense.

I see Oliver has already replied, but:  Don't confuse the example (of
completing in a glob qualifier) with the intent of the discussion,
which is about presentation of the result for _dates.  You could just
as easily be completing after "find -mtime ".

Re: Regression: broken completion on modification time

[Nikolay Aleksandrovich Pavlov (ZyX)]

18.06.2016, 01:34, "Bart Schaefer" <schaefer@brasslantern.com>:
> On Jun 17, 10:10pm, Nikolay Aleksandrovich Pavlov (ZyX) wrote:
> }
> } I would say "yes" just to check what possibilities is it talking
> } about. Question is why would I hit `<Tab>` in first place: if I did
> } not see this discussion I would not ever suggest that completing a
> } (mostly) numeric and in any case very short argument to `m` has any
> } sense.
>
> I see Oliver has already replied, but: Don't confuse the example (of
> completing in a glob qualifier) with the intent of the discussion,
> which is about presentation of the result for _dates. You could just
> as easily be completing after "find -mtime ".

Where I have exactly the same question: `-mtime` argument is still numeric (now without “mostly” if I am not mistaking) and short. And _dates is not used anywhere else as far as I see, `ag` finds it only in `/usr/share/zsh/5.2/functions/Completion/Zsh/_globquals` and `/usr/share/zsh/5.2/functions/Completion/Unix/_find` when searching in `/usr/share/zsh`.

Also I cannot find `_dates` in `man zshall`, so developers probably will not use it in third-party completions. Especially given that it is the same directory with _find (which means that without looking at the source code of that file and without knowing about `-mtime` completion one will think that there is `dates` *nix command, unless I am missing something and there is a list of helper functions anywhere outside of man pages, generated automatically because `ag` cannot find it in zsh git repository).

Re: Regression: broken completion on modification time

[Bart Schaefer]

On Jun 18,  1:49am, Nikolay Aleksandrovich Pavlov (ZyX) wrote:
}
} Where I have exactly the same question: `-mtime` argument is still
} numeric (now without "mostly" if I am not mistaking) and short.

The intent is to use the complist module / menu selection to present
a calendar so that you can point at a date to generate the number of
days forward or backward that correspond to that date, rather than
having to work out the delta yourself and then type it.  It's not
about how many keystrokes are being saved, in this case.

(The reason for this thread is to discuss not doing this when complist
or selection are not in use.)

} Also I cannot find `_dates` in `man zshall`

It was introduced last July as an experiment; as I mentioned in an
earlier message on this thread, several things about it were never
properly resolved.  Documentation appears to have been another.

Re: Regression: broken completion on modification time

[Oliver Kiddle]

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'

Re: Regression: broken completion on modification time

[Bart Schaefer]

On Jun 18,  1:50am, Oliver Kiddle wrote:
}
} 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?

I believe
	compstate[old_list]=''
(or any value other than 'keep', actually) is intended to do that?  But
I'm unclear in which circumstances there is an opportunity to twaddle
that, as the doc description refers to "the widget" rather than "the
completer" or "completion function".

Re: Regression: broken completion on modification time

[Daniel Shahaf]

Oliver Kiddle wrote on Fri, Jun 17, 2016 at 18:19:43 +0200:
> (As an aside, I notice _git has a max-verbose style. Not sure if we can
> change that for consistency with _path_commands.)

Change it how?  I don't see how max-verbose and extra-verbose can be
combined, since the former is an int and the latter a bool.

> Daniel Shahaf wrote:
> > However, with this patch and extra-verbose, the «'' - exactly»
> > alternative doesn't show.  (It's not just "hidden"; each of "- --
> > before" and "+ -- after" take half of $COLUMNS.)
> 
> 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.
> 

As you said later, it'd have to show as «'' -- exactly» or « --
exactly».  (Or we could teach the C code to take '*(om=5)' for "exactly
five")

I mentioned the lack of "exactly" as a difference, but now that I think
about it, I suppose I think the "exactly" _should_ be displayed: firstly,
because displaying more options is better; secondly, because it is
displayed in non-verbose mode, and it'd be odd for setting the "verbose"
style to cause fewer options to be offered.

Another display option would be to use a dummy "string without a match"
as Bart said (compadd -E1) for something like

    → sense
    (for the "exactly" sense, skip/omit this field)
    + -- before
    - -- since

> > 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
> > completion at all.  It still did that with extra-verbose and
> > group-name='' set, I haven't debugged further yet.
> 
> You need to enable menu selection:
>   zstyle ':completion*:default' menu 'select=0'
> Pressing Ctrl-D (list-choices) a couple of times will also work.

Got it, thanks.

Daniel

Re: Regression: broken completion on modification time

[Oliver Kiddle]

Daniel Shahaf wrote:
> Change it how?  I don't see how max-verbose and extra-verbose can be
> combined, since the former is an int and the latter a bool.

Ah, ok. I didn't check out the details of max-verbose.

> Another display option would be to use a dummy "string without a match"
> as Bart said (compadd -E1) for something like
>
>     → sense
>     (for the "exactly" sense, skip/omit this field)

I've gone with "sense [default exactly]" as the explanation heading.
We've used square brackets to indicate defaults elsewhere.
The patch now also covers find.

Oliver

diff --git a/Completion/Unix/Command/_find b/Completion/Unix/Command/_find
index e736f32..3854d6c 100644
--- a/Completion/Unix/Command/_find
+++ b/Completion/Unix/Command/_find
@@ -1,7 +1,7 @@
 #compdef find gfind
 
-local curcontext="$curcontext" state_descr variant
-local -a state line args alts
+local curcontext="$curcontext" state_descr variant default
+local -a state line args alts disp smatch
 
 _pick_variant -r variant gnu=GNU $OSTYPE -version
 
@@ -101,7 +101,7 @@ case $variant in
       '-D[print diagnostics]:debug option:(help tree search stat rates opt exec)'
       '-O+[enable query optimisation]:level:(1 2 3)'
       '*-daystart'
-      '-regextype:regexp syntax:(emacs posix-awk posix-basic posix-egrep posix-extended)'
+      '-regextype:regexp syntax:(help findutils-default awk egrep ed emacs gnu-awk grep posix-awk posix-basic posix-egrep posix-extended posix-minimal-basic sed)'
       '*-warn'
       '*-nowarn'
       '*-xautofs'
@@ -147,13 +147,21 @@ _arguments -C $args \
   '*-user:user:_users' \
   '*-xdev' \
   '*-a' '*-o' \
-  '*:directory:_files -/'
+  '(-D -E -H -L -O -P -f -s -x --help --version)*:directory:_files -/'
 
 if [[ $state = times ]]; then
   if ! compset -P '[+-]' || [[ -prefix '[0-9]' ]]; then
-    disp=( 'before' 'exactly' 'since' )
     compstate[list]+=' packed'
-    alts=( "senses:sense:compadd -V times -S '' -d disp - + '' -" )
+    if zstyle -t ":completion:${curcontext}:senses" verbose; then
+      zstyle -s ":completion:${curcontext}:senses" list-separator sep || sep=--
+      default=" [default exactly]"
+      disp=( "- $sep before" "+ $sep since" )
+      smatch=( - + )
+    else
+      disp=( before exactly since )
+      smatch=( - '' + )
+    fi
+    alts=( "senses:sense${default}:compadd -V times -S '' -d disp -a smatch" )
   fi
   alts+=( "times:${state_descr}:_dates -f d" )
   _alternative $alts
diff --git a/Completion/Zsh/Type/_globquals b/Completion/Zsh/Type/_globquals
index ed9c008..6eef168 100644
--- a/Completion/Zsh/Type/_globquals
+++ b/Completion/Zsh/Type/_globquals
@@ -1,7 +1,7 @@
 #autoload
 
-local state=qual expl char delim timespec
-local -a alts tdisp sdisp
+local state=qual expl char delim timespec default
+local -a alts tdisp sdisp tmatch smatch
 local -A specmap
 
 while [[ -n $PREFIX ]]; do
@@ -118,11 +118,27 @@ while [[ -n $PREFIX ]]; do
       timespec=$PREFIX[1]
       if ! compset -P '[Mwhmsd]' && [[ -z $PREFIX ]]; then
 	tdisp=( seconds minutes hours days weeks Months )
-        alts+=( "time-specifiers:time specifier:compadd -E 0 -d tdisp -S '' - s m h d w M" )
+	tmatch=( s m h d w M )
+	if zstyle -t ":completion:${curcontext}:time-specifiers" verbose; then
+	  zstyle -s ":completion:${curcontext}:time-specifiers" list-separator sep || sep=--
+          print -v tdisp -f "%s ${sep//(#m)[%\\]/$MATCH$MATCH} %s\0" ${tmatch:^^tdisp}
+	  tdisp=( ${(0)tdisp} )
+	fi
+	alts+=( "time-specifiers:time specifier:compadd -E 0 -d tdisp -S '' -a tmatch" )
       fi
       if ! compset -P '[-+]' && [[ -z $PREFIX ]]; then
 	sdisp=( before exactly since )
-        alts+=("senses:sense:compadd -E 0 -d sdisp -S '' - + '' -")
+	smatch=( - '' + )
+	if zstyle -t ":completion:${curcontext}:senses" verbose; then
+	  zstyle -s ":completion:${curcontext}:senses" list-separator sep || sep=--
+	  default=" [default exactly]"
+	  sdisp=( "- $sep before" "+ $sep since" )
+	  smatch=( - + )
+	else
+	  sdisp=( before exactly since )
+	  smatch=( - '' + )
+	fi
+        alts+=( "senses:sense${default}:compadd -E 0 -d sdisp -S '' -a smatch" )
       fi
       specmap=( M months w weeks h hours m minutes s seconds '(|+|-|d)' days)
       alts+=('digits:digit ('${${specmap[(K)${timespec:-d}]}:-invalid time specifier}'):_dates -f ${${timespec/[-+]/d}:-d} -S ""' )