Re: completion oddity

[Bart Schaefer <schaefer@xxxxxxxxxxxxxxxx>]

On May 22,  4:06pm, Danek Duvall wrote:
}
} So if I set up my own style processing in order to override this
} behavior (both the earliness and the use of the empty value) as you
} suggested to Greg, would it be kosher to use the matcher-list style,
} or would I want to use my own style name?

Doesn't really matter.  Using the matcher-list name means that any
definition of that for any less-specific context will end up applying 
to your more specific situation, but if you're planning always to
provide the most specific definition then that won't matter.

} > }     gtar --show--names<TAB>
} > } 
} > } and it beeps and moves me to between the second double-hyphen,
} > } then after another beep, starts cycling between the two. If I
} > } just have "--show" there, then it ends up cycling among four
} > } alternatives.
} 
}     --show-defaults
}     --show-omitted-dirs
}     --show-transformed-names
}     --show-stored-names

Oh, well, that all makes sense.  When you have all four possibilities
there are no common suffixes, and when you do have a common suffix
there are the same number of words; in neither case is there the
possibility of resolving the ambiguity.

On May 22,  6:03pm, Danek Duvall wrote:
} Subject: Re: completion oddity
}
} ... is there some way, either in a user's configuration or within
} a single completion function, to turn off the "end with the same
} substring" completion, while maintaining the dash-separates-words
} aspect of the completion [...?]

In fact, there is, and it's at once so obvious and so unintuitive
that I'm quite sure it wasn't done on purpose.

Define _k this way:

    _k() { _arguments --really-r1-word --r1-word }

The specifications passed to _arguments are tried in order, so if
the longer one (which I suspect means the one having the most words
rather than the most characters) is tried first, the ambiguity is
re-discovered and you get menu completion.