Re: file completion(?) erases word typed

[Bart Schaefer <schaefer@xxxxxxxxxxxxxxxx>]

On Aug 24,  7:13pm, Daniel Shahaf wrote:
}
} I don't know why list-choices would act differently to expand-or-complete.

Some additional clues ...

Using my example (because I don't have gtk-* installed):

torch% f /usr/local/bin/zsh-5<TAB>

Here the word on the line is not yet the longest common prefix of any of
the possible matches.  So we enter compresult.c:do_ambiguous() and on
line 786 we delete the entire word on the line, but ainfo->line has a
prefix, which is inserted by cline_str() at line 789.  This happens to
be the same word that's already on the line.  Because a prefix has
been inserted, the set of matching suffixes is listed.

Next with:

torch% f /usr/local/bin/zsh-5.<TAB>

We arrive in do_ambiguous() and hit line 786 as before, but this time
the string that was on the line is already the longest common prefix;
so now ainfo->line does NOT have a prefix with which to replace it.  
In this case cline_str() should re-insert the original word from the
line, which is present in ainfo->line->orig, but for some reason the
value of ainfo->line->olen is zero, so cline_str() ends up doing
nothng and the erased word is never restored.

ainfo->line->olen appears ultimately to come from add_match_part()
called from match_str() at line 739 of compmatch.c; it's merged from
there into ainfo by join_clines() called from add_match_data().  At
this point, though, I get lost trying to keep track of what's going
on with l + loff and llen (which comes from mp->llen) and ll and all
of Sven's other usefully named variables.

======

I *think* what it comes down to is that the matcher-list is causing
the path prefix to be mapped to nothing so as to be able to complete
the basename of the command, but because completion wants to wait for
a second tab before starting the menu on ambiguous results, it ends
up throwing away the data that it would need to do anything useful
when that second tab finally arrives.

This hypothesis is supported by the fact that using zstyle to force
entry into menu-selection results in completions being available.

However, I don't know whether the right thing is to recognized that
the prefix is going to end up empty and jump directly into the menu
without looking for the second tab, or to second-guess the matcher
code and re-insert the original word when that fails to do so; or if
there is instead a fix to compmatch.c needed.  And I don't presently
have any idea how to implement any of those choices.