Closed cattyhouse closed 1 year ago
Amazing that you found the exact fix. Good catch!
I still cannot reproduce the issue in my macOS even with the super detailed test that you've posted above. Maybe you have a path or file with special characters that I don't have.
Does it also work if you use LC_CTYPE=C
instead of LC_ALL=C
?
People say it is LCCOLLATE that matters. " how is sorted relative to letters"
I think LC_ALL is safer, who know what else there will be in fpath, it only apply to that line anyways
Oh okay, good point. I just have second thoughts on merging this because we're using the same code that compinint uses to collate the completions:
I'm wondering if the right solution would not be to have separate compdump files for each LANG (or LC_ALL):
zstyle ':zim:completion' dumpfile "~/.zcompdump.${LANG}"
since it seems compinit would generate different files in each case.
I dont know it is _
vs letters
:
printf '%s\n' _init_s _initc | LC_ALL=en_US.UTF-8 sort
_initc
_init_s
printf '%s\n' _init_s _initc | LC_ALL=C sort
_init_s
_initc
There are lots of _xx_yy in fpath, they order differently in different locale
Okay, if that has only to do with the order -- although we're not using sort in our code -- then I think I will not affect how compinit works, but will affect how the module code works because the order matters to the module logic.
The compdump file is different when the locale orders the _ character differently as you've shown:
% for lc (C cs_CZ.ISO8859-2) LC_ALL=${lc} compinit -C -d /tmp/zcompdump.${lc}
% diff -q /tmp/zcompdump.{C,cs_CZ.ISO8859-2}
Files /tmp/zcompdump.C and /tmp/zcompdump.cs_CZ.ISO8859-2 differ
It's just a matter of order inside the file, yes.
Test:
returns 1