Case-insensitive completion (Re: tab completion bug?)

[Bart Schaefer <schaefer@xxxxxxxxxxxxxxxx>]

[redirect to -workers and Cc TJ in case he's not on that list]

On Oct 24,  7:59am, TJ Luoma wrote:
} On Thu, Oct 23, 2014 at 10:23 PM, Bart Schaefer
} <schaefer@xxxxxxxxxxxxxxxx> wrote:
} > On Oct 23,  9:26am, TJ Luoma wrote:
} > }
} > } I would still suggest that the original behavior which left me with
} > } "cd $sites//Users/luomat/Dropbox/Sites/" is a zsh bug, but I will
} > } leave that decision to those more qualified to answer.
} >
} > I'm not able to reproduce this behavior ... I get the correct set of
} > completions even when capitals in $sites do not match the filesystem.
} >
} > There must be something else going on with your configuration.
}
}         setopt no_case_glob  # set ignore case for ls etc

That's the one.  With no_case_glob set I am able to reproduce the error:

torch% setopt nocaseglob
torch% db=$PWD
torch% sites=$PWD/src                                 
torch% cd $sites//usr/src/local/zsh/zsh-5.0-build/Src/

The setting of nocaseglob is tested at line 139 of _path_files and has
the effect of changing the matcher setting, which is passed down to
compfiles at line 463 and sends _path_files into this branch:

      # A little extra hack: if we were completing `foo/<TAB>' and `foo'
      # contains no files, this will normally produce no matches and other
      # completers might think that's it's their time now. But if the next
      # completer is _correct or something like that, this will result in
      # an attempt to correct a valid directory name. So we just add the
      # original string in such a case so that the command line doesn't 
      # change but other completers still think there are matches.

The actual culprit is the call to compadd at line 705, which adds the
unexpanded variable as the "original string" but passes the expanded
path prefix (with the inexact capitalization) as the -W option.  The
completion internals compare case-sensitively when removing the prefix,
so it doesn't match and the entire expanded path gets treated as if it
were the name of a file inside $sites/.

(It's possible I've got that partly wrong and the prefix isn't removed
because it doesn't match the literal '$sites/' but the end result is the
same.)

I'm not sure at this point what to do about it.